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
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
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
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
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
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
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
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
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
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
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
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.
> >
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
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
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:
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
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
> 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
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.
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
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
21 matches
Mail list logo