Public SourceMage Discussion List

[seth AT swoolley.homeip.net]

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