Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger.
Andi At 10:34 PM 11/10/2001 +0200, Jani Taskinen wrote: >On Sat, 10 Nov 2001, Zeev Suraski wrote: > > >Guys, > > > >We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on > >which 4.1.0 is currently scheduled to be based on, has branched away a few > >months ago. Some people have expressed concern that releasing 4.1.0 based > >on that branch is not a good idea, because there have been so many changes > >in the HEAD branch, and synchronizing fixes and so on is going to be a > >headache. > >I have a bad feeling about this branch and I vote for dropping it and >starting new from HEAD. There are several reasons for this: > >The change between 4.0.7 -> 4.1.0 (and also sudden change of the >release master from Zeev to Stig) has confused some people according the >discussion on php-qa list a while ago. Many of them might have tested >4.0.7 RCs but not necessarily all have tested the 4.1.0 RCs. >Not to forget the 11th of September.. > >I have no idea who have tested the latest RC. Does anyone have? >After the latest RC there have been a LOT of fixes in the release >branch and also several fixes in the HEAD (which weren't MFH'd) >and there hasn't been any new RCs after those fixes were committed. > >How many people test the branch (from CVS) ? >Has anyone kept any list of the test results and problems found ? >Has anyone kept eye on fixes done which weren't merged to the branch ? > >Answer is: We don't KNOW. > >The thing is that the project has grown to be so big that we can not >afford long periods of time between releases. Too much stuff gets >in without testing. Too many NEW bugs are introduced and like it has been >said many times before, not enough people really pay attention to fixing >them. Developers simply ignore them and continue adding new stuff thus >creating new possible bugs. > >Anyone think what I think? "Release early, release often" > >http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.html > >This works very well for Linux, why wouldn't it work for PHP ? >Our QA team is very small. It has actually gotten smaller during the >last 6 months instead of getting bigger like it should have. > >Enough ranting, let's get into fixing this situation. I can't see any >solutions that won't bite us but one solution that won't bite as so >badly in the _long_run_, as if we delay it or release too early we're >gonna get hurt. My proposal is this: > >- Release the current branch as 4.1.0 but clearly state that there > will be 4.2.0 soon. Also start the 4.2.0 branch from HEAD now and > the QA process on it with some things kept in mind: > > o Any serious problems found (by our best QA team: the real users) in 4.1 > we fix them in 4.2 and announce that after 4.2 release we start > following the versioning rules for real. > > o We continue releasing 4.2.x versions out of the 4.2 branch but with > ONLY bug fixes in it. And we do this OFTEN. Any new stuff goes to HEAD. > We should decide what amount of fixes or with what severity triggers > the (short) QA process for the 4.2.x branch. > > o After there have been, let's say 5 big ones in HEAD, we start new > branch, 4.3 and QA process moves there. The QA should not take so long > with this. Security related fixes should trigger new release process > immediately. > > o Any changes into extensions from now on should include the start of > using the version numbers in extension. Also, if there are changes in > many extensions or there are big changes in some extension we make > another 4.2.x release. (compromise for Zeev's sake :) > > o Any big changes or changes that might possibly break things should > be announced on the php-qa list and only after QA has tested that the > changes don't break anything, they should be allowed into CVS. > >- We need to have ONE place where to keep the RC packages. And we > need to have also Windows build of the RCs at this same place. > Having the packages in someone's home directory is not very good idea. > Better place would be at http://qa.php.net/ > >- We name persons for each branch who work together with QA team and > make sure the releases are tested properly. ie. This person merges all > fixes into the branch and keeps record how the testing goes on and > decides when is the time to release. > > o List of succesful builds on different platforms > - Create a build tracker to qa.php.net (Bat[e] ?) > >- Make the bug system to send bug reports to php-qa list > and only confirmed reports to php-dev thus making it easier > for developers to notice which reports are real bugs. > Huge amount of the reports coming in are bogus. > >With all this I think we can avoid this kind of situations in the future >as the amount of testing will get smaller. And democracy doesn't always >work. :) > >Of course these release-dictators should be elected somehow so that >evil dictators never get the power again. :) > >--Jani > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
