On Tue, 2017-11-21 at 10:05 -0500, Neal Gompa wrote:
On Tue, Nov 21, 2017 at 4:22 AM, Jan Kurik jkurik@redhat.com wrote:
On Mon, Nov 20, 2017 at 7:45 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 17 November 2017 at 13:30, Randy Barlow randy@electronsweatshop.com 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.)