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

[Michael Meeks]

Hi there,

On Fri, 2012-08-10 at 08:27 -0700, bfo wrote:
> Not at all. After reviewing >400 bugs (and counting) 

	That's good work :-)

> I could double 3.5MAB numbers in an instant. 

	Hey ho; it is no secret that there is really no shortage of bugs in the
product :-)

> Just see 3.5MAB stats in ESC minutes - open bugs vs fixed ratio is
> unfortunately more or less constant.

	Amazing isn't it - I wonder whether it would remain so if you doubled
the number of MABs ;-) I have no real explanation for that ~constant
~30% number.

>  The same with regressions. 67 in Writer? 177 in whole package? Regressions!
> Bugs that irritate users most, because they want to use advertised nice new
> features but they are stuck with old version for good.

	Having regressions is not a new thing for the project; but yes these
are annoying issues - this is why we track them and try to prioritise &
address them.

	Having said that a large number of bugs are going to be regressions,
anything that breaks an existing functionality is such - and doing
development (even bug-fixing) without creating any new bugs is simply
impossible. Clearly we need to invest effort into our highest priority
bug and feature gaps.

	The reason I graph regressions each week is to try to add focus there;
if you can think of another more encouraging way - that'd be
appreciated.

> or rewriting filters just to introduce 12 regressions.

	Um - you think we re-write filters just to introduce regressions ? :-)
If it's the RTF filter you're concerned about (the biggest re-write
recently), it has removed a ton of buggy, complicated, horrible code;
worse - code that was duplicated so that fixing it had no value for
improving inter-operability elsewhere. We (the ESC) made a strategic
decision to take some regressions there - in order to have much greater
sharing of the filter code, such that we have less code, and hence our
bug fixes have more impact across all Microsoft import and export
filters. That is IMHO a great decision, but sure we have a few open
regressions there still to nail. As of now the export code for RTF, DOC
and DOCX is substantially shared eg. so fixing a bug in one will make it
magically work for the others - that has to be a good place to be. Our
RTF import/export is now in many ways more capable than it was before
feature-wise; eg. not loosing all the document data after an embedded
formula is quite a nice new feature in the re-write etc. etc. ;-)

>  It has to stop. Really. Now. Crashkill, regressionkill, testing
> before commiting, better code reviews.

	There is testing before committing. One strategic thing we -badly- need
is the ability to get stack traces with full symbols out of QA. With
that information we can double or better the productivity of bug fixing
- without it we are half-blind.

	Fridrich has been working on getting stack traces / symbol servers
setup for Windows for the last several months; he is currently on
vacation - no doubt he'll give an update on that when he gets back. It
is an enduring frustration to me to be missing that piece.

> On the other way - paid support as a first answer for bug fixing is a
> deadend. Corporate users can count their assets. They are tempted by "free"
> software and they expect it just works (interoperates with their customers).

	If we cannot build a successful business ecosystem around LibreOffice
we're doomed IMHO. Luckily I don't share your belief that no-one wants
to pay to support development - though aggregating such demand can be
challenging.

> That is all for today. Hope to see some ideas in ESC minutes some
> day and more QA volunteers.

	It's really not clear to me what you're looking for: surely you're not
asking for the whole project to stop working on features, and focus
exclusively on bugs for a year ;-) that seems an unrealistic expectation
to me - we have to move forward as well as fix our huge legacy of bugs,
as well as the new bugs we create. 

	All the best,

		Michael.

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