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? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
