Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73586
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1396527638.2982.350.camel@guybrush>
References: <CAMUwpuQZrHBVkipgfbtaPxwUqGBGoX=AgAJrzXWCS5GATQcsbA@mail.gmail.com>
	<CAKOpQSwZ9-NNwHMSt2rrMw7s63bxf7+NYtAeDC-F=BDy+YVXTg@mail.gmail.com>
	<1396523991.2982.340.camel@guybrush>
	<CAKOpQSw4CpaZLdB0tkeorwnO+Ax9aYqFmMYasxwRwDLok8BZZw@mail.gmail.com>
	<1396527638.2982.350.camel@guybrush>
Date: Thu, 3 Apr 2014 14:34:55 -0700
Message-ID: <CAKOpQSw9=CgNcfS16=HccKDwKRo_oee_dv9LsDt_JoLyq3i2+Q@mail.gmail.com>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0115f08a1740b904f62a2c1b
Subject: Re: [PHP-DEV] Branching PHP6
From: kris.craig@gmail.com (Kris Craig)

--089e0115f08a1740b904f62a2c1b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 3, 2014 at 5:20 AM, Johannes Schl=FCter <johannes@schlueters.de=
>wrote:

> On Thu, 2014-04-03 at 04:32 -0700, Kris Craig wrote:
> > By release branch, are you referring to minor releases or maintenance
> > releases?  If the latter, it'd be a moot point under this model because
> > we'd be getting rid of separate branches for maintenance releases
> > altogether.  Instead, the RM would simply apply the tag to the commit
> where
> > they want the maintenance release to occur.  That would be a much clean=
er
> > approach than what we're doing now.
>
> The past shows that in practice this won't work. We had enough incidents
> in the past where "small" changes after an RC roe the release. That's
> why we created the strict rule of using those release branches.
>

That wouldn't happen if the RM controlled commits to the minor release
branch.


>
> > If you want to continue having a gatekeeper approach with only one pers=
on
> > having access to a minor increment branch, a simple alternative would b=
e
> to
> > have people push their feature branches if they believe the commits
> should
> > go on one or more minor increments.  Then, the release manager for each
> > minor increment (i.e. there'd be an RM for 6.0 and 6.1 instead of for
> each
> > individual maintenance increment) would decide whether or not to merge
> that
> > feature branch in.  The feature branch itself would be based on a minor
> > release branch and subsequently deleted after it's either merged or
> > rejected.
>
> Neither do we have the resources for constant gatekeeping nor is that
> the spirit. In general we trust developers to do the right things and
> prefer fixing mistakes afterwards over preventing improvements by
> process.
>

Actually, that's extremely easy to accomplish with Git.   Gitolite, for
example, enables the use of branch-specific permissions for different users=
.

Besides, my point was that this branching model can easily accommodate both
scenarios with and without a gatekeeper.


>
> The reason why we have the "ugly" history comes more from the fact that
> we have long living feature branches branched of quite some time ago
> (i.e. pull requests) which then are merged in, instead of e.e. rebaseing
> the first.
>
>
That's part of it, but I've also noticed a ton of criss-crossed merging
happening between version branches.  That, more than anything I think,
makes it a nightmare to read.  Furthermore, there's simply no need to have
an ever-increasing number of dead branches that lead nowhere and never
merge back.  If somebody wants to find a specific version, that's what tags
are for.

--Kris

--089e0115f08a1740b904f62a2c1b--