Re: Golang go-updates feature branch?

[John Kehayias]

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