N@j0rge @Kyle Gospo Myself and @Skynet were discussing the option of pinning users to specific versions of Fedora instead of shipping users on latest or stable. This could be implemented through ujust and Yafti so users can choose when they do a major upgrade between Fedora releases.
JI'm not against that but I want to see how this F40 release works out since it'll be the 2nd one we've had.
Jbut generally speaking I want bluefin to evolve past major release "versions" and "you need to a dist upgrade every 6 months"
KI think stable just upgrading to the next is a feature
KAnd I have zero desire to support previous releases in a gaming OS
KSo none for me, sorry
JI only default to gts because I am very risk averse for my work machine on fedora due to kernel regressions.
Jthough maybe when we have centos builds that might solve the problem for a subset of users
Aimo theres some value in stable != latest, ie moving stable manually once we know a set up is 100%. Even if its only a couple hours. Would save a lot of headaches
JI am strong -1 on manually gating tags
J(but that's for bluefin)
FAren't kernel versions pretty much matching between previous & last release?
FHaving GTS can be useful for Gnome extensions though
Jno, there's just enough of a delay I found
Mso long as it automatically rolls I'm happy. My coworkers love the fact that they don't have to do a major operation every 6 months and instead its just part of the normal update cycle.
For gts vs latest, we are all on latest and so far haven't had any needs to go to gts because the kernel seems to be the same in each. GTS was handy when new releases came out for extensions and have an easy target when the dot release broke stuff. Have looked at trying to do ucore on desktop though for that slightly slower kernel.
For gts vs latest, we are all on latest and so far haven't had any needs to go to gts because the kernel seems to be the same in each. GTS was handy when new releases came out for extensions and have an easy target when the dot release broke stuff. Have looked at trying to do ucore on desktop though for that slightly slower kernel.
KWe just need to use :testing for that purpose, it's already set up
K:unstable too
SThe reasoning I was thinking: every other OS requires you to run a command to change major release versions. By default, it could match everyone else where it is locked to a major release with a just command to switch to latest or gts or do the upgrade to the next major release. Or it could be in the welcome setup that it asks which one you want to be on
Acan you manually move :stable to point to a test build?
KYes, they're separate branches
KCan move what we need to stable anytime we like
KI'm also separating the copr repos between the two
Athats because on a normal distro upgrading is a hour long process that may end up with the computer dying right? Ive never had an ubuntu upgrade go 100%
SDownloading a new image that's your entire OS is still going to take a while and it can still break everything if some of the configs don't match up
Amy idea would be to have the stable branch build as edge and manually move stable to point to it a couple hours or days later. So you know 100% the image is tested and works etc. WIthout having potential mismatches.
Aand if youre sure it will work 100% move it immediately
KWe don't have diffs right now so we do that every single update regardless
KYeah, that's ready to go and a simple methodology change on our end
KIf you set up a 2nd HHD Copr that can be used in :testing
NI would love full end to end testing of the ISOs as well where it attempts to boot and install from the ISO and runs automated tests on it.
KAnd then you have a way to test and version gate
KAnd this is one place copr shines @antheas
KJust fork it in copr, name it hhd-testing
Ai need to work on the coprs. Probably make spec files pull from github
KAnd I'll make :testing point to it
KThen have it auto build like the current one does
KAnd turn off auto build for stable
KLastly, have stable build from a static tag or commit that you ratchet as you're satisfied
KThat's how all the Bazzite coprs work atm
Nso it sounds like to me maybe we just need to have a more defined process for testing to production if we are going to do a rolling model for Bazzite?
NBluefin already has GTS and it is the preferred image we ask folks to use.
KI mean, I'm just stating the model I use. Happy to document it
Nthough it might be good to have a testing image before it moves into latest.
Apretty much, imo having a bunch of guys on discord sanity check the build for a day is plenty
Alike 80% of the work
Athen when youre happy you just point stable to it and everyone upgrades
Nyeah, I'm more talking about the ISO build process.
Aor if something goes wrong you tell the tester just move to stable
NI don't like downloading and testing 12+ ISOs to make sure they worked 
Atrue
