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