Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59566
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGSj+Qsr1xzdqJS1sxst8NwFO8XyE4RT9vpXqHKozj4w+MwbCg@mail.gmail.com>
References: <4F82878A.6030609@sugarcrm.com>
	<CAGSj+Qv+r2674T=N7zC0DhC9Xy1+6FVLw7+MYusA9pwESHBZzQ@mail.gmail.com>
	<CAKOpQSxMTUykqL1pBsfVWsYZ3rTZi7gOsrbk1yKk8ywSUbf1SA@mail.gmail.com>
	<4F834F94.1000002@sugarcrm.com>
	<CAKOpQSxvCFK+r==tgYrphepww6tnEeN=MFd_ZSTK=3=--MPAyA@mail.gmail.com>
	<CAGSj+Qsr1xzdqJS1sxst8NwFO8XyE4RT9vpXqHKozj4w+MwbCg@mail.gmail.com>
Date: Mon, 9 Apr 2012 14:55:45 -0700
Message-ID: <CAKOpQSx_wB3MY7C4EHUsW1j-GAE_X1ds38fH4dLD3xm8LgzjbA@mail.gmail.com>
To: Kiall Mac Innes <kiall@managedit.ie>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0442811e7e9a4f04bd461127
Subject: Re: [PHP-DEV] release process with git
From: kris.craig@gmail.com (Kris Craig)

--f46d0442811e7e9a4f04bd461127
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 9, 2012 at 2:33 PM, Kiall Mac Innes <kiall@managedit.ie> wrote:

> On Mon, Apr 9, 2012 at 10:27 PM, Kris Craig <kris.craig@gmail.com> wrote:
>>
>> What I'm referring to is the same kind of bugfixes/etc that go into new
>> release candidates.  I mean, we're still planning on having multiple
>> release candidates before an actual release, right?  If so, then obviously
>> we'll need a way to commit those changes.  If they're not made on the RC
>> branch, then where were you thinking they should go, and how would we then
>> apply those bugfixes to the 5.4 trunk if not through a merge?
>
>
> Referring again to how openstack manages this (because I personally feel
> they have nailed it)..
>
> Any commit that should be applied to the RC should also be applied to
> master/trunk, right? So - Why not commit it to master/trunk and nominate it
> for inclusion in the release. This allows a release manager to look at the
> bug, the fix, and the implications of of the fix before the fix lands in
> the RC.
>
> Once a commit has been made to master/trunk.. That fix can be
> cherry-picked into the RC if it's deemed suitable.
>

That approach would also work, so long as the RM doesn't mind having to
cherry-pick through different commits, making sure they're not based off of
non-included commits that would cause conflicts, etc.  Git merging
essentially does the bulk of this grunt work for you; but the downside, as
Stas pointed out, is that people would then wind-up posting unnecessary
commits because there would be no manual filtering.

Hmm so how about we consider a third option?  It sounds like what we need
is a bridge so that bugfixes can be quarantined yet still cherry-picked by
the RM without the added burden of code conflicts being introduced from
trunk.

So how about this:


   1. RM creates PHP-5.4.x branch from PHP-5.4.
   2. Development continues on PHP-5.4 branch without any interaction with
   PHP-5.4.x branch.
   3. RM is allowed to commit directly to PHP-5.4.x.
   4. Anybody else who wants to propose a bugfix will create a new branch
   based off of PHP-5.4.x.
      - For example:  git checkout -b Bugfix-Some_Bugfix_Title PHP-5.4.x.
   5. Once commit(s) on Bugfix branch are made, developer merges the bugfix
   into PHP-5.4 trunk branch and asks the RM (i.e. "nominates" it, as you put
   it) to merge it into the PHP-5.4.x release branch as well.
   6. RM can decide whether or not to merge it in.  Because the branch was
   based off of the release branch as opposed to trunk, it's considerably less
   likely that any conflicts will emerge should the RM decide to merge it in.
   If s/he doesn't merge it in, the changes have already been merged into the
   trunk branch so at very least they'll be there for the next release.

This approach should address everyone's concerns while taking advantage of
Git's branching functionality, which was designed precisely with situations
such as this in mind.  The RM filter remains but the manual workload and
potential for human error are both dramatically reduced.

--Kris


> Thanks,
> Kiall
>

--f46d0442811e7e9a4f04bd461127--