Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76148
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain litespeedtech.com designates 209.85.192.46 as permitted sender)
Message-ID: <53D2D90B.2020005@litespeedtech.com>
Date: Fri, 25 Jul 2014 18:24:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>, 
 Ferenc Kovacs <tyra3l@gmail.com>
CC: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@php.net>, 
 PHP Internals <internals@lists.php.net>
References: <539B8B74.6030707@sugarcrm.com>	<53CB0347.2030902@sugarcrm.com>	<53CEB32B.8030407@sugarcrm.com>	<53D03599.20205@litespeedtech.com>	<1406212844.3964.140.camel@guybrush>	<53D18775.3020107@litespeedtech.com> <CAH-PCH432SLt+gy0sHm8hDrdhMckdne4vnzGQ6tmDWayiJHj0A@mail.gmail.com> <53D2C44C.6090106@litespeedtech.com> <53D2CA71.3090707@sugarcrm.com>
In-Reply-To: <53D2CA71.3090707@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: 5.3 final release
From: gwang@litespeedtech.com (George Wang)

All right, looks like it is my fault not making the reply sounds 
critical enough. It pretty much make all third party php-litespeed rpms 
useless, only causes trouble and confusion for LiteSpeed users.

Maybe the release branches should be only open to the RMs, save everyone 
time and efforts and force to follow the procedure.

So, now moving forward, the code should be in PHP-5.4/5.5/5.6 branches 
already, I will update NEWS files in 5.4/5.5/5.6 branches, anything 
else? I want to make sure the LiteSpeed SAPI code is up2date in next 
release.

Best regards,
George Wang




On 7/25/2014 5:21 PM, Stas Malyshev wrote:
> Hi!
>
>> I just found that my commits to PHP-5.4.31 and PHP-5.5.15 branch have
>> been voided, the result is that in final 5.4.31 and 5.5.15 release
>> package, sapi/litespeed code is still the ancient V5.5 release, it is
>> ridiculous!
> No, it is not ridiculous, it is the release process. The three-number
> branches are release branches, and no commits but by the RMs should be
> done there. Moreover, even by the RMs the only commits that go there
> once the release is branched is either technical release commits
> (versions, NEWS, etc.) or urgent high-profile security fixes which could
> not be done in development branches, or other exceptional commits (like
> somebody discovering at the last moment Windows build is broken).
>
> In general, once the release branch is created, it is frozen except for
> urgent fixes, RC fixes/reverts and other exceptional cases. The decision
> of which commits to include is by the RM of the branch.
>
> The regular commits go into development branches - PHP-5.4, PHP-5.5,
> etc. I've sent you an email to verify if it is not an urgent commit, but
> both from review and from your answers it was clear that it was not, and
> there's no compelling reason to override regular release flow for it.
> Thus, these commits were not included into releases that were already
> well under way.
>
>> What is the procedure to make sure our latest sapi/litespeed release
>> will be in the next release?
> Creating a pull request and after review etc. committing it to the
> development branches - PHP-5.4, PHP-5.5, etc. There's more info here:
> https://wiki.php.net/vcs/gitworkflow
>
> In the future, I would recommend to ask on the list if the procedure is
> not clear. I understand there was a lot of change in how PHP release
> process works in the last couple of years, and not everybody may be up
> to date with it. Please ask and we will answer. We have docs, we have
> guides and we have this list where there are a number of people who can
> explain how to do things right. We've outgrown the situation of cowboy
> release management, we have a process now, which has been working pretty
> well so far. I am sorry that it caused your frustration, but be assured
> your changes are not lost and will be released in the next version in
> accordance to the regular release process.
>
> I would also encourage you to update NEWS files for the release branches
> from 5.4 up to reflect your changes. The changes are always made to the
> topmost release in the NEWS file.