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. :)
I think all of these are good ideas that will contribute to getting us out of this mess. Another 4.1.0 RC RSN then. - Stig -- 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]
