On Mon, Dec 13, 2021 at 2:25 PM Alejandro Saez Morollon <asm@xxxxxxxxxx> wrote: > > I've been thinking a little about how Go is updated in Fedora. I would like to hear other opinions about the current state of the releases and improve it. (snip) Sorry for not seeing this email earlier. I have been sending all mail from the golang list to /dev/null for my sanity's sake, and this thread has fallen victim to that. > Both Go and Fedora have release cycles of 6 months, so the schedule is a little tight. Go releases can be delayed and have issues in the mass rebuild phase. > A user needs to wait for the next Fedora release to get a new major version of Go. So consequentially, they will tend to download from upstream, making the Go package just necessary for dependencies but with little use on its own. Also, backport bugs to Fedora releases might be a problem. Releasing packages that depend on new features are an issue too [0]. If the release cycles of Golang and Fedora are conflicting, there's nothing we can do. It might not be the "best" outcome considering the "First" foundation, but what about just ... *not* bothering with making the tight squeeze? If it's too tight to get Go X into Fedora Y in time, then just update to Go X when it's ready, only in rawhide (Fedora Y+1). That way, Fedora releases get the most recent, stable Go version that was available at the time. (This is already what happened with Go 1.17 in rawhide earlier this year). And is keeping older branches really such a problem? I see that upstream keeps releasing bugfix / point releases for older golang branches. Fedora 34 and 35 have golang 1.17.11 (!) right now, so that should not be a problem for our 1-year+one-month lifecycle? > What I think is an improvement: > > Suppose a new Go major version is released in the middle of a Fedora life cycle. In that case, I think it is an improvement for the user to be able to update to the following Go release. > > A hypothetical new release cycle would look like this: > > Fedora N release follows Go upstream as close as we can. > Fedora N-1 sticks with the latest major version of Go that was available on it until the release of Fedora N. I think this is a *very bad* idea. Thankfully, I now maintain only one package that uses golang (though with a lot of vendored dependencies), but it still breaks with almost every major release of Golang for some inexplicable reason (even though Go promises forwards-compatibility ...). Updating the Go compiler in the middle of a stable release would break numerous packages, and I don't think we should put even more maintenance and unnecessary build-fixing busywork on the already stretched-thin golang package maintainers in Fedora. Just update the Go compiler to a new major version when it is ready, only in rawhide. There, package build issues can be resolved without impacting or blocking updates on stable releases, and then let the new Go trickle down into the next stable release. That's how the Rawhide -> Fedora train works for a reason (GCC, Python, Ruby, LLVM/Clang, etc. all work this way; the only different toolchain is Rust, which is updated - thanks to very very strong forward-compatibility guarantees - every 6 weeks). Honestly, I do not see the problem with how things currently work. Isn't it normal that "the new hotness" is first baked to perfection in rawhide, until it is then released with the next stable Fedora release? Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
