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.
This is not related to the Fedora proposal that I'm planning to submit today regarding the update of Go. I do not pretend to change anything for the next Fedora release, but at least have an idea of if what we are doing right now can be improved.
The current state:
Each Fedora release has a major release of Go available.
For example, Fedora 33 had 1.15, and Fedora 34 had 1.16.
The problem:
I see two main issues with this approach.
1. 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. 2. 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].
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.
Another hypothetical approach could be using modules with each upstream supported release in a stream.
To help in the decision, I made a report tool/web page [1] that shows the current state of the packages that depend on Go (Thanks to the COPR API).
It compares the builds of every single Go dependent package in Fedora 35 using the current available Go package with the same list of Go packages but using the Go package is available on Fedora Rawhide. To rephrase it, it compares Fedora 35 packages built with Go 1.16 with Fedora 35 packages built with Go 1.17.
As you can see, right now, from the 1901 packages that depend on Go, 196 have some sort of change and 1705 built exactly the same. You can search for "Same results" or "Something has changed" to see this. Or by the name of the package.
The report is not smart enough to say what happened right now so some "issues" are in fact improvements like golang-github-cactus-statsd-client, others like golang-github-briandowns-spinner are real issues.
My idea is to improve this report with your suggestions. Hence, if a new Go major release is available, we can confidently say that the package can be updated in the middle of a Fedora release.
[0] https://github.com/containers/podman/pull/12544
[1] https://alexsaezm.fedorapeople.org/report.html -> let it load, it has a JS that allows you to search
On Mon, Dec 13, 2021 at 02:22:24PM +0100, Alejandro Saez Morollon wrote:
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.
Another hypothetical approach could be using modules with each upstream supported release in a stream.
This seems like the thing Modularity was invented to do, and would have the advantage of being able to be consistent across a release with a "baseline" version but also provide options.
On Tue, Dec 14, 2021 at 5:01 AM Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Dec 13, 2021 at 02:22:24PM +0100, Alejandro Saez Morollon wrote:
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.
Another hypothetical approach could be using modules with each upstream supported release in a stream.
This seems like the thing Modularity was invented to do, and would have the advantage of being able to be consistent across a release with a "baseline" version but also provide options.
But AFAIK, only users can select a module stream, right? I mean, packages can't be build on top of a module stream so new needs of package maintainers cannot be satisfy with modules.
I'm curious about how other SIGs deal with these scenarios...
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ golang mailing list -- golang@lists.fedoraproject.org To unsubscribe send an email to golang-leave@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/golang@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sat, Dec 18, 2021 at 09:11:08AM +0100, Alejandro Saez Morollon wrote:
But AFAIK, only users can select a module stream, right? I mean, packages can't be build on top of a module stream so new needs of package maintainers cannot be satisfy with modules.
Packages _can_ build on top of a module stream, but only if they themselves are in other modules. Partly, this is a consequence of us deciding not to have a "default module" functionality in Fedora, but the _general_ thing is that modularity conceptually isn't really good for having arbitrary versions of low-level tools.
It's best for whole language stacks meant for end-user selection, and for big (like, "that's what this container or vm is _for_") applications (a database server or similar, or a web app). For example, this is a problem that it'd be ideal for: https://ask.fedoraproject.org/t/shipped-versions-of-php-and-zabbix-frontend-...
It can also be used for desktop apps that have separation through Flatpak.
It's not good for "many multi-purpose utilities and small tools in Fedora Linux need to be built with one version, others need another version. (And I think part of our misstep in bringing modularity to Fedora was opening it up for folks to try basically anything... like the Jurassic Park thing, it turns out that just because you _can_ doesn't mean you _should_, and I think we'd have been more successful drawing those lines. But, ah well.)
So anyway, back to Go — I think that's basically the line on deciding how to package this:
A) Are multiple versions primarily for _users_ and for a few "large" (in the sense of "likely to be deployed as sole tool in a container or vm") apps, or
B) Is it important to have multiple versions to build many different packages in Fedora Linux itself?
In case A, modularity _should_ be a solution (and although I know people are despairing about the technology overall, it's still being worked on and we should figure out and fix anything that's less than ideal). In case B, it's probably best to offer parallel "compat" packages, or use one of the other "alternatives to modularity" approches people have suggested.
golang@lists.fedoraproject.org
-
Alejandro Saez Morollon -
Matthew Miller