[Libreoffice-qa] top #n bugs tracking ...

[Michael Meeks]

Hi there,

	So - in the attempt to get something concretely actionable out of this;
I liked this idea:

On Sat, 2012-08-11 at 12:30 -0700, bfo wrote:
> Call for bugs (CFB). I think that CFB should be introduced in the release
> schedule (example http://wiki.documentfoundation.org/ReleasePlan/3.6). When
> to do it and how is another matter. I think that when RC1 is released a CFB
> should be started and bugfixing planned when RC2 is released (2 weeks
> are enough?). Bugs should be nominated by QA from ESC stats - regressions
> and MAB list. Hard code freeze is in next 4 weeks, so the question is -
> how many bugs can be fixed in 4 weeks ?

	So - I like the idea of highlighting a small set of the most critical
bugs each-week - say five; and having them linked in the ESC minutes
with a small write-up. Of course that would need to be generated by QA.

	The bit that is unworkable in the above is the problem of starting QA
in earnest only at RC1 :-) That is is -way- too late. We have to be
doing QA on master, Betas etc.

	I hope people realise that the -intention- is that you can run
'master' / daily snapshots and have as bug-free experience as you do on
a release branch ;-) well - at least, that's a goal we need help finding
and fixing the bugs as early as possible.

	Why is RC1 -way- too late ? The time it takes to get a fix made,
tested, reviewed and included into the next RC is sufficiently long that
being certain that bugs fixed in RC1 are truly fixed without knock-on
regressions by the time we hit RC3 is already not optimal.

> how many bugs can be fixed in 4 weeks ?
 
	There is this fallacy that because RC1 is separated from final release
by four weeks, that we have four weeks to fix bugs :-) there is a three
week window here at the outside. Furthermore, we're substantially only
interested in screaming ship-stoppers for the RC phase - anything else
creates too much risk.

	The earlier we can start aggressive bug hunting, and a low tolerance
for new regressions the better; most ideally in master.

	On the other hand, getting some top #5 bugs chewed over at the ESC call
each week from Beta0 onwards sounds like it would be a worthwhile thing
to do. Of course, there is no guarantee they get fixed and this data
should already existing in the MAB tracker for the next release - but it
might be helpful to get wider exposure.

	Are you volunteering to write that ? if so, the ESC agenda goes out
tomorrow ;-)

	ATB,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot