>>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.)
-
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/