Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[Simon Tournier]

Hi Ludo,

On Sat, 08 Feb 2025 at 17:43, Ludovic Courtès <ludo@gnu.org> wrote:

>> Sorry if my understanding is incorrect, but if we do not increase the
>> number of people with specific/dedicated/controlled write access, the
>> move to Codeberg is useless.  Provocative on purpose. ;-)
>
> As I mentioned in the GCD under “Workflow”, at the Guix Days, and in the
> message you’re replying to, I think we should adapt our workflow to
> empower team members to merge (or queue) changes without being
> committers themselves.

Define committer? :-)

Somehow, my point is that we need to take the opportunity to also
re-think what means Committer, Team member, etc. and the implications
about write access and “duties”.

By committer, you read “write access to the master branch” when I read
“write access to some upstream branch that lands to master”.

Somehow, the issue we want to address has three sides:

 1. Tooling
 2. Expectations (as Submitter and as Reviewer)
 3. Incentives

Here this GCD is about #1.  Great!  However, from my point of view, this
cannot be disconnected from #2 and #3.

Do not take me wrong, I do not propose to delay this GCD or to enlarge
its scope.  Not at all because all must be very focused, otherwise
nothing is actionable.  What I suggest is to pave the way for the next
GCD :-) As Tobias anticipates [1] with some “HTTP redirect for the Git
repository”.

Or as you say below: a first clarification for the workflow that would
work for us.

> I gave the example of Nixpkgs, where package maintainers, who are not
> necessarily committers, can trigger merges for some changes that touch
> their packages and that pass a number of tests.

I agree.

> I don’t have yet a clear idea of what workflow would work for us but I
> think we can take inspiration from Nixpkgs and many other projects that
> rely on automation to do empower people beyond committers.

For the record (you probably know better than me), nixpkgs has more than
5k+ open PRs.

    https://github.com/NixOS/nixpkgs/pulls

Well, whatever they do seems far from perfect. ;-)

Cheers,
simon

1: Re: Discussion with Codeberg volunteers
Tobias Geerinckx-Rice <me@tobias.gr>
Fri, 07 Feb 2025 16:58:54 +0000
id:7C4D66EC-4C34-430D-B3E3-9DD486974435@tobias.gr
https://lists.gnu.org/archive/html/guix-devel/2025-02
7C4D66EC-4C34-430D-B3E3-9DD486974435@tobias.gr">https://yhetil.org/guix/7C4D66EC-4C34-430D-B3E3-9DD486974435@tobias.gr


PS: For sure, these 5k+ open PRs include automated PR as updates.  Yeah
    running after the very last version of
    python312Packages.microsoft-kiota-serialization-text (1.9.1->1.9.2,
    see #380877) is probably vitally important and burning many
    resources for that is something the future will thank us.

    Sorry for the sarcasm but I’m bored by all this “fast fashion“.  Do
    we include frugal in the tools we build?