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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]