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!
[0] https://meetbot.fedoraproject.org/fedora-meeting/2017-11-17/fesco.2017-11-17... [1] https://pagure.io/fesco/issue/1790 [2] https://pagure.io/fesco/issue/1790#comment-480090
On Fri, Nov 17, 2017 at 1:30 PM, 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!
[0] https://meetbot.fedoraproject.org/fedora-meeting/2017-11-17/fesco.2017-11-17... [1] https://pagure.io/fesco/issue/1790 [2] https://pagure.io/fesco/issue/1790#comment-480090
If anything, I'd rather see the freezes shortened. With how fast we do composes and things like that, I do not see a good reason to make longer freezes. This last freeze was incredibly annoying. At least for me, it led me to have to wait for my Bodhi updates to merge long after they've reached karma...
----- Original Message -----
From: "Neal Gompa" ngompa13@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Friday, November 17, 2017 7:40:59 PM Subject: Re: Proposal to increase the beta freeze to 3 weeks
On Fri, Nov 17, 2017 at 1:30 PM, 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!
[0] https://meetbot.fedoraproject.org/fedora-meeting/2017-11-17/fesco.2017-11-17... [1] https://pagure.io/fesco/issue/1790 [2] https://pagure.io/fesco/issue/1790#comment-480090
If anything, I'd rather see the freezes shortened. With how fast we do composes and things like that, I do not see a good reason to make longer freezes. This last freeze was incredibly annoying. At least for me, it led me to have to wait for my Bodhi updates to merge long after they've reached karma...
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Longer freezes also mean that users who upgrade their systems during the freeze, get various NVR conflicts due to updates having already been pushed for their stable release but not for the n+1 fedora and bugzillas start piling up as it happened on the last freeze. So I concur with Neal here. However that's only one side of the coin.
If an extra week of testing would provide a more robust release, I wouldn't really mind.
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.
[0] https://meetbot.fedoraproject.org/fedora-meeting/2017-11-17/fesco.2017-11-17... [1] https://pagure.io/fesco/issue/1790 [2] https://pagure.io/fesco/issue/1790#comment-480090
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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.
Jan
[0] https://meetbot.fedoraproject.org/fedora-meeting/2017-11-17/fesco.2017-11-17... [1] https://pagure.io/fesco/issue/1790 [2] https://pagure.io/fesco/issue/1790#comment-480090
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
-- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On 21 November 2017 at 04:22, 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.
Thank you for clarifying the below. I have worked on Fedora Project for N years and it is clear that I have been going off some wrong views.
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.
Jan
[0] https://meetbot.fedoraproject.org/fedora-meeting/2017-11-17/fesco.2017-11-17... [1] https://pagure.io/fesco/issue/1790 [2] https://pagure.io/fesco/issue/1790#comment-480090
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
-- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
-- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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?
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.)
On Mon, 2018-03-05 at 11:35 -0800, Adam Williamson wrote:
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.)
Sorry for the thread necro, didn't notice I had a filter applied :)
-
Adam Williamson -
Charalampos Stratakis -
Jan Kurik -
Neal Gompa -
Randy Barlow -
Stephen John Smoogen