On Tue, 2017-11-21 at 10:05 -0500, Neal Gompa wrote:
On Tue, Nov 21, 2017 at 4:22 AM, Jan Kurik <jkurik(a)redhat.com>
> On Mon, Nov 20, 2017 at 7:45 PM, Stephen John Smoogen <smooge(a)gmail.com>
> > On 17 November 2017 at 13:30, Randy Barlow <randy(a)electronsweatshop.com>
> > > Greetings fellow Fedorans!
> > >
> > > During today's FESCo meeting, there was discussion around a
> > > to increase the freeze period from 2 weeks to 3 weeks. 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.
> > >
> > > 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
> > 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
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.)
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net