At 10:35 PM 4/24/2001 -0700, Rasmus Lerdorf wrote:
> > At 02:24 AM 4/25/2001 +0300, Zeev Suraski wrote:
> > >While I'd say Jani's letter was slightly over emotional ;), he does have a
> > >point.
> > >I think that taking a stop to look closely at the bugs database would be a
> > >good thing, and the turn of a new version is a good time to do
> > >it. Deciding 4.0.6 won't include any significant new features, and that
> > >we'll start its release process after a bugs-database-cleaning period
> > >sounds like a good idea to me.
> >
> > Well I was saying exactly what Jani is saying. That if you want a bug free
> > minor version then you have to be aware of all the existing crash bugs in
> > the bugs database and not live in the illusion that this last 4.0.5 crash
> > bug fix creates now a stable version. I don't think every crash bug can be
> > a show stopper. Our releases would slow down to a halt.
>
>Nobody is talking about such an illusion. Let's not lose track of what
>caused this ruckus. A crash bug was found and fixed in a mainstream
>extension. It was just before a release. So the release was put off for
>a couple of days to get this fix in. I see absolutely nothing wrong with
>this.
Neither do I.
>Of course there are still bugs. And yes there are still serious bugs
>lurking. But none we have a known and tested fix for.
Yes but for example the crash bug I fixed in foreach(). I don't think it
was a showstopper. It ended up slipping in because there was another RC
anyway (and it was a one liner) but what I meant is that not all crash bugs
are show stoppers.
> > Anyway, I think it's a good idea to decide on a one to two week intensive
> > period where no features are added and all developers work hard on closing
> > crash bugs and other serious bugs. The problem is that there will be lots
> > of developers who will want their very important patches going into 4.0.6
> > and quite a few who won't be bothered to do the tough job. I'm not sure
> > this would work.
>
>This will definitely not work as "all developers" are at very different
>stages of development. Some extensions are very young and evolving
>quickly right now. Telling a developer with such an extension to stop
>developing the extension and only fix bugs doesn't make much sense.
I disagree. I don't think having developers take off a couple of days from
their "stage of development" and help the greater PHP cause is a big deal.
After all it is these developers that can help fix bugs, and well what can
we do, bugs aren't necessarily fixed by their authors.
It's much more fun coding and writing your own extension, and it's a good
thing, but it doesn't mean you can't do some of the dirty work for a couple
of days. That suggestion to look at the Debian model is a good idea IMO.
>The realistic way to do this, and the way I thought we had agreed on, is
>to create a release branch at some semi-stable point and not add new
>features to it but focus on fixing the most serious bugs in it. And yes,
>I agree that it would be good if we could get more developers to focus on
>the release branch and devote more cycles to tracking down issues in the
>release branch, but here is where I would like the QA team or someone to
>step up and create a list of issues (likely just a list of bug id numbers)
>that they deem to be significant issues with the release branch. It
>should not be the QA team's job to track down developers and try to
>convince them to fix bugs.
>
>eg.
>
>Release branch 4.0.87
>
> Showstoppers: #20457, #24099
> Serious: #245555, #354354, #546543
> Moderate: #535436, #45326543, #5443543
>
>Developers like finite-looking lists like this. They can see an end to
>the work. Fix 5 bugs and we are good to go for the release. Obviously
>there will still be bugs, but at least this would be an organized approach
>to it.
Having a better defined/reproduced list of bugs is a must and if the QA
team can do that PHP will definitely benefit from it. However, today when
they ask people to fix bugs they are often not fixed and I don't even think
that they are necessarily looked at. That is why a defined "everyone join
forces to kill the bugs" period would be a good thing. And whoever doesn't
help isn't allowed to hack on his extension anymore (Just kidding :).
Andi
--
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]
