Subject: Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

From: Ricardo Wurmus <[email-masked]>
Date: Mon, 17 Mar 2025 18:07:42 +0100

Ludovic Courtès <[email-masked]> writes:

>>     c) A discussion allowing write-access for dedicated 
>>     branches.
>
> Opening a PR gives access to a dedicated branch; I suppose that 
> would be
> the main approach, available to everyone.
>
> Getting a dedicated branch on the guix/guix repo wouldn’t be 
> different
> from now, where committers can create branches on their own.
>
> What would you add on this topic in the document?

Can we as "owners" of the repository grant individuals write 
access to a dedicated branch that was opened by a pull request? 
This would allow a team to grant a collaborator write access to 
pushing to their team branch.

I suppose even if this worked in principle we'd have the problem 
that commits by these collaborators would have to be signed by a 
known key in the keyring.

>>     b) “scalability will be the major concern here; additional
>>         developments may be needed to consolidate this support”
>>
>>         Why not automatically create AGit PR from Debbugs for 
>>         1-2 months
>>         and guard the issues?
>
> What would it buy us?

Is the goal here to give the Codeberg bug tracker an honest try 
before committing to switiching over?  I think the downsides of 
increased confusion weigh heavier.  It is already confusing that 
debbugs sends confirmation emails that mention something other 
than issues.guix.gnu.org.  Increasing the number of systems to 
three does not seem like a good idea to me.

>>      All in all, the milestones I’m proposing could be:
>>          
>>       i) Teach etc/teams.scm for refusing single patch with 
>>       less than 5
>>          lines or series including more than 10 patches; 
>>          instead ask to
>>          send it via PR.
>>
>>          Keep that for 3-4 months; feed the fixes about items 
>>          a)--d)
>>
>>      ii) Only mention Codeberg in the documentation starting on 
>>      11th of
>>          September.
>>
>>     iii) Increase the rule of etc/teams.scm for refusing more 
>>     patches.
>>
>>      iv) On 1st of December, The Big Move.
>
> An incremental move from guix-patches to PRs as you suggest 
> sounds
> perfectly reasonable to me (I see a risk of fragmentation 
> between the
> two systems but maybe it’s unlikely, as Vagrant’s experience 
> suggests).
> I’m not sure whether/how ‘teams.scm’ could help here, but I’ll 
> propose
> changes along these lines.

Can we already reject patches that have been sent without 
involving our tooling?  (E.g. without Cc-ing a team.)  Only then 
could we enforce anything like the above.

-- 
Ricardo