Re: [PATCH 2/2] suspend: Cleanup calling of power off methods.

[ebiederm@xmission.com (Eric W. Biederman)]

Pierre Ossman <drzeus-list@drzeus.cx> writes:

> What we probably need then is an official policy that maintainers need
> to have an account in the bugzilla. Start with the subsystem maintainers
> and leave it to them to get each driver maintainer in line. Having only
> a handful of parts of the kernel in the bugzilla is just confusing.

But the definition of a maintainer is whoever takes responsibility for
part X.  The are many pieces of the kernel that don't easily break
up into the taxonomy of subsystem and driver.  There are many people
to reluctantly take responsibility because there is no one else,
and so aren't even mentioned in MAINTAINERS much less the rest of it.

> Personally I think the mailing lists are a great way for general
> discussion. But once we have a confirmed bug (or difficult new feature)
> it is better off being tracked in bugzilla. And this is my opinion both
> as a user and as a developer. Bugzilla is the de facto standard of
> reporting bugs so some users might find it troublesome dealing with
> mailing lists such as LKML.

One problem I have with a system like bugzilla is that frequently bug
reports are not complete, and bugzilla sets the expectation that
once you file a bug the reporters part is complete.  Frequently it takes
several round trips via email to even understand the bug that is being
reported. 

So either we need a two level bug tracking system where there
is a place to capture bugs that users see, and a place to track
bugs that developers understand.  Or we need something that is
much more interactive than bugzilla.

I like Andrews idea of a short term mailing lists for each bug.  Where
filing the bug creates the mailing list and the mailing list exists
until the bug is closed sounds like something that might even get
used, as it can be easy for everyone.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/