Bug fixing stalled?
By my count, there's about 90 "critical" bugs and nearly 400 "normal" bugs in cvs/4.7beta. For the past few days, I've been trying to fix a couple of bugs a day and clearing out ones that no longer apply. I want to encourage everyone to do the same. We could be done in a couple of weeks time with the critical bugs, I think. -- Dondley Communications http://www.dondleycommunications.com Communicate or Die: American Labor Unions and the Internet http://www.communicateordie.com
On 09 Jan 2006, at 5:10 AM, Steve Dondley wrote:
By my count, there's about 90 "critical" bugs and nearly 400 "normal" bugs in cvs/4.7beta. For the past few days, I've been trying to fix a couple of bugs a day and clearing out ones that no longer apply. I want to encourage everyone to do the same. We could be done in a couple of weeks time with the critical bugs, I think. I am going to spend all of next weekend bug fixing. we really _need_ a 4.7 release to be done before vancouver.
I was thinking we should organise a bug fix friday. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Mon, 09 Jan 2006 04:10:27 +0100, Steve Dondley <sdondley@dondley.com> wrote:
By my count, there's about 90 "critical" bugs and nearly 400 "normal" bugs in cvs/4.7beta. For the past few days, I've been trying to fix a couple of bugs a day and clearing out ones that no longer apply. I want to encourage everyone to do the same. We could be done in a couple of weeks time with the critical bugs, I think.
I have a site to release on the 10th. Then I'll spend a hell lot of time on core.
Hi, On Sun, 2006-01-08 at 22:10 -0500, Steve Dondley wrote:
By my count, there's about 90 "critical" bugs and nearly 400 "normal" bugs in cvs/4.7beta. For the past few days, I've been trying to fix a couple of bugs a day and clearing out ones that no longer apply. I want to encourage everyone to do the same. We could be done in a couple of weeks time with the critical bugs, I think.
This is a great idea, But I am concentrating on E-Commerce at this stage so that I can make a release soon after 4.7 is released. Gordon.
This is a great idea, But I am concentrating on E-Commerce at this stage so that I can make a release soon after 4.7 is released.
Don't drop everything else. Just commit to doing 20 to 30 minutes per day reviewing patches, investigating and hopefully squashing a bug or two. -- Dondley Communications http://www.dondleycommunications.com Communicate or Die: American Labor Unions and the Internet http://www.communicateordie.com
On 1/8/06, Steve Dondley <sdondley@dondley.com> wrote:
Don't drop everything else. Just commit to doing 20 to 30 minutes per day reviewing patches, investigating and hopefully squashing a bug or two.
I have been trying to do this, but have a few questions. Many of the "critical" bugs only affect a small group of people. I think that there are really two ideas that need to be expressed (severity and priority) but they are jammed into the one field (priority). If we encounter bugs that are severe, but which only affect a small group of people, should we change their priority to "normal" just to get them off this list? It would also be nice to have a status of "not-repeatable" since that seems like a discrete problem different from the current status values. Or should those items just get turned into "support requests" and moved out of the queue? Greg
I like these ideas. The last increase to the number of ways to classify a little while back was a big improvement. I think there is some merit to adding the categories you mention below. +1 On 1/8/06, Greg Knaddison <greg.knaddison@gmail.com> wrote:
On 1/8/06, Steve Dondley <sdondley@dondley.com> wrote:
Don't drop everything else. Just commit to doing 20 to 30 minutes per day reviewing patches, investigating and hopefully squashing a bug or two.
I have been trying to do this, but have a few questions.
Many of the "critical" bugs only affect a small group of people. I think that there are really two ideas that need to be expressed (severity and priority) but they are jammed into the one field (priority).
If we encounter bugs that are severe, but which only affect a small group of people, should we change their priority to "normal" just to get them off this list?
It would also be nice to have a status of "not-repeatable" since that seems like a discrete problem different from the current status values. Or should those items just get turned into "support requests" and moved out of the queue?
Greg
-- Dondley Communications http://www.dondleycommunications.com Communicate or Die: American Labor Unions and the Internet http://www.communicateordie.com
Op maandag 09 januari 2006 06:19, schreef Steve Dondley:
It would also be nice to have a status of "not-repeatable" since that seems like a discrete problem different from the current status values. Or should those items just get turned into "support requests" and moved out of the queue?
I mailed the development list about another important setting: "post 4.7". A lot of bugs are *real* bugs, but have been around for a long while, or are not critical for a release for 4.7 [1]. But *really are* bugs. Being able to "postpone them for after 4.7" might be a good idea. Using the postponed status is not an option, since we then use the "patch" etc status, as well as that there is no indication untill when its postponed. Bèr [1] http://drupal.org/node/40505
On 1/9/06, Bèr Kessels <ber@webschuur.com> wrote:
I mailed the development list about another important setting: "post 4.7". A lot of bugs are *real* bugs, but have been around for a long while, or are not critical for a release for 4.7 [1]. But *really are* bugs. Being able to "postpone them for after 4.7" might be a good idea. Using the postponed status is not an option, since we then use the "patch" etc status, as well as that there is no indication untill when its postponed.
Yes, that makes sense, kind of. I believe that the "version" field is for the version where the problem/feature request was found. There should ideally be another field for "version targetted to fix the problem" I was thinking more about my comment that we need a "not repeatable" entry added to the "status" but I think that we really need a "resolution" field separate from status (though comments suffice for now) to track what happened rather than the "status". The "status" may be "active" but that doesn't tell us whether it is waiting to be verified, verified as a bug and needs to be fixed, or "not repeatable". So, the total of Bèr and my recommendations: 1. New "Targeted Milestone" field which contains the release where the bug is hoped to be fixed (also helps with changelogs/release announcements) which would include post 4.7 2. Severity field separate from priority 3. Resolution field separate from status with corresponding new values. Ironically, this seems like "post 4.7" work ;) Greg
1. New "Targeted Milestone" field which contains the release where the bug is hoped to be fixed (also helps with changelogs/release announcements) which would include post 4.7 2. Severity field separate from priority 3. Resolution field separate from status with corresponding new values.
Best to file these as feature requests for the project.module, and to create a cross-reference it from the Drupal infrastructure project. :-) -- Dries Buytaert :: http://www.buytaert.net/
What is the general rule for handling issues assigned to outdated versions? For e.g. if an issue exists in 4.5.0, which has been fixed in the current HEAD, it it OK to mark it as fixed? Or will it need to be fixed in the 4.5.x tree? Thanks -K
Karthik wrote:
What is the general rule for handling issues assigned to outdated versions? For e.g. if an issue exists in 4.5.0, which has been fixed in the current HEAD, it it OK to mark it as fixed? Or will it need to be fixed in the 4.5.x tree?
I have no inhibition to mark 4.5 or 4.6 bugs as fixed if this is fixed in cvs. Cheers, Gerhard
Steve Dondley wrote:
By my count, there's about 90 "critical" bugs and nearly 400 "normal"
Note: many of the bugs are only marked as critical because that is now the defautl setting. it would be helpfull to find out which ones of those actually are critical and downgrade the rest to normal or minor. A bug is critical if it breaks Drupal ie a +- important function that fails in some way.
bugs in cvs/4.7beta. For the past few days, I've been trying to fix a couple of bugs a day and clearing out ones that no longer apply.
Thats much appreciated. I'd also appreciate if everybody could look at the issues they once created and see if they still apply. They'd know best.
I want to encourage everyone to do the same. We could be done in a couple of weeks time with the critical bugs, I think.
That would be nice. There are also a lot of patches waiting for reviews and work to be done at them. Cheers, Gerhard
participants (10)
-
Adrian Rossouw -
Bèr Kessels -
Dries Buytaert -
Gerhard Killesreiter -
Gordon Heydon -
Greg Knaddison -
Karoly Negyesi -
Karthik -
Steve Dondley -
Steve Dondley