Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] bugzilla woes: flags

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: seth AT swoolley.homeip.net
  • To: Jaka Kranjc <lynx AT mages.ath.cx>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] bugzilla woes: flags
  • Date: Thu, 10 Aug 2006 08:28:40 -0700

Sorry for top-posting this :)

I'm not getting the same results as you. For example, I tried flag
equals fixed in lesser branch- and got two bug results, not 1874. When
I'm online after work, I might get some time to go over some issues with
bugzilla (they might be fixable after all).

Dkowis and I were also discussing some potential UI improvements to
bugzilla and/or using a tracking system that's more intuitive to the
process we liked. This discussion is ongoing in #sourcemage-quality.
Drop in there if you'd like to give feedback (or just reply to this
thread). I have some issues with the current proposal from dkowis that
I think are resolvable, I just need to sit down and go over them with
him in more detail than I already have. One thing I'd personally like
to avoid is cloning. I want one bug to be tracked under one bug, not a
bug tracked and its integration tracked in a separate bug, unless we
don't call it a bug, but have a different form/table for it (this is
just basic database normalization -- I'd go over the theory in email,
but I figure google can explain it better). Data duplication is a
hobgoblin for expediency, not long-term data analysis.

Yes, we don't have enough gatekeepers/integrators (no volunteers have
come forward). Right now, I'd like everybody to bear with us as the
integrations are being avoided even if approved (except for important
items) so we can re-branch stable-rc 0.5 from test (as per an easier
switch to git from perforce). When this is done, there will be more
mass bugzilla bug edits and most of the approveds will have made it into
stable-rc 0.5.

The plan is to get releases every month, but for now, a release once
every two months looks like it is the most doable until our SCM
conversion completes. I apologize for any delays and I hope people
understand that the bug fixes are greatly appreciated and they will make
it into stable in due time. The fixes going in _greatly_ improve the
new user experience because we're testing for a simple cast from a clean
base. This is the experience most newbies will encounter, and if they
fail it's hard to explain why we didn't do such a simple test.

One modification to the process that I'd like to make is to make
stable-rc open for integrations by regular gurus for the first few weeks
after a stable release so that people can get their favorite wish-list
items in asap. This also would let us test stable-rc as it originated
and get most of the dependency-related and interaction-related fixes in
very quickly. Once the first round of testing on stable-rc would be
done and after an appreciable number of important fixes made it in, the
branch would be closed to integrates without gatekeeper approval and
re-testing would be done on a spot-basis until it meets numbers, then a
full re-test (spin) would begin. This could potentially drag out
releases to once every two months instead of my one month target,
however, I think people would like it better to have a period where they
could take ownership of their section's idea of what would appear in
stable. I don't want the gatekeepers to be the power driving what
appears in stable.

As I get more hardware for testing, I'll be able to test test grimoire
before integration to stable-rc at the same time as stable integration.
This could eliminate the need for a stable-rc open period as fixes could
go directly to test grimoire as long as we hold off version updates for
important spells (like gcc/glibc, etc) during that testing period. This
would then work to decrease testing and release cycle periods back to
within the one month time frame I'd like to hit.

So that's my grand vision for moving forward. Any comments?

Seth

On Thu, Aug 10, 2006 at 03:49:10PM +0200, Jaka Kranjc wrote:
> We have flags for grimoire QA purposes (and others) and bugzilla's advanced
> search form gives the impression of being competent to deal with them.
> However, it could be just me, but it doesn't show the right results when
> checking more than one flag.
>
> I'd like to know a few simple stats:
> 1. how many not fixed quickfix+ (useful for new people or that /quick
> fix/) ...
> 2. how many fixed in lesser branch and waiting for gatekeepers (useful to
> annoy the gatekeepers) ...
> 3. how many fixed in lesser branch, approved for integration and not done
> (useful to annoy anyone with access)
> ... bugs are there
>
> These would nicely show the state of our QA process and where it could be
> improved. From my experience we lack gatekeepers or them doing gatekeeping
> more regularly and people to integrate things down once they are approved
> or
> them searching for such bugs (shouldn't these be a priority?).
> Or we should just release more often (one month since last release now).
>
> Examples:
> 0.0 searced by setting flag equals quickfix+
> 103 bugs found
> randomly picking a few shows it probably does the right thing
>
> 0.1 searced by setting flag equals fixed in lesser branch+
> 221 bugs found
> randomly picking a few shows it probably does the right thing
>
> 0.2 searced by setting flag not equals fixed in lesser branch+
> 128 bugs found
> randomly picking a few shows it probably does the right thing. Wierd number.
>
> 0.3 searced by setting flag equals fixed in lesser branch-
> 1874 bugs found - all the bugs there is. Wierd number.
>
> 1. 0 searced by setting flag equals quickfix+ AND flag not equals fixed in
> lesser branch+
> 103 bugs found
> looks like the same list as under 0.0 #12930 confirms a problem.
>
> 1.1 searced by setting flag equals quickfix+ AND flag not equals "fixed in
> lesser branch"+
> 103 bugs found
> looks like the same list as under 0.0 #12930 confirms a problem.
>
> 1.2 searced by setting flag equals quickfix+ AND flag not equals branch+
> 103 bugs found
> looks like the same list as under 0.0 #12930 confirms a problem.
> Also tried with the order reversed.
>
> 1. 3 searced by setting flag equals quickfix+ AND flag not equals fixed in
> lesser branch
> 103 bugs found
> looks like the same list as under 0.0 #12930 confirms a problem.
>
>
> ... so I didn't even bother with the others. The few bugzilla docs that
> I've
> found don't mention searching. Help.
>
>
> In other news, dkowis wrote a long proposal about bugzilla on the wiki
> (currently down here).
>
> --
> We cannot command nature except by obeying her. --Sir Francis Bacon



> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss





Archive powered by MHonArc 2.6.24.

Top of Page