> 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.
Of course there are still bugs. And yes there are still serious bugs
lurking. But none we have a known and tested fix for.
> 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.
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.
-Rasmus
--
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]
