GNU bug report logs - #76503
[GCD] Migrating repositories, issues, and patches to Codeberg

Previous Next

Full log

View this message in rfc822 format

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>, 76503 <at> debbugs.gnu.org
Cc: Guix Devel <guix-devel <at> gnu.org>
Subject: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Date: Thu, 17 Apr 2025 18:48:24 +0200

Hi Ludo,

Minor comments. :-)

> As a reviewer, it is possible to pull references of pending pull
> requests by adding something like this to `.git/config`:
>
> ```
> [remote "pulls"]
>        url = git <at> codeberg.org:org/guix-science/guix-science.git
>        fetch = +refs/pull/*/head:refs/remotes/pulls/pr/*
> ```
>
> Running `git fetch pulls` then retrieves references to branches
> corresponding to all the pull requests.

I think it is misleading.  Because this does not really « pull
references of pending PRs » but retrieve « all the PRs ».  Therefore,
then one needs to manually find their way.

Well, although I’m sure Git scripts are around, it appears to me a good
opportunity to show how the API is easy to exploit.  For instance, I
propose this:

--8<---------------cut here---------------start------------->8---
```
[alias]
        prs-fetch="!f() { for pr in                                                              \
        $(curl -s 'https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=open' \
           | sed 's/,/\n/g' | grep number | cut -f2 -d':' | sed 's/,//g');                       \
        do git fetch -u origin pull/$pr/head:pull/$pr/head ;done                                 \
        }; echo Fetch open PRs; f"

        prs-clean="!f() { for pr in                                                                \
        $(curl -s 'https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=closed' \
           | sed 's/,/\n/g' | grep number | cut -f2 -d':' | sed 's/,//g');                         \
        do git show-ref pull/$pr/head &&                                                           \
           git update-ref -d refs/heads/pull/$pr/head && git update-ref -d refs/pullreqs/$pr ;done \
        }; echo Clean closed PRs; f"

        prs="!git prs-fetch && git prs-clean"
```
--8<---------------cut here---------------end--------------->8---

Using this tip, as a reviewer, you synchronize the pending PRs.  The
idea, similarly as the initial tip, is to have something minimal and
pave the way; and not come with some full-featured solution.

Or this appears to you too “complicated”, I would not provide any
’.git/config’ tips and just write in plain text the tips:

        As a reviewer, it is possible to pull references of pending pull
        requests by exploiting Forgejo API.  For instance, querying the
        list of [open pull
        requests](https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=open)
        allows to get still pending pull request numbers and then fetch
        them using `git fetch -u origin pull/123/head:pull/123/head`,
        where `123` reads the pull request number.

Last, it appears to me a good idea to also provide the tip for removing
closed pull requests; because it’s not straightforward – at least, it
was not obvious for me before I did my homework. :-)


> The self-hosting option has its appeal for a project with the size and
> values of Guix—it is not uncommon for similar projects to do that, an
> example being the [Lix project](https://git.lix.systems/); there even
> exists a [preliminary Forgejo service for
> Guix](https://git.boiledscript.com/hako/Rosenthal/src/commit/7a6a28e872b3168f9b6513ccf797e247cd8a366d/rosenthal/services/web.scm#L32).
> However the author thinks that, as it stands, Guix system administrators
> have more than enough on their plate and are perhaps not up to the task
> of providing the availability guarantees we expect from such a service.

I understand the intent of the last sentence.  Well, I would not close
the door this way.  And I would remove the mention of “author” – it’s a
Consensus Document after all. :-) Nitpicking for the very last part.

        However, considering the current load of Guix system administrators for
        many other tasks and considering the constraints (availability) we
        expect from such a service, self-hosting appears an unreasonable
        workload at first.  Self-hosting might be considered later once the
        switch is well-established and all the mail-based workflow is curated.

Or something along these lines.


For the rest, I would word differently the Motivation section but I do
not have enough time neither energy; especially when I can live with the
current state. :-)

I’m happy that many points had been resolved or discussed.

To complement a chat we had IRL some weeks ago, let me point you the
public message [1] containing my 4 requirements and my potential query
for write-access suspension while I will not have a setup that fulfills
them.

Last but not least, I support the outcome of this GCD. I know it’s not
yet the Deliberation Period and this will not be taken into account.
But I will be offline for some weeks and it appears to me worth to
express my plain support.

Cheers,
simon

1: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <zimon.toutoune <at> gmail.com>
Mon, 10 Mar 2025 13:30:44 +0100
id:87frjl6paj.fsf <at> gmail.com
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/87frjl6paj.fsf <at> gmail.com
https://yhetil.org/guix/87frjl6paj.fsf <at> gmail.com

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.