On 1 November 2015 at 22:14, Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: [snip] > On Sun, 2015-11-01 at 20:03 +0100, Kevin Kofler wrote: >> IMHO, we should have at most 1 week of strict freeze. If we decide >> that we >> have to slip anyway, then we should pull in ALL updates pending >> stable and >> restart the release process (freeze, spin RCs, test) from there. >> >> (That would also make it less painful to slip multiple times and thus >> decrease the pressure to rush out quick hacks to work around blockers >> instead of clean fixes.) > > I think Kevin is closer to right on this. It's unreasonable to have 500 > updates queued for users on release day. Yeah, freeze is required to do > QA on the release, but QA on the release is not worth so much if it all > goes out the door the first time someone clicks update. (Well, it's > essential for the installation process, but beyond that....) > [snip] I think it is to some extent a question of what we are QA'ing for. As I see it (and I may be in the minority), the QA process is a process put in place to ensure the *install and live media* function correctly, and produce a working installed system from which the user can move forward with updates. QA has never made any efforts to QA updates, presumably because there's just not sufficient resource. So, in a resource limited world, I think the QA team are doing the most sensible thing they can do with their limited resources. In lieu of QA resource for updates, we have imperfect community processes which we hope provide QA for subsequent updates, though unfortunately the community base that has tested those 500 updates that are available on release day are probably far less than for updates produced after release, when more folks have the release distro installed and are using it and testing updates. I think that's the issue that we could address by engaging the community more though. Any other proposal requiring more from the QA team has to identify where that extra resource comes from. Cheers, Jonathan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
