On Thu, Aug 2, 2018 at 7:12 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On 08/02/2018 05:04 AM, Neal Gompa wrote: > > > This might surprise you, but I actually prefer the current way. It > > makes activating Rawhide an explicit action that can stay carried > > forward. > > The same for the proposed change, once you install fedora-release from > rawhide you are on rawhide until and unless you intentionally switch. > > >The other thing is, realistically, few third party folks try > > to build for Rawhide because Rawhide snapshots are either too old or > > too broken. > > > > Case in point, the Docker containers for Rawhide effectively look like > > Fedora 28, so what's the point? And upgrading to the latest released > > compose just breaks everything, so it's not useful there either. > > I've been looking into this the last week or so by chance. Rawhide does > compose containers every day with rawhide compose, they are just not > correctly uploading to our registry. Hopefully this will be fixed soon. > > I don't think the answer to something being old or broken is to sigh and > wander off. We need to fix those things, and I think we are making > progress on doing so. > > > This change makes no sense unless we were actually going to make > > Rawhide something that people could rely on. And I'm not sure that's a > > good idea, since we have a nice cadence of releasing every 6 > > months(-ish). It's already too hard to keep Rawhide working because of > > GCC breakages and the DNF stack work, and upstreams rely on our > > Rawhide tree to suss out these kinds of things. > > I'm not sure I follow here... you don't think we should make rawhide > something to rely on because we have regular releases? > I'm saying that if we try to pull off something similar to openSUSE Tumbleweed with our current infrastructure and tooling, upstreams like GCC and glibc could no longer leverage our Rawhide to validate their code. > In any case I think rawhide is very useful and without it our stable > releases would be vastly more diffcult. We can definitely do better to > make it stable, but I think it's quite usable. It's not usable whenever we have compiler transitions or add more weird GCC plugins, and that's something I've accepted will never change as long as we're the distribution that helps make GCC great. And that's fine. > > > > And I would argue that special casing Rawhide is sort of the point, > > but I have no objection to making dnf --releasever=rawhide distro-sync > > also work. I just don't think it's smart to drop the release number > > thing and the fedora-repos-rawhide package. > > The number will keep working too. We can make that an alias in > mirrormanager. So, for example if we had this implemented now and we > branched 29 off, '29' would point to the branched release, '30' or > 'rawhide' would point to rawhide. If you installed fedora-release from > rawhide it would keep you on rawhide, if you install from branched or > distro-sync to the branched fedora-release (by doing a 'dnf > --releasever=29 distro-sync fedora-release') you go on branched. This > means you don't need to worry about fedora-release-rawhide and > enabling/disabling repos, and makes everyone's life easier. > But the problem is that it does make things slightly harder. And you're not quite correct about this. The way that DNF gets this value is through identifying the package that provides "system-release" or "distribution-release" and identifies the version set for the package. That version is what propagates to set $releasever. Hilariously, PackageKit independently reads VERSION_ID from os-release(5) to determine this. These don't always agree. And in addition, it's impossible to stay on Rawhide through PackageKit without the controls through fedora-repos-rawhide forcing it. And how do you propose people sync down from Rawhide to "branched"? Or sync up from an old Rawhide to "branched"/"stable" which this change? >From what I can tell, that wouldn't be easy. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/MQQFHZNTJS4AZ6Y52264LXNGOOHJBAO4/
