<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 31, 2018 at 10:41 AM Giovanni Manghi <<a href="mailto:giovanni.manghi@gmail.com">giovanni.manghi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> This code freeze period will need to be associated with a strict definition of "blocker issues" that really need to by adressed immediatly. This issue here is a great example of a valid blocker.<br>
<br>
big fan of the "no known regressions admitted", at least for LTR releases.<br clear="all"></blockquote></div><div><br></div><div>The problem here is the "known" part: if we had more testers on the nightlies during the two weeks before the release date, we would probably have catched some of these regression in time to fix them.</div><div><br></div><div>I think that it would be a good idea to create a group of volunteer testers, like we have for translators, that can regularly run test cycles (for example going through the tutorials that we already have).</div><div><br></div><div>We might want to introduce the concept of release candidate, in order to have a stricter code freeze, and give the testers and translators some amount of time for testing and translations, during this time only "real" bug fixes should be allowed.</div><div><br></div><div>That said, I think that "release early release often" is still the best way we can handle release cycles.<br></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Alessandro Pasotti<br>w3:   <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div></div>