Bugzilla bug tracking database for 2.5 now available.
Quoted 11 lines · Paul Larson
Quoted 4 lines
That being said, I guess this should have been the first question:
Should bugs reported to bugme still be posted here (or elsewhere when appropriate)? I would assume so, at least for a while.Yes!
The bugzilla database is a great idea but it should remain a database i.e. a list. Discussion and the initial reporting of bugs should remain on the relevant lists _please_.
Please do not force users to report X times the same bug in different places.
This will only lead to lost information since people won't drag the whole problem history each time. OTOH at least the initial stage of bug submissions should be cc'd to the relevant lists, so that interested people can get on the problems. This is what apache does (with big fat warnings to not reply to the mail but fire bugzilla instead) and it seems to work well.
Regards,
Signature · 1 line
Nicolas Mailhot <[email protected]>
While I have this on my mind I want to express this now since the very first bug that hit my mailbox had this issue.
I DO NOT want to be working on bugs on anything other than Linus's actualy sources. The first bug I got was a networking bug with Andrew Morton's -mm patches applied.
This isn't going to work if that is what people are going to be allowed to do.
I want to suggest that all reported bug in the database must be reporducable with some release done by Linus or his BK sources. And also that we can automatically close any BUG submissions that have other patches applied.
Quoted 7 lines
While I have this on my mind I want to express this now since the very first bug that hit my mailbox had this issue.
I DO NOT want to be working on bugs on anything other than Linus's actualy sources. The first bug I got was a networking bug with Andrew Morton's -mm patches applied.
Quoted 7 lines
This isn't going to work if that is what people are going to be allowed to do.
I want to suggest that all reported bug in the database must be reporducable with some release done by Linus or his BK sources. And also that we can automatically close any BUG submissions that have other patches applied.
Hmmm ... I'm not sure that being that restrictive is going to help. Whilst bugs against any randomly patched version of the kernel probably aren't that interesting, things in major trees like -mm, -ac, -dj etc are likely going to end up in mainline sooner or later anyway ... wouldn't you rather know of the breakage sooner rather than later?
Recall when some random idiot broke sparc64 by mucking with free_area_init_node? Those changes had been sitting in -mm tree for a while ;-) (and yes, that was me).
M.
Quoted 16 lines · Martin J. Bligh
Quoted 8 lines
While I have this on my mind I want to express this now since the very first bug that hit my mailbox had this issue.
I DO NOT want to be working on bugs on anything other than Linus's actualy sources. The first bug I got was a networking bug with Andrew Morton's -mm patches applied.
Quoted 7 lines
This isn't going to work if that is what people are going to be allowed to do.
I want to suggest that all reported bug in the database must be reporducable with some release done by Linus or his BK sources. And also that we can automatically close any BUG submissions that have other patches applied.
Quoted 6 lines
Hmmm ... I'm not sure that being that restrictive is going to help. Whilst bugs against any randomly patched version of the kernel probably aren't that interesting, things in major trees like -mm, -ac, -dj etc are likely going to end up in mainline sooner or later anyway ... wouldn't you rather know of the breakage sooner rather than later?
Well for that particular tree, the diff from mainline is quite small, and those diffs are avowedly experimental. That's why it exists - the get fresh code some testing and exposure.
So people will need to use their judgement as to whether the problem is in 2.5.47, or in the -bk snapshot which was taken from Linus, or in the -mm addons.
If in doubt, people should go for the mailing list first. Because
a) the response time will be better
b) more people will see it
c) the owners of the add-on patches can screen it quickly.
But hey. It's early days yet, and it is easy to overdesign this sort of thing. I'd say just start using the thing, and adapt the work processes later on, based on some experience.
Quoted 21 lines · Andrew Morton
Quoted 9 lines · Martin J. Bligh
Quoted 8 lines
While I have this on my mind I want to express this now since the very first bug that hit my mailbox had this issue.
I want to suggest that all reported bug in the database must be reporducable with some release done by Linus or his BK sources. And also that we can automatically close any BUG submissions that have other patches applied.
Quoted 6 lines
Hmmm ... I'm not sure that being that restrictive is going to help. Whilst bugs against any randomly patched version of the kernel probably aren't that interesting, things in major trees like -mm, -ac, -dj etc are likely going to end up in mainline sooner or later anyway ... wouldn't you rather know of the breakage sooner rather than later?
So people will need to use their judgement as to whether the problem is in 2.5.47, or in the -bk snapshot which was taken from Linus, or in the -mm addons.
Quoted 5 lines
If in doubt, people should go for the mailing list first. Because
a) the response time will be better
b) more people will see it
c) the owners of the add-on patches can screen it quickly.
Has my 2.5 Problem Report Status postings been useful? If so, when I discussed this with Martin one of the roles we agreed I would play was taking bug reports from the list and adding them to bugzilla. I'll also be a "filter" for some of the issues discussed in this thread, sort of a janitor if you will.
My question is how should compile failures figure into the bug database? Most of the compile failures are typos or thinkos that get quickly fixed. Should they get tracked, or dismissed quickly unless they linger on. I didn't track simple compile failures in my list.
Quoted 3 lines · Thomas Molina
...
Has my 2.5 Problem Report Status postings been useful?
I think it's at the stage where it needs a "nag" factor. Those little reminder emails from bugzilla are really irritating.
Quoted 5 lines
If so, when I
discussed this with Martin one of the roles we agreed I would play was taking bug reports from the list and adding them to bugzilla. I'll also be a "filter" for some of the issues discussed in this thread, sort of a janitor if you will.
Sounds very useful.
Quoted 4 lines
My question is how should compile failures figure into the bug database? Most of the compile failures are typos or thinkos that get quickly fixed. Should they get tracked, or dismissed quickly unless they linger on. I didn't track simple compile failures in my list.
I'd say don't include them. It's not as if we're likely to forget about them.
Quoted 35 lines · Thomas Molina
Quoted 21 lines · Andrew Morton
Quoted 9 lines · Martin J. Bligh
Quoted 8 lines
While I have this on my mind I want to express this now since the very first bug that hit my mailbox had this issue.
I want to suggest that all reported bug in the database must be reporducable with some release done by Linus or his BK sources. And also that we can automatically close any BUG submissions that have other patches applied.
Quoted 6 lines
Hmmm ... I'm not sure that being that restrictive is going to help. Whilst bugs against any randomly patched version of the kernel probably aren't that interesting, things in major trees like -mm, -ac, -dj etc are likely going to end up in mainline sooner or later anyway ... wouldn't you rather know of the breakage sooner rather than later?
So people will need to use their judgement as to whether the problem is in 2.5.47, or in the -bk snapshot which was taken from Linus, or in the -mm addons.
Quoted 5 lines
If in doubt, people should go for the mailing list first. Because
a) the response time will be better
b) more people will see it
c) the owners of the add-on patches can screen it quickly.Has my 2.5 Problem Report Status postings been useful? If so, when I discussed this with Martin one of the roles we agreed I would play was taking bug reports from the list and adding them to bugzilla. I'll also be a "filter" for some of the issues discussed in this thread, sort of a janitor if you will.
Quoted 4 lines
My question is how should compile failures figure into the bug database? Most of the compile failures are typos or thinkos that get quickly fixed. Should they get tracked, or dismissed quickly unless they linger on. I didn't track simple compile failures in my list.
It'd be nice if people simply tried compiling a patched kernel (all affected modules) before they submitted the patch, I'm betting you'd catch a lot of typos. Also, compiling _everything_, even as a module, at least once before sumbitting the patch would probably help.
I'm sure people will miss one or two still, but so far I've found a fairly high hit rate of things that simply won't compile in 2.5.x - also the main reason that I hadn't actually used a 2.5.x kernel until now.
Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu
Quoted 4 lines · Patrick Finnegan
It'd be nice if people simply tried compiling a patched kernel (all affected modules) before they submitted the patch, I'm betting you'd catch a lot of typos. Also, compiling _everything_, even as a module, at least once before sumbitting the patch would probably help.
thats fine if there is an all-compiling kernel release out there. right now 2.5-bk is far from it. last i checked allmodconfig (a couple of days ago) there was major breakage all over llc, scsi, video, sound, ... which kinda masks any breakages you might have introduced. these sort of things get fixed in time, but they are often replaced by new ones in other places
j.
Signature · 1 line
toyota power: http://indigoid.net/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 4 lines · Thomas Molina
My question is how should compile failures figure into the bug database? Most of the compile failures are typos or thinkos that get quickly fixed. Should they get tracked, or dismissed quickly unless they linger on. I didn't track simple compile failures in my list.
It probably depends where in the 2.5 cycle you are up to.
While there are still a lot of changes going in, it isn't so critical.
When it gets to 2.5.99 and later, you need to track absolutely everything. Even if that means entering the problem, and 20 minutes later entering the patch that corrects it, and the next day closing the bug against Linus' next release.
Given a resourced bug tracker, and the various test projects, this could be a nice smooth release producing a product without gaping holes. But its probably a bit soon to tell...
Brad
- --
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE91G4kW6pHgIdAuOMRAkNiAKCNE7pvodft5ZC+e7nTqgbLeLO0ewCfQujm bNoeJoLIea10YFPSTfyRdnM=
=SPCi
-----END PGP SIGNATURE-----
Quoted 3 lines · Martin J. Bligh
Quoted 3 lines
I DO NOT want to be working on bugs on anything other than Linus's actualy sources. The first bug I got was a networking bug with Andrew Morton's -mm patches applied.
[snip
Quoted 6 lines
Hmmm ... I'm not sure that being that restrictive is going to help. Whilst bugs against any randomly patched version of the kernel probably aren't that interesting, things in major trees like -mm, -ac, -dj etc are likely going to end up in mainline sooner or later anyway ... wouldn't you rather know of the breakage sooner rather than later?
Would this be an appropriate use of the "version" tag in Bugzilla? Currently the only choice is "2.5", but if that were renamed to "2.5-linus", then the other heavily used patchsets could be monitored while making it easy for people who only want to see bugs in Linus' tree.
-Eric
Quoted 4 lines · Eric Northup
Would this be an appropriate use of the "version" tag in Bugzilla? Currently the only choice is "2.5", but if that were renamed to "2.5-linus", then the other heavily used patchsets could be monitored while making it easy for people who only want to see bugs in Linus' tree.
That works for me. Create a 2.5-ac product that is assigned to me. I can then reassign them all to DaveM as appropriate
Quoted 8 lines · Alan Cox
Quoted 4 lines · Eric Northup
Would this be an appropriate use of the "version" tag in Bugzilla? Currently the only choice is "2.5", but if that were renamed to "2.5-linus", then the other heavily used patchsets could be monitored while making it easy for people who only want to see bugs in Linus' tree.
That works for me. Create a 2.5-ac product that is assigned to me. I can then reassign them all to DaveM as appropriate
I think this is an excellent idea. It shouldn't require much effort to get bugs directed to the people would would be most likely to care about it. That was my thinking when I suggested the "send a one time copy of this bug report to <email address>". If the right person is already set up to get the report though, this feature wouldn't be needed (as often).
-Paul Larson
Quoted 8 lines · Eric Northup
Quoted 4 lines
Would this be an appropriate use of the "version" tag in Bugzilla? Currently the only choice is "2.5", but if that were renamed to "2.5-linus", then the other heavily used patchsets could be monitored while making it easy for people who only want to see bugs in Linus' tree.
That works for me. Create a 2.5-ac product that is assigned to me. I can then reassign them all to DaveM as appropriate
Right - that makes sense ... I'll let Jon figure out the best way to acheive this inside bugzilla - Eric's suggestion of version would be nicer, but require some significant mods to bugzilla, I think. Failing that, your suggestion of a new product-type thing would be pretty easy to implement.
M.
Quoted 9 lines · Martin J. Bligh
Quoted 8 lines · Eric Northup
Quoted 4 lines
Would this be an appropriate use of the "version" tag in Bugzilla? Currently the only choice is "2.5", but if that were renamed to "2.5-linus", then the other heavily used patchsets could be monitored while making it easy for people who only want to see bugs in Linus' tree.
That works for me. Create a 2.5-ac product that is assigned to me. I can then reassign them all to DaveM as appropriate
Quoted 9 lines
Right - that makes sense ... I'll let Jon figure out the best way to acheive this inside bugzilla - Eric's suggestion of version would be nicer, but require some significant mods to bugzilla, I think. Failing that, your suggestion of a new product-type thing would be pretty easy to implement.
M.
What if we create a top level category called Patches(or something) and have a components under that for each tree, patch set. So anything thats not from Linus' tree could be put into one of these components. The natural owner for each of these components would be the maintainer of the named tree/patch. Perhaps that is what you are suggesting above and I have misread it?
Jon
Quoted 5 lines · [email protected] said:
Would this be an appropriate use of the "version" tag in Bugzilla? Currently the only choice is "2.5", but if that were renamed to "2.5-linus", then the other heavily used patchsets could be monitored while making it easy for people who only want to see bugs in Linus' tree.
Definitely. Properly used, bugzilla can track any number of kernel trees. You can craft bugzilla queries to only show you bugs against the versions you're interested in.
Jason
From: "Martin J. Bligh" <[email protected]>
Date: Thu, 14 Nov 2002 18:35:47 -0800
wouldn't you rather know of the breakage sooner rather than later?
It means I have to track multiple source trees, no thanks. I have enough trouble keeping up with what is actually in Linus's tree.
Recall when some random idiot broke sparc64 by mucking with free_area_init_node? Those changes had been sitting in -mm tree for a while ;-) (and yes, that was me).
When they get merged I'll deal with the carnage.
Quoted 9 lines · David S. Miller
From: "Martin J. Bligh" <[email protected]>
Date: Thu, 14 Nov 2002 18:35:47 -0800wouldn't you rather know of the breakage sooner rather than later?
It means I have to track multiple source trees, no thanks. I have enough trouble keeping up with what is actually in Linus's tree.
This may or may not help but it seems relevant. BK has uniq names for each changeset, we're fixing BK/Web so you can use the uniq names instead of the revs (which change out from under you).
So it should be possible to link the bug report with a changeset in Linus' tree if you want.
It's worth pointing out that if you can see the bug in a particular version of Linus' tree then *everyone* can see it by getting a copy of the tree as of that cset. BK guarentees that if you clone -r<rev> then you'll see exactly what anyone else saw as of that cset.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 6 lines · Martin J. Bligh
Hmmm ... I'm not sure that being that restrictive is going to help. Whilst bugs against any randomly patched version of the kernel probably aren't that interesting, things in major trees like -mm, -ac, -dj etc are likely going to end up in mainline sooner or later anyway ... wouldn't you rather know of the breakage sooner rather than later?
Simple answer:
Bugreports in specific patchsets / kernel trees should first be sent to the respective maintainer (mailing list, real person, distributor, whatever) and then be "filtered" by that person into the consolidated "vanilla" bugzilla.
Anything else is madness. (Anything else also won't fit into the support models of RH, SuSE, UL ...)
Sincerely,
Lars Marowsky-Brée <[email protected]>
Signature · 5 lines
Principal Squirrel SuSE Labs - Research & Development, SuSE Linux AG "If anything can go wrong, it will." "Chance favors the prepared (mind)." -- Capt. Edward A. Murphy -- Louis Pasteur
Quoted 1 line · Martin J. Bligh
Hmmm ... I'm not sure that being that restrictive is going to help.
Yes it is unless you create toplevel categories for bugs that are occuring on non-official kernel trees.
My expeience so far with this bug database has been that I just immediately close every bug assigned to me, here are two examples:
1) TCP crash with -mm2 patches --> known error in Andrew's patches
2) tcp_MSS doesn't compile --> already fixed in current BK tree
the list goes on and on, and the simple fact of the matter is that I have yet to see a _REAL_ bonified bug. If this is how this bug database is going to continue to be used by people, it's going to be of only limited usefullness to me.
Look, if #1 and #2 would have been posted to linux-kernel instead, the fact is that before I woke up and hit my email box SOMEONE ELSE would have responded and even sent that person a patch.
In this sense it appears that linux-kernel is more effective than thus bug database, ESPECIALLY if we are going to allow people to report bugs against trees with random patches applied.
Quoted 4 lines
Quoted 1 line
Hmmm ... I'm not sure that being that restrictive is going to help.
Yes it is unless you create toplevel categories for bugs that are occuring on non-official kernel trees.
This is now done, in response to your original comments.
Quoted 3 lines
Look, if #1 and #2 would have been posted to linux-kernel instead, the fact is that before I woke up and hit my email box SOMEONE ELSE would have responded and even sent that person a patch.
Right, but look at the flip side ... once that bug has been logged in bugzilla, the person who would have emailed lkml now has an easily searchable interface, and could have found the bug, found out what the patch for it was, and fixed it themselves, without ever bothering you, lkml, or anyone. I'm not saying that'll happen 100% of the time, but it should help overall ... will just take a short period whilst data builds up.
M.
Quoted 7 lines
Right, but look at the flip side ... once that bug has been logged in bugzilla, the person who would have emailed lkml now has an easily searchable interface, and could have found the bug, found out what the patch for it was, and fixed it themselves, without ever bothering you, lkml, or anyone. I'm not saying that'll happen 100% of the time, but it should help overall ... will just take a short period whilst data builds up.
Too much data and the data becomes noise.
I also think that if your goal is to make things progress more smoothly, adding work for people like dave is not a good plan.
This is not an easy problem space, on the one hand you want to have all bugs tracked, on the other hand, trivial bugs in the bug db just make the bug db unusable. No engineer is going to put up with 100,000 stupid bug reports. You need a plan to get rid of those or keep them out of the bugdb or it's unlikely to get used by the people who really need to use it.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Larry McVoy <[email protected]>
Date: Fri, 15 Nov 2002 13:23:04 -0800
This is not an easy problem space, on the one hand you want to have all bugs tracked, on the other hand, trivial bugs in the bug db just make the bug db unusable. No engineer is going to put up with 100,000 stupid bug reports. You need a plan to get rid of those or keep them out of the bugdb or it's unlikely to get used by the people who really need to use it.
Exactly.
It seems to me that only allowing one person to close a bug is going to be the big bottleneck in a project like this. There is no reason the community cannot close the bugs.
It isn't going to scale if it's just one person per category. That simply won't work.
So with that taken care of, basically the database begins to degenerate into a copy of linux-kernel with a nicer search engine :-)
Quoted 6 lines · Larry McVoy
This is not an easy problem space, on the one hand you want to have all bugs tracked, on the other hand, trivial bugs in the bug db just make the bug db unusable. No engineer is going to put up with 100,000 stupid bug reports. You need a plan to get rid of those or keep them out of the bugdb or it's unlikely to get used by the people who really need to use it.
Or the bugs could just be assigned to whoever owns the patchset ...
Gerhard
--
Gerhard Mack
<>< As a computer I find your faith in technology amusing.
Em Sat, Nov 16, 2002 at 02:10:13AM -0500, Gerhard Mack escreveu:
Quoted 9 lines · Larry McVoy
Quoted 6 lines
This is not an easy problem space, on the one hand you want to have all bugs tracked, on the other hand, trivial bugs in the bug db just make the bug db unusable. No engineer is going to put up with 100,000 stupid bug reports. You need a plan to get rid of those or keep them out of the bugdb or it's unlikely to get used by the people who really need to use it.
Or the bugs could just be assigned to whoever owns the patchset ...
or the tickets could just be closed after, say, one month without activity.
If it is really a bug it'll be resubmitted after a while, its not as we'll not have duplicates anyway...
- Arnaldo
Quoted 9 lines · Arnaldo Carvalho de Melo
Em Sat, Nov 16, 2002 at 02:10:13AM -0500, Gerhard Mack escreveu:
Quoted 7 lines · Larry McVoy
Quoted 6 lines
This is not an easy problem space, on the one hand you want to have all bugs tracked, on the other hand, trivial bugs in the bug db just make the bug db unusable. No engineer is going to put up with 100,000 stupid bug reports. You need a plan to get rid of those or keep them out of the bugdb or it's unlikely to get used by the people who really need to use it.
Quoted 7 lines
Quoted 1 line
Or the bugs could just be assigned to whoever owns the patchset ...
or the tickets could just be closed after, say, one month without activity.
If it is really a bug it'll be resubmitted after a while, its not as we'll not have duplicates anyway...
Very bad idea. People using unusual hardware do not want to keep re-submitting a bug report. I know when I submit a report I expect that it will remain until the problem is fixed. I do not like to receive multiple copies of a bug report so I don't submit multiple copies unless it's going to be helpful (like pointing out different versions that exhibit the problem). If I thought my report was just going to get dropped because the developer was busy that month I wouldn't bother to submit at all. I'd rather wait 6 months for a fix knowing that the report is still in the database than just have it dropped.
Signature · 7 lines
Murray J. Root ------------------------------------------------ DISCLAIMER: http://www.goldmark.org/jeff/stupid-disclaimers/ ------------------------------------------------ Mandrake on irc.freenode.net: #mandrake & #mandrake-linux = help for newbies #mdk-cooker = Mandrake Cooker
Em Sat, Nov 16, 2002 at 04:08:31PM -0500, Murray J. Root escreveu:
Quoted 12 lines · Arnaldo Carvalho de Melo
Quoted 11 lines
Em Sat, Nov 16, 2002 at 02:10:13AM -0500, Gerhard Mack escreveu:
Quoted 9 lines · Larry McVoy
Quoted 6 lines
This is not an easy problem space, on the one hand you want to have all bugs tracked, on the other hand, trivial bugs in the bug db just make the bug db unusable. No engineer is going to put up with 100,000 stupid bug reports. You need a plan to get rid of those or keep them out of the bugdb or it's unlikely to get used by the people who really need to use it.
Or the bugs could just be assigned to whoever owns the patchset ...
Quoted 8 lines
Quoted 4 lines
or the tickets could just be closed after, say, one month without activity.
If it is really a bug it'll be resubmitted after a while, its not as we'll not have duplicates anyway...
Very bad idea. People using unusual hardware do not want to keep re-submitting a bug report. I know when I submit a report I expect that it will remain until the problem is fixed. I do not like to receive multiple
Oh well, there is _no_ guarantee that it will be fixed, sometimes there is no maintainer at all and the ticket will stay there forever lost in the noise... And if anybody is interested in fixing the driver or even looking to see if somebody submitted a ticket he/she can just search for all tickets, even the ones closed because nobody is did any activity in a perior of one month (or any other timeout period).
Its not like the ticket will vanish from the database.
- Arnaldo
Quoted 13 lines
Quoted 4 lines
Very bad idea. People using unusual hardware do not want to keep re-submitting a bug report. I know when I submit a report I expect that it will remain until the problem is fixed. I do not like to receive multiple
Oh well, there is _no_ guarantee that it will be fixed, sometimes there is no maintainer at all and the ticket will stay there forever lost in the noise...
And if anybody is interested in fixing the driver or even looking to see if somebody submitted a ticket he/she can just search for all tickets, even the ones closed because nobody is did any activity in a perior of one month (or any other timeout period).
Quoted 1 line
Its not like the ticket will vanish from the database.
One thing we've done before in other bug-tracking systems was to create a "STALE" state (or something similar) for this type of bug. So it wouldn't get closed (I have seen this done as a closing resolution, but I think that's a bad idea), but it wouldn't be in the default searches either ... you could just select it if you wanted it ... does that sound sane? (obviously we don't need this yet, but might be a good plan longer-term).
M.
Em Sat, Nov 16, 2002 at 01:44:19PM -0800, Martin J. Bligh escreveu:
Quoted 15 lines
Quoted 13 lines
Quoted 4 lines
Very bad idea. People using unusual hardware do not want to keep re-submitting a bug report. I know when I submit a report I expect that it will remain until the problem is fixed. I do not like to receive multiple
Oh well, there is _no_ guarantee that it will be fixed, sometimes there is no maintainer at all and the ticket will stay there forever lost in the noise...
And if anybody is interested in fixing the driver or even looking to see if somebody submitted a ticket he/she can just search for all tickets, even the ones closed because nobody is did any activity in a perior of one month (or any other timeout period).Quoted 1 line
Its not like the ticket will vanish from the database.
Quoted 7 lines
One thing we've done before in other bug-tracking systems was to create a "STALE" state (or something similar) for this type of bug. So it wouldn't get closed (I have seen this done as a closing resolution, but I think that's a bad idea), but it wouldn't be in the default searches either ... you could just select it if you wanted it ... does that sound sane? (obviously we don't need this yet, but might be a good plan longer-term).
looks sane, the idea is that automatically bugzilla would move things that didn't had any activity to a state that doesn't appears on the default searches, this can help with dups as well, only the most recent duplicates would, over time, appear on the default searches. And the others would remain in STALE mode forever. STALE for over a year? CLOSED STALE. 8) And even then it would be in the database...
- Arnaldo
Quoted 15 lines · Martin J. Bligh
Quoted 13 lines
Quoted 4 lines
Very bad idea. People using unusual hardware do not want to keep re-submitting a bug report. I know when I submit a report I expect that it will remain until the problem is fixed. I do not like to receive multiple
Oh well, there is _no_ guarantee that it will be fixed, sometimes there is no maintainer at all and the ticket will stay there forever lost in the noise...
And if anybody is interested in fixing the driver or even looking to see if somebody submitted a ticket he/she can just search for all tickets, even the ones closed because nobody is did any activity in a perior of one month (or any other timeout period).Quoted 1 line
Its not like the ticket will vanish from the database.
Quoted 8 lines
One thing we've done before in other bug-tracking systems was to create a "STALE" state (or something similar) for this type of bug. So it wouldn't get closed (I have seen this done as a closing resolution, but I think that's a bad idea), but it wouldn't be in the default searches either ... you could just select it if you wanted it ... does that sound sane? (obviously we don't need this yet, but might be a good plan longer-term).
Sounds like a good idea to me.
Signature · 7 lines
Murray J. Root ------------------------------------------------ DISCLAIMER: http://www.goldmark.org/jeff/stupid-disclaimers/ ------------------------------------------------ Mandrake on irc.freenode.net: #mandrake & #mandrake-linux = help for newbies #mdk-cooker = Mandrake Cooker
Quoted 16 lines · Martin J. Bligh
Quoted 13 lines
Quoted 4 lines
Very bad idea. People using unusual hardware do not want to keep re-submitting a bug report. I know when I submit a report I expect that it will remain until the problem is fixed. I do not like to receive multiple
Oh well, there is _no_ guarantee that it will be fixed, sometimes there is no maintainer at all and the ticket will stay there forever lost in the noise...
And if anybody is interested in fixing the driver or even looking to see if somebody submitted a ticket he/she can just search for all tickets, even the ones closed because nobody is did any activity in a perior of one month (or any other timeout period).Quoted 1 line
Its not like the ticket will vanish from the database.
Quoted 7 lines
One thing we've done before in other bug-tracking systems was to create a "STALE" state (or something similar) for this type of bug. So it wouldn't get closed (I have seen this done as a closing resolution, but I think that's a bad idea), but it wouldn't be in the default searches either ... you could just select it if you wanted it ... does that sound sane? (obviously we don't need this yet, but might be a good plan longer-term).
Personally... if they really are bugs, I would rather keep them open, even in the absence of a maintainer... maybe that's not scalable, but I would rather not auto-expire things which really are bugs. The maintainer (or "someone who cares") may not appear until the next stable series, for example. Vendors do that alot.
'stale' may be a decent compromise if people disagree with my logic, though...
Jeff
Em Sat, Nov 16, 2002 at 04:54:58PM -0500, Jeff Garzik escreveu:
Quoted 10 lines
Quoted 7 lines · Martin J. Bligh
One thing we've done before in other bug-tracking systems was to create a "STALE" state (or something similar) for this type of bug. So it wouldn't get closed (I have seen this done as a closing resolution, but I think that's a bad idea), but it wouldn't be in the default searches either ... you could just select it if you wanted it ... does that sound sane? (obviously we don't need this yet, but might be a good plan longer-term).
Quoted 5 lines
Personally... if they really are bugs, I would rather keep them open,
even in the absence of a maintainer... maybe that's not scalable, but
I would rather not auto-expire things which really are bugs. The maintainer (or "someone who cares") may not appear until the next stable series, for example. Vendors do that alot.
Jeff, ok, so we could do as vendors: mark the ticket as LATER, or whatever that doesnt make clearly stale tickets that nobody is looking appear on the default queries.
If somebody is _so_ interested in a particular feature he/she can look for tickets marked LATER, add comments and state that he/she is working on it, provide more info, etc.
Quoted 2 lines
'stale' may be a decent compromise if people disagree with my logic, though...
:-)
- Arnaldo
From: "Martin J. Bligh" <[email protected]>
Date: Fri, 15 Nov 2002 14:11:56 -0800
Right, but look at the flip side ... once that bug has been logged in bugzilla, the person who would have emailed lkml now has an easily searchable interface, and could have found the bug, found out what the patch for it was, and fixed it themselves, without ever bothering you, lkml, or anyone. I'm not saying that'll happen 100% of the time, but it should help overall ... will just take a short period whilst data builds up.
I'm more concerned about the inevitable explosion of duplicates and "fixed already"'s.
This is why a lot of people warned early on, and were wary about, having someone full time managing and watching over this bug database. It is specifically to deal with dups and things of this nature.
I don't want to be concerned about spending each morning closing a screenful of dups or "fixed already" reports. Then the bug database isn't helping me, it's rather making more work for me.
This work is someone else's job. On linux-kernel, we have a "someone else" to do this already, the entire readership of linux-kernel. :-)
In bugzilla however, all of this work now must be done by whoever at OSDL is watching over the bugzilla database all day long and _ME_. That is an inefficient use of resources.
Even if the whole readership of linux-kernel moved over and started watching over the bug database as they do now with the lists, that still leaves tons of work for me because only I can click on the "CLOSE" button for the bug report. I want the whole readership of linux-kernel to have this capability, to close the bug. This way I can do what I do with linux-kernel when I'm just too damn busy to read that day's posting, hit the big delete key.
Quoted 11 lines
I'm more concerned about the inevitable explosion of duplicates and "fixed already"'s.
This is why a lot of people warned early on, and were wary about, having someone full time managing and watching over this bug database. It is specifically to deal with dups and things of this nature.
I don't want to be concerned about spending each morning closing a screenful of dups or "fixed already" reports. Then the bug database isn't helping me, it's rather making more work for me.
Quoted 6 lines
This work is someone else's job. On linux-kernel, we have a "someone else" to do this already, the entire readership of linux-kernel. :-)
In bugzilla however, all of this work now must be done by whoever at OSDL is watching over the bugzilla database all day long and _ME_. That is an inefficient use of resources.
OK, the easy way to fix this is to change the default owner for the category to someone else who can filter the bugs as they arrive in "OPEN" state. After filtering, they can be moved to "ASSIGNED" state, and the owner changed to you ... how does that sound?
M.
From: "Martin J. Bligh" <[email protected]>
Date: Fri, 15 Nov 2002 14:22:28 -0800
OK, the easy way to fix this is to change the default owner for the category to someone else who can filter the bugs as they arrive in "OPEN" state. After filtering, they can be moved to "ASSIGNED" state, and the owner changed to you ... how does that sound?
This funnels the work to two people, it's still wildly inefficient.
What is so difficult about allowing anyone to review and close a bug?
Quoted 1 line · David S. Miller
What is so difficult about allowing anyone to review and close a bug?
Does Buzilla have some "undo everything Jerry Erk did recently" feature ? If not, the incompetent and the practical jokers might become a problem.
- Werner
Signature · 3 lines
_________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina [email protected] / /_http://www.almesberger.net/____________________________________________/
Quoted 6 lines · Werner Almesberger
Quoted 1 line · David S. Miller
What is so difficult about allowing anyone to review and close a bug?
Does Buzilla have some "undo everything Jerry Erk did recently" feature ? If not, the incompetent and the practical jokers might become a problem.
There's a good example extant where this isn't a problem: Wikipedia. In their example, vandalism increases, but so does clean-up. Dave's idea lets us scale the number of Bugzilla janitors. We won't get perfect scaling, but it's much better than not scaling.
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 2 lines · Oliver Xymoron
There's a good example extant where this isn't a problem: Wikipedia. In their example, vandalism increases, but so does clean-up.
Oh, don't get me wrong - I'm not advocating iron-clad control with a big bureaucracy. I simply suspect that the clean-up might be a lot more work that the act of stupidity. (So, if Bugzilla doesn't already track actions by user, with some convenient batch undo function, this would be a feature request :-)
- Werner
Signature · 3 lines
_________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina [email protected] / /_http://www.almesberger.net/____________________________________________/
Quoted 4 lines
There's a good example extant where this isn't a problem: Wikipedia. In their example, vandalism increases, but so does clean-up. Dave's idea lets us scale the number of Bugzilla janitors. We won't get perfect scaling, but it's much better than not scaling.
I'm all for scaling the number of janitors, but not to any random moron with an easily created free email address. And it's not just malicious damage, it's too easy for people to close of things as duplicates because they look similar-ish. People need to have a certain level of skill and trust - I'm not going to open this up into a total free-for-all.
M.
Quoted 11 lines · Oliver Xymoron
Quoted 7 lines · Werner Almesberger
Quoted 1 line · David S. Miller
What is so difficult about allowing anyone to review and close a bug?
Does Buzilla have some "undo everything Jerry Erk did recently" feature ? If not, the incompetent and the practical jokers might become a problem.
Quoted 5 lines
There's a good example extant where this isn't a problem: Wikipedia. In their example, vandalism increases, but so does clean-up. Dave's idea lets us scale the number of Bugzilla janitors. We won't get perfect scaling, but it's much better than not scaling.
Changes to wiki's are version controlled, with links to those versions, so it's a simple matter to revert the vandalism... less work than the vandalism itself. Is the same true for bugzilla?
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
Quoted 18 lines · Eli Carter
Quoted 11 lines · Oliver Xymoron
Quoted 7 lines · Werner Almesberger
Quoted 1 line · David S. Miller
What is so difficult about allowing anyone to review and close a bug?
Does Buzilla have some "undo everything Jerry Erk did recently" feature ? If not, the incompetent and the practical jokers might become a problem.
Quoted 5 lines
There's a good example extant where this isn't a problem: Wikipedia. In their example, vandalism increases, but so does clean-up. Dave's idea lets us scale the number of Bugzilla janitors. We won't get perfect scaling, but it's much better than not scaling.
Quoted 3 lines
Changes to wiki's are version controlled, with links to those versions, so it's a simple matter to revert the vandalism... less work than the vandalism itself. Is the same true for bugzilla?
Yes, simply close or reopen bugs. Anyone can still submit bugs, so it's not as if there wasn't already a ripe outlet for vandalism. I don't see that opening up the rest of the system makes this worse..
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 8 lines
OK, the easy way to fix this is to change the default owner for the category to someone else who can filter the bugs as they arrive in "OPEN" state. After filtering, they can be moved to "ASSIGNED" state, and the owner changed to you ... how does that sound?
This funnels the work to two people, it's still wildly inefficient.
What is so difficult about allowing anyone to review and close a bug?
That might work if it's open to a set of trusted maintainers (eg. the set of current bugzilla subsystem maintainers), but I don't think totally open universal access is a good idea. A pool of people is probably the way to go here.
M.
Quoted 6 lines · Martin J. Bligh
Hmmm ... I'm not sure that being that restrictive is going to help. Whilst bugs against any randomly patched version of the kernel probably aren't that interesting, things in major trees like -mm, -ac, -dj etc are likely going to end up in mainline sooner or later anyway ... wouldn't you rather know of the breakage sooner rather than later?
Unfortunately that doesn't scale well, and introduces all sorts of potential red herrings in bug reports... should I be handling bug reports for OSDL's Carrier Grade Linux branch, for example? ;-) and we've seen that there are patches in these various trees are often intentionally kept out of mainline for various reasons.
I'm definitely going to close net driver bug reports which aren't against mainline, without regards to their contents or value...
I thought this database was going to be used to stabalize 2.5... not provide a vehicle for further time wastage and distraction :)
Jeff