Ludovic Courtès <l...@gnu.org> 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
