I *completely* agree with making sure 5.3.0 is stable and stopping
extra things sneaking their way in. I just don't like the way that it
is being done.
If the release is tagged and built, then why continue with the freeze?
Why not open it up for bug fixes towards 5.3.1?
If the reason that you're about to be given is, we might find
something critical and need to re-roll 5.3.0 then branch from the tag
you've created, fix what's needed and re-tag. Even though CVS sucks it
does allow this.
This is the way the Mozilla project has done it for years, following
their example we'd just create a PHP_5_3_RELBRANCH and work from that.
The RMs are the only ones that get to decide what goes in after the
freeze.
https://wiki.mozilla.org/SeaMonkey:Release_Process
Scott
On 26 Jun 2009, at 21:12, Pierre Joye wrote:
you totally misunderstood the mail. The freeze is about the days
between now and the release itself on Tuesday (monday evening
actually). That's perfectly valid.
The idea then is to allow only bug fixes in 5.3.1, and only bug fixes.
What's wrong with that?
--
Pierre
On Fri, Jun 26, 2009 at 9:26 PM, Scott MacVicar<sc...@macvicar.net>
wrote:
On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote:
On 26.06.2009, at 20:26, Pierre Joye <pierre....@gmail.com> wrote:
On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar<sc...@macvicar.net>
wrote:
On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote:
Aloha,
So the last fix is just being prepared for a commit and so we
will be
tagging 5.3.0 soon.
We would like to up hold the commit freeze until 5.3.0 is
announced
next
Tuesday.
This freeze that you guys have implemented is frustrating, just
branch
5_3
into a release branch and Johannes can take selective fixes from
5_3 as
needed.
We all know your reasons for the freeze and agree with it but
holding up
regular development is a PITA.
It is not holding up development. It is about getting a viable
release
cycle and to give us the minimum safety to release 5.3.1 in a
reasonable time frame. Please explain me what's wrong to allow only
bug fixes for this phase?
Also please note that we have HEAD for all the developments and new
features.
Exactly.
I will do my best to track things that need to be merged. Best is
to note
if something needs to be merged.
But if you all feel it's such a huge burden then you can of course
insist
on putting the burden on the RMs. The fact of the matter is that
our current
infrastructure is not fit for providing both sides with an efficient
solution.
If we're freezing some more after this release for the SVN
conversion then
we could have a pretty cold branch for another week or so.
As I've already said, I agree with only allow verified bug fixes by
Johannes
into 5.3.0. it's this extra bureaucracy that is getting added on
top that's
sucking hard.
I don't want to leave it up to someone else to merge it into 5.3, I
should
be doing it myself. It's possible that things could get
accidentally missed
wen someone else is applying it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
