Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73609
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53404ED4.7080304@sugarcrm.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>
	<1396527638.2982.350.camel@guybrush>
	<CAKOpQSw9=CgNcfS16=HccKDwKRo_oee_dv9LsDt_JoLyq3i2+Q@mail.gmail.com>
	<533F9C11.9000303@sugarcrm.com>
	<688A2215-A79A-417B-8E7A-76CF03DF9F35@gmail.com>
	<CAKOpQSyCKtpnTBWuxx7Geae0+Q8oPB3BjBFUJVDUqYDZv-+iEg@mail.gmail.com>
	<533FBFB3.3010808@sugarcrm.com>
	<CAF+90c9+5v8PHQgNjqS8Rz8zhbbUdvj-uCVd5XfY_ty8UTOdAw@mail.gmail.com>
	<53404ED4.7080304@sugarcrm.com>
Date: Sat, 5 Apr 2014 19:32:12 -0700
Message-ID: <CAKOpQSyPJT2NZPuSxLCaTXcxOB6Vj9usJhHB8yCEqzKRtWcz2Q@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>, 
	Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133059ef27b9904f6568e9b
Subject: Re: [PHP-DEV] Branching PHP6
From: kris.craig@gmail.com (Kris Craig)

--001a1133059ef27b9904f6568e9b
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Apr 5, 2014 at 11:43 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > A github fork of a semi-active PHP core developer likely has at least
> > ten additional "active" (as in, not yet merged) branches.
>
> These branches are in dev's private fork, so I'm pretty confident the
> devs can manage their own backyard. They also don't have to import every
> branch from main repo to their private repo, AFAIK.
>
> > I think keeping around dead branches does have a cost. It blows up
> > branch listings significantly. If you open the branch list on github and
> > try to find something you'll end up scrolling through more than fifty
> > release branches and other dead ends.
>
> It has a completion widget there, and I still not sure what is
> "something" you're looking for there. Is it "PHP-5.6"? It's not hard to
> find then, you know its name. The issue seems to me getting much more
> attention than it deserves.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
You are correct in that it's not a catastrophic issue or anything.  But
even if it's not that big a deal, it's still a mess.  And I guess the point
I'm making is that, if there's a cleaner way of doing this that doesn't
introduce any costs or other drawbacks (which there is and it doesn't),
then why not do it the cleaner way going forward starting with PHP 6?
 Here's a quick breakdown of what we'd be looking at:


   - Release managers would continue to have exclusive commit access to
   release branches.
   - Current and past versions would still be quickly and easily accessible
   via tags, just as they are now.
   - Branching would better reflect segregation of maintenance releases
   from trunk commits.
   - Feature branching would be consistent and would not add to clutter.
   - The corpses of old EOL branches would no longer pile-up and linger for
   eternity.
   - The reduced clutter will make it easier to locate active branches and
   much easier to read and make sense of the commit history.

On the flip side, there really aren't any drawbacks.  The only case against
doing this that I'm seeing is "it's no big deal".  Maybe it's not that big
a deal, but it's still an improvement that doesn't introduce any adverse
consequences.  I realize that some people who are still Git-weary might be
a little reluctant to tweak the branching procedure at all, but it's really
not as complicated as it sounds.

--Kris

--001a1133059ef27b9904f6568e9b--