On Wed, Oct 31, 2018 at 10:41 AM Giovanni Manghi <giovanni.man...@gmail.com> wrote:
> > 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. > > big fan of the "no known regressions admitted", at least for LTR releases. > 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. 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). 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. That said, I think that "release early release often" is still the best way we can handle release cycles. -- Alessandro Pasotti w3: www.itopen.it
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
