[Libreoffice-qa] Reminder: QA Meeting on Wednesday

[Pedro]

Hi Robinson


Robinson Tryon wrote
>> Isn't 16% of Regressions something that TDF should be worried about?
>>
>> (713 out of 4419 open bugs, according to
>> http://nabble.documentfoundation.org/Libreoffice-qa-Minutes-of-ESC-call-2015-11-19-tp4166818.html)
> 
> I definitely would like to see that percentage drop, just as I'd like
> to see our outstanding bug pool drop to at least half. As Bubli
> pointed out last week, there is a certain amount of interpretation to
> how we categorize and prioritize a "data loss bug":
> "Loss of some 10k row sheet full of 2 years of scientific work data is
> in slightly different category than, dunno, loss of text highlighting
> in an article," so perhaps some of our bugs might need re-evaluation,
> and/or we might need to consider regressions in a slightly different
> light?

Obviously there are different degrees of regression (but that is what the
Importance fields are for).

But regressions are a major source of aggravation. People expect
consistency. This is true from software to restaurants. If something that
used to work/be good looses function/quality then people will look somewhere
else.


Robinson Tryon wrote
>> How can QA (Quality Assurance) and TDF motivate the Devs to worry about
>> the
>> consistency of the program?
> 
> I think we're pretty consistent on providing QA/Bugzilla stats to the
> devs, as well as searching-out some critical/widely-affecting bugs and
> getting those in their field of vision.

I think that QA is doing it's best (particularly on having new bugs
triaged). I think what is failing is to convince the Devs that Quality (and
possibly adoption of LO) is affected by regressions and long standing bugs
and that some more time needs to be dedicated to that (however boring that
may be... triaging bugs is not always fun, so QA people know about
boring...)

Now that Collabora has a paid version (by the UK government) which is a 3
year LTS some of these bugs might start to be squashed and contributed back
to the Master branch...

A sugestion: maybe have a branch dedicated to bug fixes every other year?
Example: let's say 5.1 is dedicated to fixes. Then a slight change of
schedule would postpone 5.2.0 to some months later so that most devs would
concentrate on 5.1 (of course new features would still be added to Master in
this period) instead of being split by two concurrent branches...

Pedro



--
View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Reminder-QA-Meeting-on-Wednesday-tp4167253p4167320.html
Sent from the QA mailing list archive at Nabble.com.