7:54 p.m.
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
10:24 p.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to
devel-leave(a)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.
12:50 a.m.
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
1:02 a.m.
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
2:18 a.m.
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
:-(
3:37 a.m.
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.
10:48 a.m.
On Fri, 2019-10-18 at 07:18 +0000, 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
2:13 p.m.
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
3:04 p.m.
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:09 p.m.
On Fri, Oct 18, 2019 at 4:05 PM Matthew Miller <mattdm(a)fedoraproject.org> 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
5:01 a.m.
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
2:19 p.m.
Miro Hrončok wrote:
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
3:28 p.m.
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
3:55 p.m.
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/35baf9d60fbd57c18da48ce06...
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_Sche...
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
5:11 p.m.
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
10:30 p.m.
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
10:48 a.m.
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
11:49 a.m.
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
9:54 a.m.
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:04 p.m.
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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.
5:55 a.m.
On Thu, Oct 17, 2019 at 10:25 PM Sérgio Basto <sergio(a)serjux.com> 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
1632
days inactive
1645
days old
21 comments
10 participants
participants (10)
-
Adam Williamson -
Kevin Kofler -
Leigh Scott -
Matthew Miller -
Miro Hrončok -
Neal Gompa -
Petr Viktorin -
Richard Shaw -
Sérgio Basto -
Zbigniew Jędrzejewski-Szmek