[Libreoffice-qa] Reminder: QA Meeting on Wednesday

[Sophie]

Hi Pedro,
Le 25/11/2015 16:16, Pedro a écrit :
> Hi Joel
> 
> 
> jmadero wrote
>>> 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...
>> This is literally impossible. We would have very talented developers
>> saying no way - then what? We cannot dictate (we can suggest) what
>> developers do. If we tell Developers "pause all your work and go back
>> and do just regression fixing" they respond with "no" and then . . . the
>> end.
> 
> Have you tried? Maybe some will say no (and they can continue to work on the
> Master branch) and some may agree.
> 
> Do all QA people say No when you ask them to have a Bug Hunting session? Why
> would ALL devs say No???
> 
> Why is it impossible to have a Bug Squashing Session for devs? I bet some
> would find it challenging to fix more bugs than the others.

We call them hackfests, and there are some regressions fixed there. But
as Joel said it has already been discussed, we are not a community who
forces people to work on specific tasks if they don't want too. Instead
we try to invite them, so any idea in this direction is more than welcome.
> 
> Why is it "literally impossible" to have a fix branch? Has something similar
> been proposed at the ESC meeting and rejected?

Bjoern answered you on that topic already
> 
> 
> jmadero wrote
>> Then catching regressions before they happen is, as
>> Sophi suggested, all about growing the community to do testing in Alpha.
> 
> I'm all for growing the community and for doing early tests. In fact I do
> very early testing for Apache OpenOffice (where each release is a regular
> install instead of a parallel Dev install)

Having dev installation allow our testers to chase until which version
the bug exists. At the OOo time, it was the same, only from RC1, install
was a production one. What we need is more people testing at the alpha
and beta stage, we have very few people testing there and it let a too
short time to find regression before the final version. But, we do not
recommend to install the last version until the 3rd one, so we should
find most of the regressions at that time.
> 
> However if there is no commitment from the Devs to fix regressions then it
> really doesn't matter at which stage you catch them...

No, don't mix things :) I can assure you that none of our developers are
happy with regressions. We monitor them closely. That's true that we
don't rely only on the numbers as a regression might affect a very
little number of people and in a very specific work - so it's a real
regression, but it will have much less impact that one affecting hundred
of people. The latter are monitored and attract the attention of the ESC
and are escalated, bibisected then we invite the dev to have a look at
it. If want to help in this area, we always need more people able to
bibisect those bugs and try to find the responsible commit, let me know,
I'll help you with the first steps.

Cheers
Sophie

-- 
Sophie Gautier sophie.gautier at documentfoundation.org
GSM: +33683901545
IRC: sophi
Co-founder - Release coordinator
The Document Foundation