Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73569
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Kris Craig <kris.craig@gmail.com>
Cc: Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
In-Reply-To: <CAKOpQSw4CpaZLdB0tkeorwnO+Ax9aYqFmMYasxwRwDLok8BZZw@mail.gmail.com>
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>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 03 Apr 2014 14:20:38 +0200
Message-ID: <1396527638.2982.350.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Branching PHP6
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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 cleaner
> 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.

> If you want to continue having a gatekeeper approach with only one person
> having access to a minor increment branch, a simple alternative would be 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.


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.

johannes