Re: 4.0.5: Merge Request

> 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