Re: Golang go-updates feature branch?

[John Kehayias <john.kehayias@protonmail.com>]

Hi Leo! and hi Guixers,

On Sun, Jan 08, 2023 at 02:22 PM, Leo Famulari wrote:

> Hello!
>
> Now that our build farm is running smoothly, I propose we revive the
> practice of feature branches, when appropriate.
>

Heartily agree here. This has come up a few times on #guix and generally with support (don't let me speak for everyone though). I think the idea of smaller and more frequent feature branches is a great idea: less code changes coming to master to review at once (compared to big core-updates merges), substitutes and closer to master to be easier for people to pull the branch and test, and some areas despite the number of builds would work nicely as a branch than just pushed (and lingering) into core-updates for much later.

> The first one that I propose is a go-updates branch, where we update the
> Go compilers. This will affect ~500 packages.
>
> If I understand correctly, Go is a relatively self-contained reverse
> dependency graph within Guix and thus a good candidate for this
> approach. It contains the Go libaries, and then some end-user
> applications, and they don't really affect other packages. So, it should
> be easy to understand when the update is ready to push.
>

I can't comment on the Go ecosystem, but that sounds good to me.

Another one I would personally like to see is Mesa: they move quickly, newer versions are needed for recent hardware, and despite the number of rebuilds it causes Mesa is careful with removing older support. This is also an area where getting people to test by running their desktop system on a newer version would be helpful, and I think the feature branch approach makes it much easier (i.e. in core-updates there is a ton to test and look for).

Anyway, perhaps that is a separate discussion and part of a larger discussion on number of rebuilds and how we classify changes.

> I can set up a jobset on ci.guix.gnu.org if people like the idea.
>
> Leo

So yes, I'm all for this general approach and think it is one that will make Guix better for the end-user and on the development side.

Thanks for bringing this up Leo, something I've also been wanting to move towards!

John