On Wed, 2 May 2001, James Moore wrote:
>
> > >I would be very against this.. to me it seems silly, the current QA Team
> > >will have to spend 90% of their time running through the (maybe
> > hundreds) of
> > >reports rather than testing. It makes more sense to me to try and attract
> > >more people who know what they are doing to the QA Team rather
> > than having a
> > >fairly (maybe more :)) disorderly group of people testing from
> > people who
> > >do not really know what they are doing..
> >
> > You have tens of thousands of people testing releases today. What's the
> > difference?
>
> The big difference is during a release process is the time scale. There are
> likley to be more bugs in an RC as well as people reporting bugs more
> rigerously (As well as probably reporting lots of bogus/dup bugs, which are
> very tedious to trawl through).
>
> If this is to happen (which I dont think it should) then we need to get the
> people to understand that RC testing is this this and this, not please test
> our latest RC and send feedback, if you come accross a problem then send the
> feedback here and here so it can be dealt with, please check the bugs
> database first etc.
>
> If we announce PHP 4.0.6RC1 in X places then people will think oh 4.0.6 is
> released (remeber PHP users are incapable of reading anything more than
> about 10 words) lets use that; they then wont bother upgrading when the real
> 4.0.6 is released. This means we will start to get bug reports saying this
> isnt working in 4.0.6 when it has been fixed in the RC phase but is still
> present in the first RC.
>
Perhaps, however, I don't see that so feasible. During the 4.0 release
cycle, the RC's were "publicly" released, and still, most people upgraded
and used 4.0 final. The benefits of having many people test a Release
Candidate, in my opinion, outweigh the negatives.
> Everyone seems to be trying to fix the problem the wrong way. IMHO the
> problem here was with the Release Cycle not the amount of testing.
>
> Normally I test RC1 massivly then if there are problems I check for them in
> later RC's where people have said they have been fixed (or its decided that
> the bug should be fixed before the release).
>
> This time this didnt work for the single reason Phanto was unresposible and
> commited a huge (700 line commit) to RC7 and DIDNT test it. I asked him (as
> I asked sascha too) to when we decided to have RC8 (I think I cc'd the list)
> to test his changes throughly as I would not have time due to "real" work.
> Now Phanto obviously didnt do this, maybe someone should have caught it but
> I feel that by not testing Phanto invalidated a lot of hard work by the rest
> of the team to make 4.0.6 stable.
>
There's no point in wagging fingers.
The fact is that this has happened before, thus the need for the patch
level releases... Whatever the meaning for this serious bug sneaking in
the release (as you said, its probably just a glitch in the Release
Process), it would still be a good thing (separate from the problems with
this release) to go ahead and make Release Candidates public on a site
like Freshmeat.
> I am certainly pissed off that this has happened as a lot of people put a
> lot of work into making sure 4.0.5 was stable and the problem here is not
> the testing but the developers commiting unneeded stuff to the RC branch.
>
> I feel we should only have x people commiting to the branch and if somthing
> is commited as late as the COM stuff was its up to the developer to test
> throughly otherwise its their head on the block.
>
There will always be glitches, educating people not to commit features to
Release Candidates (unless absolutely necessary) and re-inforcing that,
is, I think the better solution.
> and remember the old proverb "Too many cooks spoil the broth"...
>
"Given enough eyes, all bugs are shallow"
Its worked for Linux...
-Sterling
--
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]
