Re: Next F31 push?
On Fri, Oct 18, 2019 at 4:05 PM Matthew Miller wrote: > > On Fri, Oct 18, 2019 at 09:13:22PM +0200, Kevin Kofler wrote: > > This would be a lot less of an issue if we were more actively promoting the > > respins that are already being done. > > Yeah, this is a Fedora Council goal -- we'd like for that SIG to easily be > able to make them in infrastructure, and then present them in a clear way. > > > I never install from GA images (except before the first respin, obviously) > > because it is just pointless to install an image just to have to upgrade > > half of the distro immediately afterwards. > > I usually use the netinstall image for basically the same reason. > I stopped using the netinstall image because it randomly installs kernel-debug instead of kernel due to us not fixing the bug with selecting kernel variants[1]. Starting from live media and upgrading avoids that problem... [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1228897 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On Fri, 2019-10-18 at 10:54 -0400, Matthew Miller wrote: > On Thu, Oct 17, 2019 at 11:02:51PM -0700, Adam Williamson wrote: > > We do tweak the release schedule every so often, right now the > > freeze > > periods are fairly long compared to the historical average. I do > > think > > that's given us a benefit in terms of how little slippage we've had > > for > > the last few releases, though; we could always consider freezing a > > bit > > later, but it might result in us slipping more... > > I'm in favor of continuing with the airlines' "this flight will take > three > hours -- wow, look, we're early again!" approach. Users and > downstreams > really appreciate the predictability. yeah , the marketing argument. So to not risk a (big) delay, why not test it ? whether we would have a big delay or not ? and freeze F31 again to get a really stable release, the F31.1 . Thanks, > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On Sat, 2019-10-19 at 00:11 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > Eh. I don't think it's a particularly bad hack at all. It's simple, > > labelled, we know what it does, and it's inherently limited (it'll > > never do anything outside of an upgrade to F31). > > That's exactly what makes this such a bad hack in my eyes. It "fixes" one > particular instance of this general issue, one that was found during > upgrades from F30 to F31. It does not fix any other instances of the bug, > even ones that could appear in the future in upgrades from F29 updates or > F30 updates to F31 updates. It is also a short-term fix, because the exact > same issue with libgit2 will likely still happen on upgrades from F30 to > F32, and the workaround is explicitly not applied there. That's because it's intended to have a proper fix before F32 comes out. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
Adam Williamson wrote:
> Eh. I don't think it's a particularly bad hack at all. It's simple,
> labelled, we know what it does, and it's inherently limited (it'll
> never do anything outside of an upgrade to F31).
That's exactly what makes this such a bad hack in my eyes. It "fixes" one
particular instance of this general issue, one that was found during
upgrades from F30 to F31. It does not fix any other instances of the bug,
even ones that could appear in the future in upgrades from F29 updates or
F30 updates to F31 updates. It is also a short-term fix, because the exact
same issue with libgit2 will likely still happen on upgrades from F30 to
F32, and the workaround is explicitly not applied there.
To me this feels like "fixing" a function:
bool isPrime(int x) {
return false;
}
as follows:
bool isPrime(int x) {
if (x == 31) // fix Fedora 31 blocker: 31 is prime!
return true;
return false;
}
:-)
> And yeah, I don't see this as a very bad hack in terms of 'tech debt'
> at all. We've done a lot worse in the past!
Not only does it not fix the actual issue (so it leaves the debt to actually
fix it for the next release), it also adds a hardcoded workaround that will
become dead code very soon.
Yes, Fedora has used other ugly hacks to creatively "fix" blocker bugs in
the past, some of which then ended up as the status quo for several releases
(because nobody cares about the issue anymore once it is off the blocker bug
list, so the proper fix never gets implemented). That does not make it a
good idea.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On Fri, 2019-10-18 at 21:19 +0200, Kevin Kofler wrote: > Miro Hrončok wrote: > > Actually: > > https://github.com/rpm-software-management/dnf-plugins-extras/pull/166 > > Ewww! This kind of hacks should NEVER be accepted in a production > distribution! Eh. I don't think it's a particularly bad hack at all. It's simple, labelled, we know what it does, and it's inherently limited (it'll never do anything outside of an upgrade to F31). > This hack will also NOT fix the issue for users like me who use dnf directly > rather than the system-upgrade plugin. That's not one of our official recommended upgrade methods. You don't use those, you get to workaround the bugs they fix. We will still document this in CommonBugs for people who do that, of course. Note that the unofficial script updater msuchy maintains for folks like you already has a similar workaround: https://github.com/xsuchy/fedora-upgrade/commit/35baf9d60fbd57c18da48ce068392ffcb8a0df90 > The right thing to do would be to delay the release until we have a real > fix, as long as it takes. Even if it takes weeks. And of course to unfreeze > the contents in the meantime because it could take weeks and there is no > telling how long. > > And you know what my preferred fix would be. :-) But of course it takes time > to fix the demodularization upgrade path in DNF and to demodularize at least > the modules that are causing the errors here. > > Sadly, Fedora has always preferred rushing out a release with this type of > crude hacks instead of fixing things properly, without introducing such > technical debt. And this does not seem to have changed. Sad. :-( This is an official part of Fedora's approach, it's documented in several places, where we talk about having a hybrid approach where neither time nor quality completely determines the release date - it's a combination of the two. e.g.: https://fedoraproject.org/wiki/Fedora_Release_Criteria#Release_Constraints https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Development_Schedule it's a choice we make. There are advantages and disadvantages to releasing exclusively based on quality, or exclusively based on time, or something between the two. This is the choice we picked. There isn't really a "right" one and a "wrong" one. And yeah, I don't see this as a very bad hack in terms of 'tech debt' at all. We've done a lot worse in the past! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On Fri, Oct 18, 2019 at 09:19:15PM +0200, Kevin Kofler wrote: > Miro Hrončok wrote: > > Actually: > > https://github.com/rpm-software-management/dnf-plugins-extras/pull/166 > > Ewww! This kind of hacks should NEVER be accepted in a production > distribution! > > This hack will also NOT fix the issue for users like me who use dnf directly > rather than the system-upgrade plugin. > > The right thing to do would be to delay the release until we have a real > fix, as long as it takes. Even if it takes weeks. And of course to unfreeze > the contents in the meantime because it could take weeks and there is no > telling how long. > > And you know what my preferred fix would be. :-) But of course it takes time > to fix the demodularization upgrade path in DNF and to demodularize at least > the modules that are causing the errors here. > > Sadly, Fedora has always preferred rushing out a release with this type of > crude hacks instead of fixing things properly, without introducing such > technical debt. And this does not seem to have changed. Sad. :-( I think you're being unfair here. "We" (as in FESCo and various people commenting in the bug) asked dnf people to do exactly this — apply a hack to allow people to do upgrades successfully. This ain't pretty, but the goal is to a) solve the problem for Joe User, b) do it in reasonable time. At least I am happy to see this proposed. People who use dnf directly are not covered by this, but they are also much more likely to know how to fix issue themselves. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On Fri, Oct 18, 2019 at 09:13:22PM +0200, Kevin Kofler wrote: > This would be a lot less of an issue if we were more actively promoting the > respins that are already being done. Yeah, this is a Fedora Council goal -- we'd like for that SIG to easily be able to make them in infrastructure, and then present them in a clear way. > I never install from GA images (except before the first respin, obviously) > because it is just pointless to install an image just to have to upgrade > half of the distro immediately afterwards. I usually use the netinstall image for basically the same reason. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
Miro Hrončok wrote: > Actually: > https://github.com/rpm-software-management/dnf-plugins-extras/pull/166 Ewww! This kind of hacks should NEVER be accepted in a production distribution! This hack will also NOT fix the issue for users like me who use dnf directly rather than the system-upgrade plugin. The right thing to do would be to delay the release until we have a real fix, as long as it takes. Even if it takes weeks. And of course to unfreeze the contents in the meantime because it could take weeks and there is no telling how long. And you know what my preferred fix would be. :-) But of course it takes time to fix the demodularization upgrade path in DNF and to demodularize at least the modules that are causing the errors here. Sadly, Fedora has always preferred rushing out a release with this type of crude hacks instead of fixing things properly, without introducing such technical debt. And this does not seem to have changed. Sad. :-( Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
Adam Williamson wrote: > The other issue is that it's *less bad* for a bad update to get out as > a 0-day update than it is for it to be in the frozen compose set. Bugs > that get baked into the live images or the installer are there forever. > A bug that only goes out in an update can be replaced by a fixed > update. This would be a lot less of an issue if we were more actively promoting the respins that are already being done. I never install from GA images (except before the first respin, obviously) because it is just pointless to install an image just to have to upgrade half of the distro immediately afterwards. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On 18. 10. 19 17:48, Adam Williamson wrote: On Fri, 2019-10-18 at 11:22 +0200, Kevin Kofler wrote: Adam Williamson wrote: As things stand I'm reasonably confident we'll be able to Go next week, I don't see a fix for the module upgrade path blocker in sight any time soon. There are three viable ones proposed in the bug, it's just a question of picking one. I'm gonna ask FESCo to vote on their preferred solution today if one hasn't been chosen yet. Already happening: https://pagure.io/fesco/issue/2230#comment-605570 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On Fri, 2019-10-18 at 11:22 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > As things stand I'm reasonably confident we'll be able to Go next week, > > I don't see a fix for the module upgrade path blocker in sight any time > soon. There are three viable ones proposed in the bug, it's just a question of picking one. I'm gonna ask FESCo to vote on their preferred solution today if one hasn't been chosen yet. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On Fri, 2019-10-18 at 07:18 +, Leigh Scott wrote: > > On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote: > > > > I mean, in the end it would be self-defeating, because the high chance > > that it would introduce more problems would just mean we'd need to > > freeze again for longer. > > > > So you get a working ISO for release then break it by releasing untested > updates after GA :-( They're not untested, they get lots of feedback because they're stuck in updates-testing for so long. :P The main issue is the difference between testing an update *as an update to an installed system* and testing its impact on the compose and deployment process. Bodhi is good at getting us feedback on the first of those. It's quite rare that an update gets pushed stable which really breaks stuff when you install it as an update to an installed system. The problem the freezes help with is that Bodhi is not so great at telling us when an update causes problems with the compose process or breaks the installer or something, because it's not easy to test that. (We've made it a bit better in the last year or so by having openQA build live and installer images with the update packages and test those, but that covers much less than the whole compose process and all the installer functionality). The other issue is that it's *less bad* for a bad update to get out as a 0-day update than it is for it to be in the frozen compose set. Bugs that get baked into the live images or the installer are there forever. A bug that only goes out in an update can be replaced by a fixed update. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On Thu, Oct 17, 2019 at 11:02:51PM -0700, Adam Williamson wrote: > We do tweak the release schedule every so often, right now the freeze > periods are fairly long compared to the historical average. I do think > that's given us a benefit in terms of how little slippage we've had for > the last few releases, though; we could always consider freezing a bit > later, but it might result in us slipping more... I'm in favor of continuing with the airlines' "this flight will take three hours -- wow, look, we're early again!" approach. Users and downstreams really appreciate the predictability. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On Thu, Oct 17, 2019 at 10:25 PM Sérgio Basto wrote: > Hi, > AFAIK , the logic is request an freeze exception , or next push will be > just after F31 GA . > I'd like have one unfreeze and push all packages that are waiting to be > pushed to stable, when we have an NO-GO. > I already made this request in past and, in resume, the idea was > rejected with some valid arguments, which I accepted ... > That's what I figured but it just seemed longer than normal (which Adam confirmed). I'm not used to seeing stable requests take so long. I'm sure we don't have the infra for this, but it sounds like we need the ability to allow a push in a "separate" environment and have the ability to accept or reject it (Try Before You Buy) rather than open the floodgates and hope for the best. Or maybe be able to selectively block packages that are used in the install media... Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On 18. 10. 19 11:22, Kevin Kofler wrote: Adam Williamson wrote: As things stand I'm reasonably confident we'll be able to Go next week, I don't see a fix for the module upgrade path blocker in sight any time soon. Actually: https://github.com/rpm-software-management/dnf-plugins-extras/pull/166 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
Adam Williamson wrote: > As things stand I'm reasonably confident we'll be able to Go next week, I don't see a fix for the module upgrade path blocker in sight any time soon. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On 2019-10-18 09:18, Leigh Scott wrote: On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote: I mean, in the end it would be self-defeating, because the high chance that it would introduce more problems would just mean we'd need to freeze again for longer. So you get a working ISO for release then break it by releasing untested updates after GA :-( Untested but fixable. The ISO needs to be usable on its own, but a 0-day-after-GA update can be amended by 1-day-after-GA update. Or a 7-day one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
> On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote: > > I mean, in the end it would be self-defeating, because the high chance > that it would introduce more problems would just mean we'd need to > freeze again for longer. > So you get a working ISO for release then break it by releasing untested updates after GA :-( ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote: > Sérgio Basto wrote: > > AFAIK , the logic is request an freeze exception , or next push will be > > just after F31 GA . > > I'd like have one unfreeze and push all packages that are waiting to be > > pushed to stable, when we have an NO-GO. > > I already made this request in past and, in resume, the idea was > > rejected with some valid arguments, which I accepted ... > > I have also made this request more than once and would still be in favor of > it, but the QA team is worried that this would introduce more bugs and > either delay the release further or make us ship with more bugs. It is a > tough call. I think such long freezes are a pain for packagers and also > delay (and keep out of the GA images) bug fixes and even security fixes > (also because the stable release updates are affected too if you do not want > to break the upgrade path), but I also understand where QA is coming from. I mean, in the end it would be self-defeating, because the high chance that it would introduce more problems would just mean we'd need to freeze again for longer. As things stand I'm reasonably confident we'll be able to Go next week, so it shouldn't be too much longer. As long as we don't let Kamil test it too hard and find too many blockers, of course. We do tweak the release schedule every so often, right now the freeze periods are fairly long compared to the historical average. I do think that's given us a benefit in terms of how little slippage we've had for the last few releases, though; we could always consider freezing a bit later, but it might result in us slipping more... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
Sérgio Basto wrote: > AFAIK , the logic is request an freeze exception , or next push will be > just after F31 GA . > I'd like have one unfreeze and push all packages that are waiting to be > pushed to stable, when we have an NO-GO. > I already made this request in past and, in resume, the idea was > rejected with some valid arguments, which I accepted ... I have also made this request more than once and would still be in favor of it, but the QA team is worried that this would introduce more bugs and either delay the release further or make us ship with more bugs. It is a tough call. I think such long freezes are a pain for packagers and also delay (and keep out of the GA images) bug fixes and even security fixes (also because the stable release updates are affected too if you do not want to break the upgrade path), but I also understand where QA is coming from. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Next F31 push?
Hi, AFAIK , the logic is request an freeze exception , or next push will be just after F31 GA . I'd like have one unfreeze and push all packages that are waiting to be pushed to stable, when we have an NO-GO. I already made this request in past and, in resume, the idea was rejected with some valid arguments, which I accepted ... On Thu, 2019-10-17 at 19:54 -0500, Richard Shaw wrote: > I've got an update I've requested stable on which is now at 15 > days... > > I'm assuming the pause is due to beta freeze activities? > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-95287d801f > > Thanks, > Richard > > ___ > devel mailing list -- > devel@lists.fedoraproject.org > > To unsubscribe send an email to > devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Next F31 push?
I've got an update I've requested stable on which is now at 15 days... I'm assuming the pause is due to beta freeze activities? https://bodhi.fedoraproject.org/updates/FEDORA-2019-95287d801f Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
