Subject: [bug#76407] [GCD] A better name for the default branch

From: Liliana Marie Prikler <[email-masked]>
Date: Wed, 19 Feb 2025 20:01:45 +0100

Hi,

Am Mittwoch, dem 19.02.2025 um 17:21 +0000 schrieb Christopher Baines:
> > +  1. the `branch` field in `.guix-channel`;
> 
> This doesn't exist as far as I'm aware?
> 
> That record does have a url field, which is important as it means
> that Guix can highlight when there is a mismatch between the URL
> being used and the contents of the channel.
> 
> I think it's worth considering what a similar mechanism might look
> like for branch names. Maybe Guix could have a notion of whether it's
> using the "primary" branch for a channel (if you pull or time-machine
> to a specific --branch, this is ignored), and that record could
> contain the name of the primary branch, and then Guix could highlight
> when the two differ.
Nice catch.  I did copy the wording from the Codeberg GCD, which talks
about updating URL.  If `branch` is not considered by .guix-channel,
that's one field less to update.

> That mechanism would allow for clearer messaging to users, since they
> could see it again and again, rather than a news entry which would
> usually only be shown once.
> 
> > (define-record-type* <channel> channel make-channel
> >   channel?
> >   (name      channel-name)
> >   (url       channel-url)
> >   (branch    channel-branch (default "master"))
> >   (commit    channel-commit (default #f))
> >   (introduction channel-introduction (default #f))
> >   (location  channel-location
> >              (default (current-source-location)) (innate)))
> 
> Is changing or removing the channel-branch default in the scope of
> this GCD?
I think channel-branch should reflect the new default.

> I'm in two minds about this. It's just the default, so it's trivial
> to change it for the default channel. But ignoring it doesn't seem
> consistent with the rest of the proposal.
> 
> Additionally, if the guix channel changes, then this might encourage
> people managing other channels to make similar changes, and I think
> there might be different and potentially more serious technical
> issues with managing that change. I think it would be sensible to
> ensure there's a good path for channels in general to change branch
> naming before making the switch for the Guix channel.
Perhaps we could warn channel authors in advance that the default
branch is subject to change and ask them to set "branch" explicitly.

> > +Following this commit, an entry in `etc/news.scm` would explain
> > the
> > +migration.  The `master` branch would then point at the commit of
> > said
> > +news entry, and would need to be updated only after said news are
> > +translated into another language.
> 
> In this scenario, assuming you're suggesting only pushing the news
> entry related commits to "master", I think the branches diverging
> would be problematic.
The point here is that we don't have to keep master updated
indefinitely, but it should point towards a commit that is also on
main.  Denis 'GNUtoo' Carikli has another idea using symbolic
references.

> Assuming you're using the default channel configuration, if you pull
> to one of these commits on "master", which isn't on the new master
> branch, then I think the next time you go to pull, you'd hit the
> downgrade protections (or at least you should do), since this is
> exactly the kind of downgrade attack that it's trying to prevent
> against. You'd be pulling a commit which isn't a descendant of the
> commit you're currently on.
See above.

> ...
> 
> I also haven't even started to think about what implications this
> would have for the services I'm involved with maintaining. The data
> service instances and the bordeaux build coordinator all have current
> and historic references to the "master" branch. In particular, the
> data service goes beyond branches being pointers to commits and
> records the state of branches over time.
> 
> It isn't immediately obvious to me how the data service could be
> adapted to handle branches changing name to both capture that a
> branch may have never actually pointed at a commit, but that commit
> is in the history of the branch in the Git sense. I think with the
> current behaviour, we'd have the history of the "master" branch
> (unless that's deleted), and then separately the history for the new
> master (not "master") branch, but that would start when that branch
> was cteated, and the two histories would be separate from the view of
> the data service, and this representation seems rather lacking.
Good point, we should add a section talking about the Guix Data
Service.

Cheers