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.gaut...@documentfoundation.org GSM: +33683901545 IRC: sophi Co-founder - Release coordinator The Document Foundation _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/