Bugzilla bug tracking database for 2.5 now available.
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Eric Northup
Quoted 4 lines
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.)