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.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
