The bugzilla database we proposed earlier is now available for
use, hosted by OSDL.
http://bugme.osdl.org
Feel free to go ahead and create yourself an account, and log
bugs in there. This is only for 2.5 bugs currently, and the main
intent is to help us drive 2.5 into a timely and stable 2.6 (or 3.0).
Please let me or the supplied mailto URLs know of any problems you
encounter, but please be patient with any inital teething problems
and don't tell slashdot just yet ;-) Apologies for this not being
ready quite at Halloween ... and there's not much data in there
right now, but we'll keep feeding it over the coming few days,
including importing Thomas Molina's list of bugs.
The categories probably need some more work, they'll evolve as
bugs get logged. The reason I own huge numbers of subsystems is
not just because I'm a derranged megalomaniac, it's more to do
with the fact that I don't have other people available with
accounts created to own them. Brave volunteers who've created an
account would be most welcome, ideally the code maintainers for
those subsystems, but other people familiar with those areas would
be a great substitute. ;-)
M.
Martin J. Bligh wrote:
> The bugzilla database we proposed earlier is now available for
> use, hosted by OSDL.
>
> http://bugme.osdl.org
>
> Feel free to go ahead and create yourself an account, and log
> bugs in there. This is only for 2.5 bugs currently, and the main
> intent is to help us drive 2.5 into a timely and stable 2.6 (or 3.0).
Fantastic, thanks.
If people have net driver bugs, feel free to report them to the above
URL, and assign them to me...
Martin J. Bligh wrote:
> The bugzilla database we proposed earlier is now available for
> use, hosted by OSDL.
>
> http://bugme.osdl.org
I forgot to mention, it would IMO speed acceptance and increase usage if
this was a vendor-neutral URL, like 'bugzilla.kernel.org'...
Jeff
>> The bugzilla database we proposed earlier is now available for
>> use, hosted by OSDL.
>>
>> http://bugme.osdl.org
>>
>> Feel free to go ahead and create yourself an account, and log
>> bugs in there. This is only for 2.5 bugs currently, and the main
>> intent is to help us drive 2.5 into a timely and stable 2.6 (or 3.0).
>
>
> Fantastic, thanks.
>
> If people have net driver bugs, feel free to report them to the
> above URL, and assign them to me...
You should now be the default owner for net driver bugs. Still looking
for other willing owners ;-)
M.
>> The bugzilla database we proposed earlier is now available for
>> use, hosted by OSDL.
>>
>> http://bugme.osdl.org
>
> I forgot to mention, it would IMO speed acceptance and increase usage
> if this was a vendor-neutral URL, like 'bugzilla.kernel.org'...
Though OSDL may be funded by a group of large companies, in practice
they're vendor neutral for this sort of thing. I suspect any requests
to Tim to remove all hardware categories that wasn't from vendor X,
or anything equally ridiculous would just result in a hefty poke in
the eye ;-) Also, I think it's polite to give them the recognition they
deserve for hosting the site, and providing the machine in runs on.
I believe we have a common goal here ... to get 2.6 to be released in
a timely fashion, and to be as stable as possible.
M.
On Thu, 2002-11-14 at 10:21, Martin J. Bligh wrote:
> >> The bugzilla database we proposed earlier is now available for
> >> use, hosted by OSDL.
> >>
> >> http://bugme.osdl.org
> >
> > I forgot to mention, it would IMO speed acceptance and increase usage
> > if this was a vendor-neutral URL, like 'bugzilla.kernel.org'...
>
> Though OSDL may be funded by a group of large companies, in practice
> they're vendor neutral for this sort of thing. I suspect any requests
> to Tim to remove all hardware categories that wasn't from vendor X,
> or anything equally ridiculous would just result in a hefty poke in
> the eye ;-) Also, I think it's polite to give them the recognition they
> deserve for hosting the site, and providing the machine in runs on.
>
I suspect that there would be blood on the Internet before that
sort of request would get through.
Of course a link from bugzilla,kernel.org is easy. :-)
> I believe we have a common goal here ... to get 2.6 to be released in
> a timely fashion, and to be as stable as possible.
>
Works for me.
> M.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Timothy D. Witham - Lab Director - [email protected]
Open Source Development Lab Inc - A non-profit corporation
15275 SW Koll Parkway - Suite H - Beaverton OR, 97006
(503)-626-2455 x11 (office) (503)-702-2871 (cell)
(503)-626-2436 (fax)
>> The bugzilla database we proposed earlier is now available for
>> use, hosted by OSDL.
>>
>> http://bugme.osdl.org
>
> I forgot to mention, it would IMO speed acceptance and increase usage if
> this was a vendor-neutral URL, like 'bugzilla.kernel.org'...
OSDL is vendor neutral, by definition. Besides, we all know
that Transmeta hosts ftp.kernel.org and Red Hat hosts vger
(for varying definitions of "hosts", but you know what I mean).
I do not see acceptance suffer, because we do not observe
Transmeta or Red Hat pushing their agendas. Same with OSDL.
I'm more interested in contacting the admin to be a component
owner for sparc, for instance. Someone is going to have a significant
admin load, because Bugzilla is not going to be self-running.
Who is that person?
-- Pete
Pete Zaitcev wrote:
> >>The bugzilla database we proposed earlier is now available for
> >>use, hosted by OSDL.
> >>
> >>http://bugme.osdl.org
> >
> >I forgot to mention, it would IMO speed acceptance and increase usage if
> >this was a vendor-neutral URL, like 'bugzilla.kernel.org'...
>
>
> OSDL is vendor neutral, by definition. Besides, we all know
> that Transmeta hosts ftp.kernel.org and Red Hat hosts vger
> (for varying definitions of "hosts", but you know what I mean).
> I do not see acceptance suffer, because we do not observe
> Transmeta or Red Hat pushing their agendas. Same with OSDL.
Sure, but vger and ftp are both suffixed with "kernel.org" If
Transmeta or Red Hat ever flake out, it's easier to redirect the domain
to some other machine.
If nothing else it's consistent naming that keeps with the Principle of
Least Surprise :)
> I'm more interested in contacting the admin to be a component
> owner for sparc, for instance. Someone is going to have a significant
> admin load, because Bugzilla is not going to be self-running.
> Who is that person?
Check out Martin's original announcement, as well as his recent one.
I'm pretty pleased: they have staff that will help triage bugs and keep
the garbage level low. Hopefully leaving the kernel hackers to do
nothing more than fix bugs :)
Jeff
> Date: Thu, 14 Nov 2002 14:36:09 -0500
> From: Jeff Garzik <[email protected]>
>[...]
> Sure, but vger and ftp are both suffixed with "kernel.org" If
> Transmeta or Red Hat ever flake out, it's easier to redirect the domain
> to some other machine.
You are right, I forgot about this aspect. My fingers typed
"vger.rutgerds.edu" for a about a year, all by themselves.
> > I'm more interested in contacting the admin to be a component
> > owner for sparc, for instance. Someone is going to have a significant
> > admin load, because Bugzilla is not going to be self-running.
> > Who is that person?
>
> Check out Martin's original announcement, as well as his recent one.
> I'm pretty pleased: they have staff that will help triage bugs and keep
> the garbage level low. Hopefully leaving the kernel hackers to do
> nothing more than fix bugs :)
No, wait, I'm not talking about triage here, just admining the
Bugzilla itself. I'll poke bugme-admin@ and see what comes out.
-- Pete
Pete Zaitcev wrote:
> No, wait, I'm not talking about triage here, just admining the
> Bugzilla itself. I'll poke bugme-admin@ and see what comes out.
There _should_ be a live person doing that, but ping Martin as well if
bugme-admin doesn't answer... :)
On Thu, 2002-11-14 at 10:04, Martin J. Bligh wrote:
> > If people have net driver bugs, feel free to report them to the
> > above URL, and assign them to me...
>
> You should now be the default owner for net driver bugs. Still looking
> for other willing owners ;-)
Please assign the other networking categories to [email protected]
thanks.
> I'm more interested in contacting the admin to be a component
> owner for sparc, for instance. Someone is going to have a significant
Not sure quite what you mean here ... if you want to volunteer to
maintain a specific subsection, you can just email me or
[email protected].
> admin load, because Bugzilla is not going to be self-running.
> Who is that person?
I'm hoping to spread the admin load out amongst different people -
one of the things for a system like this is that it's easier to scale
it up by spreading the load. Anything that's not picked up by external
people will have the slack picked up by some IBM people, to make sure
the database doesn't end up as a fetid cesspit of festering stale
misinformation ;-)
M.
Em Thu, Nov 14, 2002 at 12:11:14PM -0800, David S. Miller escreveu:
> On Thu, 2002-11-14 at 10:04, Martin J. Bligh wrote:
> > > If people have net driver bugs, feel free to report them to the
> > > above URL, and assign them to me...
> >
> > You should now be the default owner for net driver bugs. Still looking
> > for other willing owners ;-)
>
> Please assign the other networking categories to [email protected]
> thanks.
Hey boss, if you accept I can take care of the ones for
net/{ipx,llc,appletalk,x25,lapb}
:-)
- Arnaldo
Martin J. Bligh wrote:
> >I'm more interested in contacting the admin to be a component
> >owner for sparc, for instance. Someone is going to have a significant
>
>
> Not sure quite what you mean here ... if you want to volunteer to
> maintain a specific subsection, you can just email me or
> [email protected].
Yep, that's what he meant (further clarified locally on IRC)...
zaitcev->sparc32 bugs, and davem->sparc64 bugs.
> >admin load, because Bugzilla is not going to be self-running.
> >Who is that person?
>
>
> I'm hoping to spread the admin load out amongst different people -
> one of the things for a system like this is that it's easier to scale
> it up by spreading the load. Anything that's not picked up by external
> people will have the slack picked up by some IBM people, to make sure
> the database doesn't end up as a fetid cesspit of festering stale
> misinformation ;-)
I just re-assigned a bug, which generated a request in my mind: is
there a default bug assignee besides you? :)
Jeff
Would it be useful/desirable/possible to have a button in the defect to
allow you to forward the important info about it to an email address?
For instance, if I wanted to bring it to the attention of linux-mm?
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.
-Paul Larson
>> On Thu, 2002-11-14 at 10:04, Martin J. Bligh wrote:
>> > > If people have net driver bugs, feel free to report them to the
>> > > above URL, and assign them to me...
>> >
>> > You should now be the default owner for net driver bugs. Still looking
>> > for other willing owners ;-)
>>
>> Please assign the other networking categories to [email protected]
>> thanks.
>
> Hey boss, if you accept I can take care of the ones for
>
> net/{ipx,llc,appletalk,x25,lapb}
We didn't bother breaking those out as they're .... ummm ... obscure,
and I wasn't desperately keen to end up with 10,000 categories ;-)
They should get dumped into "networking, other" at the moment.
These are just the default owners, so bugs can just get reassigned
to somebody else if that suits ...
M.
On Thu, 2002-11-14 at 16:42, Paul Larson wrote:
> 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_.
Robert Love
> Yep, that's what he meant (further clarified locally on IRC)... zaitcev->sparc32 bugs, and davem->sparc64 bugs.
OK, I'll get that fixed up.
>> > admin load, because Bugzilla is not going to be self-running.
>> > Who is that person?
>>
>> I'm hoping to spread the admin load out amongst different people -
>> one of the things for a system like this is that it's easier to scale
>> it up by spreading the load. Anything that's not picked up by external
>> people will have the slack picked up by some IBM people, to make sure
>> the database doesn't end up as a fetid cesspit of festering stale
>> misinformation ;-)
>
> I just re-assigned a bug, which generated a request in my mind: is
> there a default bug assignee besides you? :)
The default assignee depends on the category you file into.
I own a lot of them right now because there's nobody else to do it
(though I have various volounteers now, so thats increasingly less
true ...yay!).
M.
Em Thu, Nov 14, 2002 at 02:57:15PM -0800, Martin J. Bligh escreveu:
> >> On Thu, 2002-11-14 at 10:04, Martin J. Bligh wrote:
> >> > > If people have net driver bugs, feel free to report them to the
> >> > > above URL, and assign them to me...
> >> >
> >> > You should now be the default owner for net driver bugs. Still looking
> >> > for other willing owners ;-)
> >>
> >> Please assign the other networking categories to [email protected]
> >> thanks.
> >
> > Hey boss, if you accept I can take care of the ones for
> >
> > net/{ipx,llc,appletalk,x25,lapb}
>
> We didn't bother breaking those out as they're .... ummm ... obscure,
OK, I guessed that perhaps the reason for creating a category was if
there was an active maintainer willing to actually look at the tickets
for these a subsystem :-)
> and I wasn't desperately keen to end up with 10,000 categories ;-)
Agreed, do it as you're doing now or as when somebody explicitely asks because
he maintains the thing and will work on respective tickets opened
> They should get dumped into "networking, other" at the moment.
No problem
> These are just the default owners, so bugs can just get reassigned
> to somebody else if that suits ...
networking, other (or 'obscure' ;-)) can come to me, if nobody objects, I'll
reassign if needed.
Just trying to find a way to help divide the load on the triage stage 8)
- Arnaldo
Martin J. Bligh wrote:
> >I'm more interested in contacting the admin to be a component
> >owner for sparc, for instance. Someone is going to have a significant
>
>
> Not sure quite what you mean here ... if you want to volunteer to
> maintain a specific subsection, you can just email me or
> [email protected].
Yep, that's what he meant (further clarified locally on IRC)...
zaitcev->sparc32 bugs, and davem->sparc64 bugs.
> >admin load, because Bugzilla is not going to be self-running.
> >Who is that person?
>
>
> I'm hoping to spread the admin load out amongst different people -
> one of the things for a system like this is that it's easier to scale
> it up by spreading the load. Anything that's not picked up by external
> people will have the slack picked up by some IBM people, to make sure
> the database doesn't end up as a fetid cesspit of festering stale
> misinformation ;-)
I just re-assigned a bug, which generated a request in my mind: is
there a default bug assignee besides you? :)
Jeff
>> and I wasn't desperately keen to end up with 10,000 categories ;-)
>
> Agreed, do it as you're doing now or as when somebody explicitely asks because
> he maintains the thing and will work on respective tickets opened
Right. If we get a load on any one area, that should definitely be
broken out as a subsection.
>> They should get dumped into "networking, other" at the moment.
>
> No problem
>
>> These are just the default owners, so bugs can just get reassigned
>> to somebody else if that suits ...
>
> networking, other (or 'obscure' ;-)) can come to me, if nobody objects, I'll
> reassign if needed.
>
> Just trying to find a way to help divide the load on the triage stage 8)
Cool ... well one way to do that would be to take over "Networking, other"
if everyone's OK with that. I wasn't anticipating much of a load on the
more obscure networking stuff, but I'm proved wrong on a regular basis
about so many things ... ;-)
M.
>On Thu, 2002-11-14 at 16:42, Paul Larson wrote:
>
>> 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,
--
Nicolas Mailhot <[email protected]>
From: "Martin J. Bligh" <[email protected]>
Date: Thu, 14 Nov 2002 15:22:02 -0800
> Just trying to find a way to help divide the load on the triage stage 8)
Cool ... well one way to do that would be to take over "Networking, other"
if everyone's OK with that. I wasn't anticipating much of a load on the
more obscure networking stuff, but I'm proved wrong on a regular basis
about so many things ... ;-)
Let Arnaldo take net/other, I'm totally fine with it.
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.
Martin J. Bligh wrote:
> Please let me or the supplied mailto URLs know of any problems you
> encounter, but please be patient with any inital teething problems
> and don't tell slashdot just yet ;-)
Well, someone didn't listen....it's on slashdot.
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [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.
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.
Martin J. Bligh wrote:
> 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
"Martin J. Bligh" wrote:
>
> > 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.
>
> 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.
On Thursday 14 November 2002 09:35 pm, Martin J. Bligh wrote:
> > 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
> 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
On Thu, 14 Nov 2002, Andrew Morton wrote:
> "Martin J. Bligh" wrote:
> >
> > > 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.
> >
> > 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.
>
> 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.
Thomas Molina wrote:
>
> ...
> 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.
> 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.
> 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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 15 Nov 2002 14:43, Thomas Molina wrote:
> 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-----
On Thu, 14 Nov 2002, Thomas Molina wrote:
> On Thu, 14 Nov 2002, Andrew Morton wrote:
>
> > "Martin J. Bligh" wrote:
> > >
> > > > 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.
> > >
> > > 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.
> >
> > 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.
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
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.
Jeff Garzik wrote:
>> I'm more interested in contacting the admin to be a component
>> owner for sparc, for instance. Someone is going to have a significant
>> admin load, because Bugzilla is not going to be self-running.
>> Who is that person?
>
>Check out Martin's original announcement, as well as his recent one.
>I'm pretty pleased: they have staff that will help triage bugs and keep
>the garbage level low. Hopefully leaving the kernel hackers to do
>nothing more than fix bugs :)
Since people asked, I'd like to introduce myself as part of the
"staff" that has volunteered some free time devoting to maintaining
this Bugzilla; i.e., keeping the database well-groomed. My team
actually consists of folks in different IBM locations and time zones:
Austin, Texas; Poughkeepsie, New York; Beaverton, Oregon; Bangalore,
India, so hopefully, we can keep an "eye" on the database around the
clock. For the past two years, my team has been working Linux
bugs and contributed bug fixes in support of our internal teams,
and now, we have volunteered to help maintain this kernel bug
database in our free time. However, we expect that the bug
volume logged will be high, so the more people in the community
volunteer to help us maintain the database, the better.
Please let us know if you like to volunteer and the Bugzilla
administrator will give you enough "power" to do the job
(e.g., assigning bugs, closing bugs, screening bugs for
duplicates, invalid bugs, etc.).
Also if you have already used this kernel Bugzilla database,
you might have noticed that many components are currently
owned by Martin or myself. As Martin pointed out in his
announcement, this is not because we are "egomaniacs", but
rather because the rightful owners (or those who know enough
about these components and want to volunteer to work bugs)
have not been registered yet. Martin and I will try our best
to turn over these components to their rightful "owners"
as soon as we can. We are still learning the "ropes" on
how to do this effectively, so it will take some time
(not too long we hope). Thanks.
Khoa Huynh
On 2002-11-14T18:35:47,
"Martin J. Bligh" <[email protected]> said:
> 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]>
--
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
Eric Northup wrote:
>>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.
Analogous though slightly different suggestion: have a "Tree" column
just where Mozilla have their (quite analogous) "OpSys" field. Compare
http://bugme.osdl.org/queryhelp.cgi#bugsettings
http://bugzilla.mozilla.org/queryhelp.cgi#bugsettings
This way people can set their queries, and triagers manage triage, in
such a way that nothing shows on anyone's radar until it's actually
relevant to them. (Whether a tree appears in the list would be up to its
maintainer, I guess.)
Caveat: although *queries* for (say) "-ac OR -dj" are possible, the
fields themselves are still single-valued. So there ought to be an
agreement that a bug doesn't get promoted to "All" trees just because
it's been confirmed on more than one.
(This has been a recurring problem in Mozilla -- e.g. people have tended
to flag PPC bugs against "All" OSes when they only meant Apple OSes, not
NetBSD or Linux PPC. Multi-valuedness would be the clean solution but
unfortunately, afaik, Bugzilla doesn't support it for those fields.)
On Fri, 2002-11-15 at 02:53, Eric Northup wrote:
> 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
Dear diary, on Thu, Nov 14, 2002 at 11:09:15PM CET, I got a letter,
where Robert Love <[email protected]> told me, that...
> On Thu, 2002-11-14 at 16:42, Paul Larson wrote:
>
> > 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_.
What about using the bugzilla email gateway? While it would be feasible that
bugs should be added through the web interface, why not to automagically
forward changes (new comments, attachments, maybe also status?) to appropriate
mailing lists and absorb the replies to the thread back to bugzilla as the new
comments? Ok, this would require people to cut the Cc soon enough not to stack
100-messages thread slowly evolving to completely different topic into bugzilla
;-).
If there is an interest in this and noone else is overly keen to do it, I would
be willing to investigate this and check the functionality of the email gateway
in bugzilla's contrib/ and possibly extend/fix it for our usage.
--
Petr "Pasky" Baudis
.
weapon, n.:
An index of the lack of development of a culture.
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/
On Thu, Nov 14, 2002 at 11:11:47PM -0800, David S. Miller wrote:
> 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.
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.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Fri, 2002-11-15 at 09:15, Alan Cox wrote:
> On Fri, 2002-11-15 at 02:53, Eric Northup wrote:
> > 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
Khoa Huynh wrote:
> Also if you have already used this kernel Bugzilla database,
> you might have noticed that many components are currently
> owned by Martin or myself. As Martin pointed out in his
> announcement, this is not because we are "egomaniacs", but
> rather because the rightful owners (or those who know enough
> about these components and want to volunteer to work bugs)
> have not been registered yet. Martin and I will try our best
> to turn over these components to their rightful "owners"
> as soon as we can. We are still learning the "ropes" on
> how to do this effectively, so it will take some time
> (not too long we hope). Thanks.
IMO it would probably be better for you two if all bugs without "real"
owners had bugs assigned to [email protected], or something
like that. That will not only ease useless emails sent to you and
Martin and other admins, but also make it easier for kernel hackers to
figure out which bugs are _really_ unassigned and need owners.
Jeff
> On Fri, 2002-11-15 at 02:53, Eric Northup wrote:
>> 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.
>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.
Yes, this is great! We can create a separate field in the bug reports to
contain this unique names, so we can reference the cset directly from
the bug reports. This allows us to link bug reports to csets -- great!
What format will these unique names be in? If we put them in the bug
reports,
can we click on them (as URLs) and get to the csets directly?
Thanks.
Khoa
On Fri, Nov 15, 2002 at 10:23:19AM -0600, Khoa Huynh wrote:
> Yes, this is great! We can create a separate field in the bug reports to
> contain this unique names, so we can reference the cset directly from
> the bug reports. This allows us to link bug reports to csets -- great!
>
> What format will these unique names be in? If we put them in the bug
> reports,
> can we click on them (as URLs) and get to the csets directly?
That's the goal. I'm hacking on it it currently, we have some issues with
how it works today, I'll try and get a bk-3.0.1 release out the door which
fixes them.
The current format is may be seen with a
bk changes -k -r<rev>
where <rev> is the changeset revision you want. You'll get something like
this:
[email protected]|ChangeSet|20021115061315|00914
That's sort of big and ugly, and it currently doesn't work as a name
in BK/Web. I'm debugging an implementation of md5 sums of the above
to see if we can use that instead. I'll let you know as soon as I
have something which works.
Assuming that we get some format like dSD4okOiGmLGDcqOTpQPFQ== then
you'll be able to view the cset with the following URL
http://linux.bkbits.net:8080/linux-2.5/cset@dSD4okOiGmLGDcqOTpQPFQ==
and that will always work and never get you different data.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
>> 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_.
>
> What about using the bugzilla email gateway? While it would be feasible that
> bugs should be added through the web interface, why not to automagically
> forward changes (new comments, attachments, maybe also status?) to appropriate
> mailing lists and absorb the replies to the thread back to bugzilla as the new
> comments?
Requestors and anyone with an account can add a list to 'cc' field,
so updates will get to the list. As for gatewaying from lists to
Bugzilla, I _strongly_ oppose it, and I hope DaveM would support me.
It's a door for spam and nothing else. If you have no IP connectivity
and read your linux-kernel with FIDO gateway and GoldED, use normal
ways of cooperating with maintainers. Bugzilla is complimentary,
not mandatory.
-- Pete
On Fri, 2002-11-15 at 09:44, Martin J. Bligh wrote:
> > On Fri, 2002-11-15 at 02:53, Eric Northup wrote:
> >> 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.
>
>
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
Jon Tollefson wrote:
>> 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?
The problem we have here is that all "versions" share the same set of
components -- and therefore, the same set of component owners. So if
we just create another version, say "2.5-ac", then we would not be able
to assign Alan Cox to the components belonging to this version because
there is only one set of components shared by all versions.
A way to get around this is to create 3-level component list (as opposed
to 2-level currently: category and components). This 3-level component
list would go like this:
Product --> Category --> Component
whereas
Product = 2.5-linus, 2.5-ac, etc.
Category = same as currently
Component = same as currently
What this does is that each product (2.5-linus, 2.5-ac, etc) would have
its *own* set of categories and components. This way we could assign all
categories and components under product 2.5-ac to Alan, and all categories
and components under 2.5-linus to other maintainers.
We could then delete "Version" from the bug reports as it no longer means
anything much.
Or we could use the name "version" for "product" in the scheme I described
above.
Khoa
[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
>> Also if you have already used this kernel Bugzilla database,
>> you might have noticed that many components are currently
>> owned by Martin or myself. As Martin pointed out in his
>> announcement, this is not because we are "egomaniacs", but
>> rather because the rightful owners (or those who know enough
>> about these components and want to volunteer to work bugs)
>> have not been registered yet. Martin and I will try our best
>> to turn over these components to their rightful "owners"
>> as soon as we can. We are still learning the "ropes" on
>> how to do this effectively, so it will take some time
>> (not too long we hope). Thanks.
>
> IMO it would probably be better for you two if all bugs without "real" owners had bugs assigned to [email protected], or something like that. That will not only ease useless emails sent to you and Martin and other admins, but also make it easier for kernel hackers to figure out which bugs are _really_ unassigned and need owners.
Sounds good - I'll see if we can set something like that up.
I'm happy for pretty much anything owned by "[email protected]"
to be stolen away ;-)
How about you give me a week to try to persaude the "real" owners
to volunteer (that's actually going really well), and then I'll
send out an email, listing which categories are still ownerless ...
M.
> Requestors and anyone with an account can add a list to 'cc' field,
> so updates will get to the list. As for gatewaying from lists to
> Bugzilla, I _strongly_ oppose it, and I hope DaveM would support me.
> It's a door for spam and nothing else. If you have no IP connectivity
> and read your linux-kernel with FIDO gateway and GoldED, use normal
> ways of cooperating with maintainers. Bugzilla is complimentary,
> not mandatory.
Agreed - cc'ing lkml is just going to piss people off.
Possibly we could create a tree hierarchy of email aliases for people
who want to watch certain categories at some point in the future, then
people can opt-in as they please.
M.
> A way to get around this is to create 3-level component list (as opposed
> to 2-level currently: category and components). This 3-level component
> list would go like this:
>
> Product --> Category --> Component
I'm not sure we really want this to be 3-level as that'd involve
replicating all the categories underneath. The OpSys field type
suggestion as an independant field would be nice, but the Bugzilla
code will need some tweaking to support possibly different default
owners dependant on that field.
For now, Jon has created us an "Alternate trees" category, with "ac"
and "mm" components, with appropriate text in the template to encourage
people to file bugs that happen (only) on those trees under the
"tree-specific" categories, and we can move bugs out from there if
need be. Hopefully that will make people happier for now, there may
be a cleaner solution long-term, but that needs more thought and more
work.
M.
On Thu, 2002-11-14 at 18:35, Martin J. Bligh wrote:
> 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.
>> 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.
> 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.
> 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.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Martin wrote:
>I'm not sure we really want this to be 3-level as that'd involve
>replicating all the categories underneath. The OpSys field type
>suggestion as an independant field would be nice, but the Bugzilla
>code will need some tweaking to support possibly different default
>owners dependant on that field.
>
>For now, Jon has created us an "Alternate trees" category, with "ac"
>and "mm" components, with appropriate text in the template to encourage
>people to file bugs that happen (only) on those trees under the
>"tree-specific" categories, and we can move bugs out from there if
>need be. Hopefully that will make people happier for now, there may
>be a cleaner solution long-term, but that needs more thought and more
>work.
I think the problem with this scheme is that all of the components
in the -ac or -mm trees are slumped into a single component.
If we have to use a 2-level component list, then I'd prefer we
do the following:
Category = 2.5-linus, 2.5-ac, 2.5-mm, etc.
Component = something like
MM-Page allocator
MM-Slab allocator
MM-NUMA
MM-MTTR
MM-Others
FileSys-devfs
FileSys-ext2
FileSys-ext3
and so on...
In other words, we just collapse the original category/component
list into a single level, and leave the top level to indicate which
trees.
Of course, only components belonging to a selected tree is displayed.
This would allow each tree to have its own set of components, which
can have different owners.
I have talked to Jon Tollefson and Jon agreed that this approach
is better.
We need to do it ASAP since the number of bugs (50+ currently) is
relatively small. We do NOT want to wait until later to make
any structural changes to the component list because that would
be a nightmare to reclassify hundreds of bugs.
Another option would be to use the "group" concept in Bugzilla to
provide the 3-level component list structure that I described
previously, but this would require some coding changes.
The above approach does not require any coding changes in Bugzilla
and is therefore preferrable.
Khoa
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 :-)
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.
"David S. Miller" <[email protected]> writes:
> I'm more concerned about the inevitable explosion of duplicates
> and "fixed already"'s.
mozilla handles it this way: the bug starts as unconfirmed. they have a
volunteer group of pre screeners. Only when one of these people sets
it to valid or similar then the owners of the module get mail.
I guess that could work for the linux kernel bugzilla too. Never hazzle
a developer, until someone confirmed the bug in some way (this does not
mean that he needs to reproduce it, just weed out obvious duplicates
and bogus postings)
-Andi
From: Andi Kleen <[email protected]>
Date: 15 Nov 2002 22:50:33 +0100
mozilla handles it this way: the bug starts as unconfirmed. they have a
volunteer group of pre screeners. Only when one of these people sets
it to valid or similar then the owners of the module get mail.
This sounds like a good idea.
> 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.
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.
> If we have to use a 2-level component list, then I'd prefer we
> do the following:
>
> Category = 2.5-linus, 2.5-ac, 2.5-mm, etc.
> Component = something like
> MM-Page allocator
> MM-Slab allocator
> MM-NUMA
> MM-MTTR
> MM-Others
> FileSys-devfs
> FileSys-ext2
> FileSys-ext3
> and so on...
No. That ends up with 10 billion items all in one drop down list,
which is a pain in the butt to use.
> The above approach does not require any coding changes in Bugzilla
> and is therefore preferrable.
The current fix doesn't require coding changes either, and was trivial
to implement. A long term solution should be done properly, by the
addition of a tree field.
M.
>> I'm more concerned about the inevitable explosion of duplicates
>> and "fixed already"'s.
>
> mozilla handles it this way: the bug starts as unconfirmed. they have a
> volunteer group of pre screeners. Only when one of these people sets
> it to valid or similar then the owners of the module get mail.
Ours is set up the same way, it's just called "OPEN" state instead
of "UNCONFIRMED".
> I guess that could work for the linux kernel bugzilla too. Never hazzle
> a developer, until someone confirmed the bug in some way (this does not
> mean that he needs to reproduce it, just weed out obvious duplicates
> and bogus postings)
Easy enough to do, we just need to change the default owners if
people get overloaded.
M.
David Miller wrote:
> mozilla handles it this way: the bug starts as unconfirmed. they have a
> volunteer group of pre screeners. Only when one of these people sets
> it to valid or similar then the owners of the module get mail.
>
>This sounds like a good idea.
Currently in the kernel bugzilla, after a bug is filed, it is initially
in the OPEN state -- this is similar to the Unconfirmed state mentioned
above. The screeners (my team and others who volunteer) can get rid of
many invalid bugs and dups. Only valid bugs then go to the ASSIGNED state
with correct owners. Of course, we do not expect to get rid 100% of all
the invalids and dups, but at least that should reduce the work of
the owners who should only work with bugs in the ASSIGNED state.
Also, the bug owner can close MULTIPLE bugs at the same time
on Bugzilla. A bug owner can query all of his bugs which will
then be displayed in a list, click the option "Change several bugs
at once" at the bottom of the list, select the bugs that he wants
to close, and then hit Commit button. It's pretty simple. Besides
closing the bugs, the owner can make similar changes to several bugs
at the same time using the same mechanism.
Regards,
Khoa
_________________________________________
Khoa Huynh, Ph.D.
IBM Linux Technology Center
(512) 838-4903; T/L 678-4903; [email protected]
Khoa Huynh wrote:
> David Miller wrote:
>
>
> >mozilla handles it this way: the bug starts as unconfirmed. they have a
> > volunteer group of pre screeners. Only when one of these people sets
> > it to valid or similar then the owners of the module get mail.
> >
> >This sounds like a good idea.
>
>
> Currently in the kernel bugzilla, after a bug is filed, it is initially
> in the OPEN state -- this is similar to the Unconfirmed state mentioned
> above. The screeners (my team and others who volunteer) can get rid of
> many invalid bugs and dups. Only valid bugs then go to the ASSIGNED state
> with correct owners. Of course, we do not expect to get rid 100% of all
> the invalids and dups, but at least that should reduce the work of
> the owners who should only work with bugs in the ASSIGNED state.
The bugs assigned to me are all in the 'open' state, with no obvious way
to change them to 'assigned'.
> Also, the bug owner can close MULTIPLE bugs at the same time
> on Bugzilla. A bug owner can query all of his bugs which will
> then be displayed in a list, click the option "Change several bugs
> at once" at the bottom of the list, select the bugs that he wants
> to close, and then hit Commit button. It's pretty simple. Besides
> closing the bugs, the owner can make similar changes to several bugs
> at the same time using the same mechanism.
The basic point still stands, though, that if the bug owner must close
multiple bugs at once, they are likely clearing out garbage and that
each individual bug is not necessarily unique or valid...
Jeff
Martin Bligh wrote:
>> If we have to use a 2-level component list, then I'd prefer we
>> do the following:
>>
>> Category = 2.5-linus, 2.5-ac, 2.5-mm, etc.
>> Component = something like
>> MM-Page allocator
>> MM-Slab allocator
>> MM-NUMA
>> MM-MTTR
>> MM-Others
>> FileSys-devfs
>> FileSys-ext2
>> FileSys-ext3
>> and so on...
>
>No. That ends up with 10 billion items all in one drop down list,
>which is a pain in the butt to use.
Well, it's not 10 billion items, but closer to....60 :-) And
the current component list is pretty complete, right? We don't
want to add anything that is not included in the official trees.
By the way, have you looked at Red Hat Bugzilla? They have
several hundreds of components in a single scroll-down list
(they define a component as a package). Of course, the list is
alphabetical, so it's not too bad to use it.
So I think 60+ is definitely a manageable number.
>
>> The above approach does not require any coding changes in Bugzilla
>> and is therefore preferrable.
>
>The current fix doesn't require coding changes either, and was trivial
>to implement. A long term solution should be done properly, by the
>addition of a tree field.
The approach above does not need any long-term solution. We should
try to avoid adding too much code above the base Mozilla code base
since it would be tough to upgrade the kernel bugzilla to a later
version of Mozilla code and it would introduce bugs which we don't
want.
Khoa
> The bugs assigned to me are all in the 'open' state, with no
> obvious way to change them to 'assigned'.
There's a radio button just below the additional comments box,
"Accept bug (change status to ASSIGNED)". Then hit Commit.
>> Also, the bug owner can close MULTIPLE bugs at the same time
>> on Bugzilla. A bug owner can query all of his bugs which will
>> then be displayed in a list, click the option "Change several bugs
>> at once" at the bottom of the list, select the bugs that he wants
>> to close, and then hit Commit button. It's pretty simple. Besides
>> closing the bugs, the owner can make similar changes to several bugs
>> at the same time using the same mechanism.
>
> The basic point still stands, though, that if the bug owner must close multiple bugs at once, they are likely clearing out garbage and that each individual bug is not necessarily unique or valid...
If it gets onerous in terms of numbers of bugs filed, we can get people
to prefilter them. I think that things will calm down in a week or so,
but if you want, I can find someone to do that for network drivers.
M.
> Well, it's not 10 billion items, but closer to....60 :-) And
> the current component list is pretty complete, right?
No it's not.
> We don't
> want to add anything that is not included in the official trees.
What do you mean by that? Bugs or components? And which are the
"offical" trees?
> By the way, have you looked at Red Hat Bugzilla? They have
> several hundreds of components in a single scroll-down list
> (they define a component as a package). Of course, the list is
> alphabetical, so it's not too bad to use it.
>
> So I think 60+ is definitely a manageable number.
Disagree. That's why we didn't go for a flat list in the first place.
M.
Martin J. Bligh wrote:
> >The bugs assigned to me are all in the 'open' state, with no
> >obvious way to change them to 'assigned'.
>
>
> There's a radio button just below the additional comments box,
> "Accept bug (change status to ASSIGNED)". Then hit Commit.
That would be the obvious way, but that option is not presented to me :)
Look at http://gtf.org/garzik/misc/Screenshot.png ;-)
Tangent: Red Hat's bugzilla has a 'NEEDINFO' status which is quite
useful too.
> >>Also, the bug owner can close MULTIPLE bugs at the same time
> >>on Bugzilla. A bug owner can query all of his bugs which will
> >>then be displayed in a list, click the option "Change several bugs
> >>at once" at the bottom of the list, select the bugs that he wants
> >>to close, and then hit Commit button. It's pretty simple. Besides
> >>closing the bugs, the owner can make similar changes to several bugs
> >>at the same time using the same mechanism.
> >
> >The basic point still stands, though, that if the bug owner must
> close multiple bugs at once, they are likely clearing out garbage and
> that each individual bug is not necessarily unique or valid...
>
>
> If it gets onerous in terms of numbers of bugs filed, we can get people
> to prefilter them. I think that things will calm down in a week or so,
> but if you want, I can find someone to do that for network drivers.
I'm willing to wait and see how things settle out in a few weeks. I
doubt it will be a huge problem for me personally, but as we see on the
mailing lists already, there are plenty of bogus net stack bug reports
[I know, I posted one just today and got corrected by Alexey]. I forsee
David having a much bigger problem with potential bugzilla-related grunt
work...
If you think back to what I first proposed, the original idea was to
minimize the grunt work on kernel developers so we could focus on
solving the tough problems :) As I said back then, that definitely
implies some useful help from staff and community to keep the bug
database clean. I think Andi Kleen mentioned that Mozilla project has
bugs begin life as pre-screened... I think that's a pretty good model.
Since you pointed out that Bugzilla supports that model from a technical
standpoint, all we need are the pre-screeners to help us out... :)
Jeff
Martin Bligh wrote:
>> By the way, have you looked at Red Hat Bugzilla? They have
>> several hundreds of components in a single scroll-down list
>> (they define a component as a package). Of course, the list is
>> alphabetical, so it's not too bad to use it.
>>
>> So I think 60+ is definitely a manageable number.
>
>Disagree. That's why we didn't go for a flat list in the first place.
Hmm...If thousands of Red Hat and SuSE users worldwide can deal with a
scroll-down list with hundreds of components, I wonder why kernel
developers can't?
60+ items on an alphabetical, scroll-down list is very easy to handle.
Go to Red Hat or SuSE Bugzilla and try it and you'll see it's not bad
at all (and they have hundreds of items!).
Also, it seems that no one else is interested in this particular
stuff anyway, so let's talk. I will call you on Monday.
Khoa.
Jeff Garzik wrote:
>> >The bugs assigned to me are all in the 'open' state, with no
>> >obvious way to change them to 'assigned'.
>>
>>
>> There's a radio button just below the additional comments box,
>> "Accept bug (change status to ASSIGNED)". Then hit Commit.
>
>
>That would be the obvious way, but that option is not presented to me :)
>Look at http://gtf.org/garzik/misc/Screenshot.png ;-)
>
Hmm....Interesting. I looked at your bugs and I see the radio buttons
to accept the bugs and move them to the ASSIGNED state. Maybe there is
something wrong with your Bugzilla profile. I will ask Jon to look
into this. Thanks for letting us know.
On Thu, Nov 14, 2002 at 10:58:09PM -0500, Patrick Finnegan wrote:
> 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.
--
toyota power: http://indigoid.net/
On Fri, 15 Nov 2002, Larry McVoy wrote:
> 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
[email protected]
<>< As a computer I find your faith in technology amusing.
Em Sat, Nov 16, 2002 at 02:10:13AM -0500, Gerhard Mack escreveu:
> On Fri, 15 Nov 2002, Larry McVoy wrote:
> > 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
On Wed, 2002-11-13 at 21:33, Martin J. Bligh wrote:
> Brave volunteers who've created an account would be most welcome,
> ideally the code maintainers for those subsystems, but other people
> familiar with those areas would be a great substitute. ;-)
If we can volunteer for sub-categories (I do not think so, but hey...) I
will do "preemption" and "scheduler", if no one else has volunteered.
Otherwise I will take all of "Process Management", and the huge blanket
of bugs that includes :)
Robert Love
On Sat, Nov 16, 2002 at 05:17:50AM -0200, Arnaldo Carvalho de Melo wrote:
> Em Sat, Nov 16, 2002 at 02:10:13AM -0500, Gerhard Mack escreveu:
> > On Fri, 15 Nov 2002, Larry McVoy wrote:
>
> > > 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...
>
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.
--
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
>> 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.
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 04:08:31PM -0500, Murray J. Root escreveu:
> On Sat, Nov 16, 2002 at 05:17:50AM -0200, Arnaldo Carvalho de Melo wrote:
> > Em Sat, Nov 16, 2002 at 02:10:13AM -0500, Gerhard Mack escreveu:
> > > On Fri, 15 Nov 2002, Larry McVoy wrote:
> >
> > > > 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...
> 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
Martin J. Bligh wrote:
> >>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.
>
>
> 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
On Sat, Nov 16, 2002 at 01:44:19PM -0800, Martin J. Bligh wrote:
> >> 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.
>
> 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.
--
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 01:44:19PM -0800, Martin J. Bligh escreveu:
> >> 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.
> 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
Em Sat, Nov 16, 2002 at 04:54:58PM -0500, Jeff Garzik escreveu:
> Martin J. Bligh wrote:
> >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.
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.
> '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: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?
David S. Miller wrote:
> 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
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
> 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.
On Sun, Nov 17, 2002 at 11:31:04PM -0300, Werner Almesberger wrote:
> David S. Miller wrote:
> > 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.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Oliver Xymoron wrote:
> 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
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
> 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.
Arnaldo Carvalho de Melo wrote:
>> >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.
>
>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.
Currently the kernel bugzilla has a state called DEFERRED (with resolution
WILL_FIX_LATER) for this type of inactive bugs. Anyone who is interested
in these bugs can set the query to look at them; otherwise, they are not
on the active bug list. They are not closed either -- they are just
"deferred".
Oliver Xymoron wrote:
> On Sun, Nov 17, 2002 at 11:31:04PM -0300, Werner Almesberger wrote:
>
>>David S. Miller wrote:
>>
>>>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.
>
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 `-------------------------------------------------
On Mon, Nov 18, 2002 at 10:53:32AM -0600, Eli Carter wrote:
> Oliver Xymoron wrote:
> >On Sun, Nov 17, 2002 at 11:31:04PM -0300, Werner Almesberger wrote:
> >
> >>David S. Miller wrote:
> >>
> >>>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.
> >
>
> 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..
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Larry McVoy wrote:
>That's the goal. I'm hacking on it it currently, we have some issues with
>how it works today, I'll try and get a bk-3.0.1 release out the door which
>fixes them.
>
>The current format is may be seen with a
>
> bk changes -k -r<rev>
>
>where <rev> is the changeset revision you want. You'll get something like
>this:
>
> [email protected]|ChangeSet|20021115061315|00914
>
>That's sort of big and ugly, and it currently doesn't work as a name
>in BK/Web. I'm debugging an implementation of md5 sums of the above
>to see if we can use that instead. I'll let you know as soon as I
>have something which works.
>
>Assuming that we get some format like dSD4okOiGmLGDcqOTpQPFQ== then
>you'll be able to view the cset with the following URL
>
>
http://linux.bkbits.net:8080/linux-2.5/cset@dSD4okOiGmLGDcqOTpQPFQ==
>
>and that will always work and never get you different data.
Thanks. Back when we were setting up the OSDL kernel bugzilla, I thought
about having a direct, unique URL link between the bugzilla bug reports
and csets in BK, but could not find anything -- like you said, the revs
changes as you move the changesets from one repository to another. So
I am very happy that you are going to provide a unique URL link for each
cset. Please let me know when you get this done and we will have
a separate field (called "Changeset Link") in kernel bugzilla to hold this.
We expect that bug owners, after putting their patches into BK, will obtain
the cset "name", and enter it into the "Changeset Link" field in the bug
report. After hitting the "Commit" button, the kernel bugzilla will
translate the cset "name" into a URL link like you indicated above.
This would allow people to view bugs, and if there are already fixes in
BK for those bugs, they can get directly to the fixes (changesets).
Khoa
Jeff Garzik wrote:
>> >The bugs assigned to me are all in the 'open' state, with no
>> >obvious way to change them to 'assigned'.
>>
>>
>> There's a radio button just below the additional comments box,
>> "Accept bug (change status to ASSIGNED)". Then hit Commit.
>
>
>That would be the obvious way, but that option is not presented to me :)
>Look at http://gtf.org/garzik/misc/Screenshot.png ;-)
>
We found out the root cause of this problem. There are different levels
of privilege in bugzilla, and the bug owners (like Jeff Garzik) have
the privilege to move bugs among different states (like RESOLVED or
CLOSED), but *not* ASSIGNED state. The original intent of Bugzilla
is that bug owners only work on bugs assigned to them, and the
screening (assigning) bugs is the responsibility of screeners. I think
this does not apply to kernel bugzilla very well, so we will give bug
owners enough "power" to assign bugs to themselves as well. Jon has
already given Jeff this power; more will come later (this is a manual
process, sigh :-))
Khoa
