[lsb-discuss] LSB Bugzilla in Re: Ways for us to work more efficiently

Wichmann, Mats D mats.d.wichmann at intel.com
Mon Feb 4 12:35:24 PST 2008


Okay, I want to come back to just the bugzilla part of this as 
I'm working on the bugtracker this week.

I'll update bugzilla and/or the wiki page based on what we settle
on for these.

> = Use of Bugzilla =
> 
> == Meaning of priority fields ==
> 
> There are a number of P1 bugs which have persisted over 2, 3, or more
> LSB releases.  Furthermore, bugs such as
> [http://bugs.linuxbase.org/show_bug.cgi?id=1310 BZ #1310: LSB 3.2
> complete release] are Priority 2, which seems rather strange.  It
> appears that the priority field is not used at all.  We should use the
> Priority fields to indicate how important a particular bug is, and in
> particular, P1 bugs should indicate bugs which are block-ship, and P4
> and P5 bugs should be bugs which we are willing to defer to the next
> release.  While using the bug dependency tree is very helpful,
> unfortunately it appears that Bugzilla doesn't have very good
> reporting mechanisms involving it, while filtering bug reports based
> on "Target Release" and "Priority" Bugzilla *can* do very well, so we
> should take advantage of BZ's abilities in these areas.

Priorities have not been much used. Nor have severities.  It
would make sense to do so. We have odd prioirites on some things
because it appears sometimes the web browser rendering the
bugzilla pages "remembers" things - we've seen cases where
somebody reports a bug as P1, and then every bug they report
after that defaults to P1 until they notice and manually set
back to P2. 

I'd like to settle on the meanings of priority vs. severity,
I'll mail out a proposal in a bit.


> == Use of Target and Version fields ==
> 
> Bugzilla allows the introduction of a "target" or "target milestone"
> field which appears to have been suppressed in the LSB bugzilla.  This
> field specifies the target version when a bug is intended to be fixed.
> The Version field is used in some bugzilla systems to indicate the
> target milestone, although formally the definition of the Version
> field is the version of the system where the reporter found the bug. 
> In the LSB bugzilla, the Version field is used inconsistently; in
> some cases it is updated to mean the version when the bug is intended
> to be fixed, but in other cases it is left as the version where the
> reporter found the problem. 

This is NOT intended (to be inconsistent). The policy, which I note
we do not document in our UsingLsbBugzilla page, is that Version is
the version where the problem was found.  The difficulty arises from
natural events, but we could prevent them:  many bugs get reported,
especially by the core team, against late development versions,
to use this last version as an example, things were much closer to
3.2 than to 3.1 so it may seem a little silly to report them against
3.1, especially if the feature itself wasn't present in 3.1 at all.
We do have generic "beta" and "snapshot" values to file against, and
that might be a useful discipline, or we could define slightly more
descriptive version tags (4.0pre to cover things intended for 4.0
before 4.0 is released).  Do people have opinions on that?

I can use Target as well as the current dependencies on rollup bugs -
if the former proves comfortable we can transition away from the
latter over time.

One note: in the particular case of an "enhancement request" it
actually makes sense for Version to be "release I'd like this for"
rather than "release I found the bug in" (since by definition
it's not a bug, and by extension it's been absent from /every/
release).


> In the LSB bugzilla, bug dependencies are used to track when a release
> is ready to be released.  This can be more powerful than the Target
> field, but it also makes it much harder to track changes via
> Bugzilla's graphing and reporting tools. 
> 
> == Use Bugzilla Graphing Tools ==
> 
> [[Image:Sample-bug-trend-chart.jpg|thumb|right|Sample bug trend
> chart]] 
> 
> I would suggest using periodic charts (probably generated
> monthly) so we
> can see how we are doing vis-a-vis open bug reports, and so we
> can get a
> high-level view about whether or not we seem to be closing the
> necessary bugs to make a release.

I do have bug trend statistics for some period going back.
I've stopped publishing those on the mailing list as nobody
showed the slightest interest in them (at least if "nobody
ever reacted" means no interest).  No problem starting something 
up again.  Incidentally, even though those statistics aren't
used that much, getting trend numbers is why I keep resisting
proposals to unify all the different Linux Foundation bugtrackers.
It's hard enough to generate good numbers on the LSB bugs
even when they're not mixed in with all the other potential
sources of bug traffic.  

> == More aggressive use of bugzilla log entries ==
> 
> One of the things which I have noticed on the LSB bug calls is that a
> huge amount of time is spent recalling the status of the various LSB
> bugs.  We could probably make the bug calls more efficient if people
> were more aggressive about keeping the BZ bug accurate.  At a previous
> project that I was on, there was a team rule that if anytime anything
> interesting was discovered about the bug, it was *always* logged

We've in general done pretty well at this.  The problem happens
when people own too many bugs and it gets harder to keep track of
all of them when things get hectic. Ahem, I'm certainly somewhat at 
fault here, as I get everything that says "specification" and a few 
others, and so I have 167 assigned to me.  I'm giving some of those 
away this week, and we'll be looking how to spread that out as more 
people show up, but in general I don't think there's a big problem 
in this area, just continuing discipline needed [kudos to Stew, who 
seems to be especially good at keeping his informantion up to date].





More information about the lsb-discuss mailing list