Re: changing maintainer field
On Tue, Jun 05, 2007 at 12:13:19AM +0200, Frans Pop wrote:
> On Monday 04 June 2007 23:42, maximilian attems wrote:
> > > what where the args against it appart from pure inertia?
>
> Note that you'll probably lose me as someone who occasionally helps reply
> to bugs as I doubt I'll want to be subscribed to two separate kernel
> lists. I suspect this will be true for others as well.
why? I mean, what's the overhead of subscribing to two separate lists?
Just curious..
> It will also mean that I will lose some sense of what is happening wrt the
> kernel.
>
> Are there enough people who are planning to subscribe to the "bug" list
> anyway or is it just going to further reduce the number of people that
> see and deal with kernel BRs?
I for one would certainly subscribe to both. However, I've heard
complaints from people that they are interested in higher level/lower
traffic discussions (new upstream to be uploaded to experimental,
kernel update in a stable release, should we drop kernel-package,
etc), but they are not interested in individual bugs. The current
model is suboptimal for them. Perhaps we can force these people to
watch bug traffic go by so that they can't help but participate in
triage at some level, but I suspect its more likely that these people
will just unsubscribe altogether (or implement their own
filter). imo, people should be able to select their level of
involvement.
However, since I personally want to see all of this mail, I'm not
really going to push the issue. If there's no outcry from people who
want to see only bugs or only non-bugs, then we're probably trying to
solve a non-existant problem. In fact, of the people I remember
complaning about this, I don't think either are active on the current
list (and I don't know whether they would subscribe to either filtered
one).
I do however think that getting more people involved with triage is
critical. I think the best way to do that would be for the kernel
team to create some sort of work flow that establishes the rules for
dealing with bugs, things like:
* When and how to forward bugs upstream
* How long to leave a bug open w/o a response from the submitter
* Procedures for narrowing down a fix/breakage - e.g., determining if
its debian-specific, using git-bisect, etc
* Useful usertag procedures for reducing the problem into smaller
sets - e.g., hardware, subsystem, etc.
In short, get it down to where 80% of the work can be handled by
monkeys, then start baiting traps with bananas and building automated
poop-slingers where feasible.
--
dann frazier
Reply to: