[Libreoffice-qa] LibreOffice releases (was: Reminder: QA Meeting on Wednesday)

[Bjoern Michaelsen]

Hi,

On Wed, Nov 25, 2015 at 04:27:58PM -0700, Pedro wrote:
> But since you can't ask the developers to do such a boring job, even that
> won't solve the problem...

Thats not entirely true. Yes, just asking some random developer to fix some
random regression (likely by another developer) is a very bad idea as it
assumes guilt by association. Bibisecting a regression and asking the developer
who causes the regression to fix it ... is less of a problem. There still might
be valid reasons from this developer not being able to care for this particular
regression at this point in time, so dont assume this to be a strictly mechanic
thing.

Note however that regressions _are_ being watched at the ESC. And people are
also watching who caused them (which is only possible when they are
bibisected) and where -- at least I am doing this already for quite a while. Im
not calling names in public though, as that would likely be very
counterproductive. It would only be a last resort if things go really out of
hands.

So QA can help here by really bibisecting bugs: Bibisected bugs tell developers
where we cant be braver and we are going too fast and loose. Good data on
bibisected regressions allows developer to handle things properly. However,
organizing the response has to happen between the developers (e.g. on the ESC)
as it would be foolish to assume a strictly mechanical handling to be helpful
here.

Best,

Bjoern

P.S.: If you want to raise visibility to regressions in a helpful way, I
suggest you start with a _positive_ motivation for developers. E.g. QA giving
out a badge each month for the three developers with (most simple approach):

- a/ the most commits
- b/ without a regression known to be bibisected down to a commit of him/her

I assume something like that might create some good and _positive_ motivation
in the right direction ...