[Libreoffice-qa] Minutes of the ESC call 2012-10-11

[Michael Meeks]

Hi Rainer,

On Thu, 2012-10-18 at 09:00 +0200, Rainer Bielefeld wrote:
> >      + 3.5 MAB needs cherry-picking and folding into 3.6 MAB (some
> >        don't seem to be valid most annoying)
...
> I already started my traditional "End of Lifecycle MAB cleanup", results
> on <http://wiki.documentfoundation.org/HardHacks#Proposed_Hard_Hacks>

	Ah ! that is good work, always a tad depressing of course to sort
through these bugs; I was hoping to have some time to do some of that
myself.

> Although I was one of those who brought up these thoughts, I believe 
> it's not realistic to hope that an other 3.5 release with 2 or 3 
> additional bugfixes will bring significant benefit.

	Well - it is possible (due to some security bug or other) that we will
want/need to do a new 3.5.x - so putting a few such easy fixes into the
branch is no problem even if that issue never arrives.

> But I believe for 3.6 we should rethink our release policy. We should 
> not terminate work on a version 3.6 because most people loose interest 
> (because they are busy with next release 3.7), that leads to a situation 
> as we have with 3.5.7 that still 77 MAB are unfixed and nobody know why, 
> but because the version is ready.

	Sure - on the other hand, some most annoying bugs are really big
beasts: eg. the "memory management is utterly shambolic" issue is one
that causes corner-case image loss, and/or image leakage all over the
shop. Yet to fix it is several man weeks of focused work and thus far no
time / volunteers for that.

> Of course I know that it never will be possible to get really all Bugs 
> fixed, but selection what these "remaining unfixed bugs" should be done 
> by a founded decision and not by coincidence.

	Certainly I think reviewing them is a really good idea; perhaps some
are just forgotten etc. having said that 

> May be something like this can help to avoid surprises 8only a first 
> thought):

	I like the schema; on the other hand preparing detailed reasons why XYZ
bug is not fixed for 80 or so bugs is a big chunk of work. Is the
advantage of this is essentially marketing, to re-assure users that
their bug is being tracked ?

> final release -4 is out:
> -----------------------
> QA does all possible efforts to sort out inappropriate MAB and and to
> add all required info to those bug so that they are really "ready for
> fixing" by developers.

	IMHO we should not accept any bug as a longer-term MAB that does not
have precise information - if a regression: where it regressed, if a
crash - a with-symbols stack-trace etc. It's fine to have a lower
quality report if it is a new bug in the latest release or more
critically 3.7/master: we want to see it fast - but for a MAB being
pulled up for 3.5 it'd need to be a complete report I think.

> final release -3 is out:
> ------------------------
> Remaining well prepared MAB will be deployed to developers similar to 
> the HardHack proceeding. (QA-calls, ESC-calls, ...)

	So - the idea that we can just hand out dozens of bugs to ESC members
and they get magically fixed is not one I'm hyper-enthusiastic about ;-)
the people there tend to be extremely busy already. On the other hand I
love the suggestion of spending time - perhaps a special dedicated ESC
call to reviewing all the MABs that dropped off the end of the release
and working out why / what to do.

	Is it easy to get a list of those once you've migrated them ?

> final release -2 is out:
> ------------------------
> If developers recognize that it will not be possible to fix particular
> bugs with acceptable "costs" and risk

	So - as you say; there is sometimes a regression risk around an
invasive fix; if so I'd suggest we just close them in some way that
makes that clear - having fixed them in master; I'm not sure that
applies to more than 1/2 of the bugs if that. I expect the most common
explanation for why a bug is not fixed is nothing to do with the bug but
to do with "no time", or something similar.

	In your schema, I'd also want to prioritise those regression bugs both
in version N and N+1 that stop people upgrading to N+1 - to me those are
even more important than MABs since they strand people on some
horrible/old code that has no new releases :-) Creative ideas about
identifying / categorising those specific kinds of forward migration
blockers would be appreciated.

	All the best,

		Michael.

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