[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 Mon, 2012-08-13 at 09:38 -0700, bfo wrote:
> Unfortunately those graphs are discouraging in many ways. Especially if one
> thinks about upgrading LO...

	Sure - of course I want to get on people's case ;-) we don't show any
visibility of the overall number of non-regression bugs that were fixed
(introducing a few regressions) and so forth: so it's not a
hyper-balanced view. We also count some classes of regression bug
(crashers) twice to try to increase focus etc. ;-)

> > 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. 
> > 
> Does QA OKeyed this decision? What QA actions were taken before such move?

	QA was involved in the ESC call that made the decision here.

> Regression tests prepared? Any tests in general? Manual tests?

	Of course the filters are tested; there were -zero- unit tests for the
RTF filter before we started, it is now perhaps -the- most unit tested
filter that there is - every bug fix Miklos makes has a nice unit test:
better - since the code is shared, that is unit testing a big chunk of
the DOCX and perhaps DOC filtering as well.

> > There is testing before committing. 
>  
> Tests as regression tests 

	Tests as in running the code to check that it continues to work - and
fixes the bug; done by the developer. Also unit tests are run wherever
there are any, if the developer doesn't run them some tinderboxes run
the whole test suite as they build.

	We need to continue to grow that test suite of course.

> > 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.
> > 
> I am starting to doubt that it helps. I recently delivered Windows bt to
> most crash bugs I could find. Prepared wiki page about it. Asked for review
> of that page.

	Wow - I didn't hear about that; can you give me a few links ? did you
use a Windows build with debugging symbols (if not the traces would be
next-to-useless sadly).

>  Silence. Few of the bugs were fixed, without any comment if my
> bt was useful. Will keep this work, but I don't see that bugs with bts are
> fixed quicker.

	Well; crasher bugs that are windows specific are -incredibly- faster to
fix with a good stack trace with symbols.

> I think I put few cents for this myself on ML and trying to gather nice
> resources in bug https://bugs.freedesktop.org/show_bug.cgi?id=50350. Someone
> is working on it? Great. It is still UNCONFIRMED...

	I've assigned it to Fridrich; I agree it is a -really- important task
to get this done. Unfortunately there are problems, the Windows symbol
server is IIRC some hideous tangled Microsoft proprietary product that
requires a Windows server to push a few binary files (que?). This
complicates matters.
  
> I would be happy if I achieve the change in base workflow - new feature in
> the codebase? Splendid! But unit tests, testcases and manual testing done
> before commiting. QA OKeyed the feature? Then you can commit.

	Stopping people committing until you are happy is unlikely to help - we
need a socially acceptable way of improving quality: the best way we've
come up with so far is small, fast, reliable, run-all-the-time unit
tests that are in-tree.

> Focusing exclusively on bugs in one of next release (be it 3.7 or 3.8) would
> be a great idea, as please remember - a feature is a no go, when there are
> still 123bugs (123bugs as one, two, three actions needed to get LO crash).

	Is there a good list of such bugs ?

	AFAICS we need a good way to get nice work (like your bugs with
backtraces) communicated to development in such a way that they notice &
do something about it :-) Not sure how to do that - bloating the MAB
list is prolly not it though - creative ideas appreciated.

	One thing I'd like to do is make a developers' portal - we can use as a
homepage, with easy-to-use boxes to lookup bug numbers, and interesting
reports on the page: that might be rather a good way of advertising the
latest problems :-)

	ATB,

		Michael.

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