On Tue, 2017-11-21 at 10:05 -0500, Neal Gompa wrote: > On Tue, Nov 21, 2017 at 4:22 AM, Jan Kurik <jkurik@xxxxxxxxxx> wrote: > > On Mon, Nov 20, 2017 at 7:45 PM, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > > > On 17 November 2017 at 13:30, Randy Barlow <randy@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > Greetings fellow Fedorans! > > > > > > > > During today's FESCo meeting[0], there was discussion around a proposal > > > > to increase the freeze period from 2 weeks to 3 weeks[1]. Several > > > > members of FESCo thought this proposal might be unpopular with Fedora > > > > developers, so a compromise proposal was made: increase the beta freeze > > > > to 3 weeks, but keep the stable freeze at 2 weeks[2]. > > > > > > > > We would like to ask for feedback from the Fedora community about this > > > > proposal. Feel free to reply here, or comment on the FESCo ticket. > > > > Thanks in advance for your thoughts! > > > > > > How many of the last "long" freezes have happened because of bad > > > software and how much has happened because other issues caused > > > composes to actually test not to be created? We "seem" to spend a lot > > > of the freeze working for an actual working compose before we can > > > actually see what is going on in with the software that people want. > > > > > > Would it make more sense to just have the Freeze not start until we > > > have a bootable compose? [I realize this is a overflowing stack > > > recursive loop if not defined adequetely define bootable but if QA > > > can't test an install until week 2 of the freeze.. we weren't ready to > > > freeze for packages. > > > > I do not think this is the case. > > > > In general there are two types of composes. We have nightly composes > > and we have RC composes. The nightly composes are built on daily basis > > and even these fail from time to time, we mostly have a new "bootable > > compose" every day. The reason why we spent most of the time of a > > Freeze period waiting for an RC compose is a condition that an RC > > compose must not contain any known blocker. So, it is not matter of > > the compose it self, it is a matter of fixing know blockers before QA > > can ask for and RC compose. Also the reason why a Freeze period is > > prolonged is typically an unresolved blocker(s). From outside it might > > look like an issue with an RC compose it self, but in fact the RC > > compose is typically blocked by a blocker bug(s). > > > > Note: what I wrote above does not apply to Fedora Modular Server, > > which is a special case due to extensive changes in development > > infrastructure. > > > > So then my question is, *why* do we do freezes at all then? Can't we > just cherry-pick updates into compose trees independently? We do freezes so that people don't suddenly make an unneeded change to the base content which causes a new release-blocking bug. If we don't have freezes, we run the risk of getting to the point where we're almost done, there's just one more blocker to fix, and....someone lands a new version of glibc that breaks everything. (Etc.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
