[Ns-developers] Open bugs - partial list of suggestions
tpecorella at mac.com
Wed Mar 14 01:53:40 PDT 2012
I do agree.
we do have most bugs left as "NEW" even when they are assigned, and the tracker (expected time, etc) is not used. Just using the full bugzilla features would be a great thing.
On the other hand, the problem is twofold: future and past.
For the future we can/should/must use better the tracker properties.
For the past we have to recover some lost metadata, e.g., what's the "bug" status. Is the bug waiting for a decision? (i.e., it contains a potential patch), did someone work on it? Is it relevant or just there for reference? It is just no more relevant?
The spreadsheet was done to answer those question and allow a quick restart on those.
My proposal is to add perform a review of the bugs and, based on consensus, prune what is:
1) not relevant anymore
2) just waiting for a decision about the proposed patch
plus to confirm/deny that a bug is still there (some bugs might have been fixed as a "side-effect" of some other bug).
This could be done in a week or two, as it's just a cleanup thing.
The following actions should be to assign all the bugs to the proper people (with their consensus) and to have a schedule for them. The point is not to close them all and fast, is just to know if somebody is working on them.
In my opinion it would be already a huge step forward to not have any bug with the NEW status. That should mean only that the bug is... new and nobody checked it.
We do have already a quite full dev meeting agenda, however we could add a short point about this. Just to have a general consensus about the action point to be taken.
On 14 Mar 2012, at 07:46, Tom Henderson wrote:
> On 03/13/2012 01:31 PM, Vedran Miletić wrote:
>> 2012/1/9 Tommaso Pecorella<tpecorella at mac.com>:
>>> my bad, now it's in read-write mode. I'm happy you're on it.
>> Tommaso, can you define a realistic release goal here, i.e. "it would
>> be a great idea to close all these for 3.14" or "we should update info
>> on all, but close at least a half"? So we can organize this into some
>> kind of a bug marathon or so.
> From my perspective, what would help most is to use the tracker to keep better track of who plans to do what by when. It is not clear who is working on specific bugs. We could use some combination of bug assignment and priority to track this.
> A bug with an assignee and status ASSIGNED (or REOPENED) and priority greater than P5 implies that someone is working on it and could be nagged periodically by release managers for status.
> There are some bugs in there that are left in for very long time as reminders that future enhancements would be welcome. However, it probably is not clear to newcomers that a patch would be welcome here if it shows as being ASSIGNED.
> I also think that release managers should be reviewing the tracker and trying to close things out, so I support what Tommaso is trying to do, but perhaps just suggesting to use the tracker instead of a separate spreadsheet. This would also help avoid the wiki bug lists that I have maintained during recent releases.
> - Tom
> p.s. a long time ago, Craig wrote up this, which we are not diligent enough to stick to, but we could revisit:
"To be is to do" - Socrates
"To do is to be" - Sartre
"Do Be Do Be Do" - Sinatra
"Scooby Dooby Do" - Scooby Do
"Yaba Daba Doo!" - Fred Flintstone
Tommaso Pecorella - Ph.D.
Dpt. Elettronica e Telecomunicazioni
Università di Firenze
CNIT - Università di Firenze Unit
via di S. Marta 3
email: tommaso.pecorella at unifi.it
tommaso.pecorella at cnit.it
phone : +39-055-4796412
fax : +39-055-494569
More information about the Ns-developers