[Libreoffice-qa] Fwd: [tdf-announce] The Document Foundation announces LibreOffice 3.6 with a wealth of new features and improvements

[Bjoern Michaelsen]

Hi Michael, all,

On Mon, Aug 13, 2012 at 10:36:27AM +0100, Michael Meeks wrote:
> On Fri, 2012-08-10 at 12:16 +0200, Timur Gadzo wrote:
> > I'm asking for EXPLANATION in the first post when will FIXES for bugs
> > resolved in MAB 3.5 be included in LO 3.6 CODE.
> 
> 	Ah ! sorry, I mis-understood :-) so the generic answer to:
> 
> 		"when will XYZ bug be fixed ?"
> 
> 	is that there is basically no answer to that question. That doesn't
> mean the bug will not be fixed - far from it, but the timing is
> uncertain. Take for example:
> 
> 	https://bugs.freedesktop.org/show_bug.cgi?id=47368
> 
> 	Which is a pet-peeve of mine that I try to spend my spare (what there
> is of it) time looking into. Unfortunately, finding the underlying cause
> (almost certainly a memory corruption) is really not easy. Thus far we
> have few-to-no traces with debug symbols enabled, it is really hard to
> reproduce the problem, the valgrind runs we try to get hang before we
> can reproduce the error ;-) etc. etc. When will that bug be fixed ?
> that's really not clear to me. I would certainly not block any release
> until that is so - badly as I want it fixed.

Still I think a valid concern is raised here: While 'when will XYZ bug be
fixed' is indeed not really answerable until it is fixed (or somebody invents a
timemachine), the question 'when and how is this issue being addressed by
development?' a good one as in it lies the key to motivating the QA team. When
the best answer developers can give to those doing bug triage is 'whenever I
find spare time' if it is a developers pet peeve or worse if its not that is
clearly something we need to improve to keep the QA team in the loop.

If we developers are asking the QA team to take care and visiblity of _all_
bugs and not only their pet peeves (which we are as we have no fulltime
sponsored QA contributors) -- the same can be expected from the developers (at
least from the sponsored full time developers). Now that is in an ideal world
we would gladly sacrify our pet peeves for the cold rational progress of the
project. In the real world, having fun along the way is an essential goal of
the project too: so there is a balance to strike there.

So we need to find a way to ensure that both QA and development are confident in
sharing the same major goals and priorities. Im working on a proposal towards that,
but I am not quite there yet.

> 	It seems rather unlikely that commercial users suffer from -all- of the
> MAB at once :-) one reason that many of them are still open is that
> (thus far) our customers havn't reported the 3.5 MAB's as issues for
> them - and (I assume) the same is true for others' customers for whom
> they provide paid support. Usually, a customer has a few blockers that
> hold up deployment, and they ask to have these few fixed, and we provide
> them with a fixed build, and merge the fixes into LibreOffice.

I think the commercial users are mostly a red herring here. L3 support is the
answer to their problems. But we also need to take care to address the issues
that are not primarily hitting commercial users, but average Joe Enduser (e.g.
crashes using basic functionality on our own fileformats without using any
fancy features). It is unlikely that those will be asked to be fixed by a
support contract anyway -- OTOH those might turn away end users (and on their
tail commercial users) from considering LibreOffice at all. So: such
fundamental functionality needs to be care of by us, otherwise nobody does.

Still no magic wand to fix bugs, though(*). ;)

Best,

Bjoern


(*) Apart from the one you already called out: Not letting bugs in in the first
place, i.e. QA tester vicously testing master builds.