this process is known and we already said that we have to change the way we do it after 5.3.0.
On Fri, Jun 26, 2009 at 10:35 PM, Scott MacVicar<sc...@macvicar.net> wrote: > 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. > -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
