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

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Tomas Volf <~@wolfsden.cz>
Cc: 76503 <at> debbugs.gnu.org
Subject: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Date: Sun, 02 Mar 2025 22:54:21 +0100

Hi Tomas,

Thanks for reading the proposal.  I pushed a fix for the typos you
reported.

Tomas Volf <~@wolfsden.cz> skribis:

>> Forgejo has several features to support collaboration among a large
>> number of people and on a large code base, including
>> [teams](https://docs.codeberg.org/collaborating/create-organization/#teams)
>> and [issue and pull request
>> templates](https://forgejo.org/docs/latest/user/issue-pull-request-templates/).
>
> How do pull request templates work together with AGit flow

Good question, I don’t know, we’ll need to check.

> that (as far as I understand it) is being considered to be mandatory?

That’s not how I see it; I think suggesting it is an option (but also
from because it provides an interface that some may prefer), but making
it mandatory now doesn’t seem justified to me.

>> To ease this migration and possibly future migration, we may add a new
>> `git.guix.gnu.org` DNS entry with HTTP redirects to
>> `git.savannah.gnu.org` (before migration) and `codeberg.org` (after
>> migration); a [patch](https://issues.guix.gnu.org/76296) implementing
>> this has been submitted.  The `%default-channel-url` variable would
>> refer to `https://git.guix.gnu.org/guix.git`.
>
> The https://git.guix.gnu.org/guix.git seems like a good idea regardless
> of whether this GCD is accepted or not.  It would allow us to switch the
> hosting on moments notice in case the underlying infrastructure goes
> down.

Yes, I think so too.

>>   - Within **30 days** after acceptance of this GCD, mailing list
>>     administrators will set up the `bug-guix` and `guix-patches` mailing
>>     lists in “Emergency Moderation” mode in the Mailman
>>     interface—meaning that messages will not get through anymore.
>
> This contradicts GCD 001 no?  The 001 requires the GCD to be sent as
> patch to guix-patches <at> gnu.org.  How will this be handled?

I think we would amend GCD 001 to change references to the email
workflow with references to the Codeberg-based workflow.  We should
probably spell it out here in an extra bullet, along these lines:

  - Once the guix-consensus-document.git repository has been moved to
    Codeberg, authorized people will apply [the
    patch](https://issues.guix.gnu.org/XXX) amending GCD 001 to refer to
    the Codeberg-based workflow.

And so we’d send the patch in question beforehand so everyone can see
how the GCD is amended.

WDYT?

> On separate note, there are other projects (well, I know just of
> Shepherd, are there others?) than Guix using bug-guix and guix-patches,
> so maybe this GCD should go a bit into how that will be handled.

Maybe with by extending the bullet above:

    […] meaning that messages will not get through anymore.
    Other projects that were using bug-guix and guix-patches (the
    Shepherd, Cuirass, etc.) must have set up their own bug-reporting
    and patch-tracking tools by then.

In practice I believe Shepherd is the only one not under the Guix
project at Savannah that will have to do something special[*]; the other
projects will be able to use the Codeberg tools.

[*] I’d like to migrate Shepherd to Codeberg as well soon, under its own
    organization.

>> Everything that can be done through Forgejo’s web interface can be done
>> *via* its [HTTP
>> interface](https://forgejo.org/docs/latest/user/api-usage/).
>
> This is not true.

I was thinking about this:

  https://codeberg.org/api/swagger#/

> There is no API for getting the Terms of Use.  Changes in those are
> announced only as a banner on the website (as far as I can tell).

Yes; I saw what you (re)wrote on this topic and I plan to reply
separately.

>> [fj.el](https://codeberg.org/martianh/fj.el/) is an Emacs interface
>> similar to `mastodon.el` that lets you view and comment on issues and
>> pull requests, list repositories, view notifications, and so on.
>
> One thing it does not support (based on the README) is the ability to do
> an actual code review, which is a bummer.

Concretely, it does not let you comment line-by-line so far, which is
what you would do in the web interface.

Of course you can still use ‘fj.el’ to send comments about changes
(that’s what I’ve been doing with those at
<https://codeberg.org/civodul/guix/pulls>), but for more complex code
reviews, one may have to resort to the web interface to pinpoint
specific issues in the code.

I agree that it’s a bummer, but I find that the overall benefit still
outweighs this annoyance (and it’s an annoyance for some of us but not
for everyone out there).

>> git push origin HEAD:refs/for/main  \
>>   -o topic="update-hello" \
>>   -o title="gnu: hello: Update to 42." \
>>   -o description='This updates the `hello` package."
>> ```
>
> Does this still require a Codeberg account?

Yes.

> Can anyone update other people's pull requests, the way I can
> currently sent n+1 version of a patch started by someone else?

If I’m not mistaken, the person who creates the pull request decides
whether they allow others to update it.  (As a reviewer and “owner”,
I’ve definitely updated other people’s pull requests.)

>> Note that since Guix requires signed commits by people listed in
>> `.guix-authorizations`, we will *not* be able to click the “Merge”
>> button nor to enable auto-merge on build success.
>
>>From the debate I gathered that the merge button can be completely
> disabled on the Website, I would suggest to put in here that we will do
> that (to prevent mistakes).

Yes, I added a sentence to that effect and pushed it; let me know if
anything more should be done in your view.

>> First, everyone will have to create an account and accept [Codeberg’s
>> Terms of
>> Use](https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md)
>> before they can contribute, which can be seen as a step back compared to
>> the email-based workflow.
>
> Something to note here is that "contribute" is used in very wide sense.
> It contains even just reporting a bug.  We will likely lose *some* bug
> reports because people will not be willing to jump through the hoops.

That is true, but the same can be said of the current workflow.

> Would it be possible to have a bot that would still allow at least to
> report bugs via email?

I imagine this is technically feasible, but the problem is that setting
up bidirectional communication (so developers can ask questions to
reporters) is probably out of reach; in that case it would lose its
interest.

In practice, if someone sends a bug to guix-devel, we won’t ignore it,
but I think it’s in the project’s interest to direct bug reports to one
channel.

Thanks for your thorough review and insightful comments!

Ludo’.

Previous Next

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