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

From: Simon Tournier <[email-masked]>
Date: Mon, 17 Mar 2025 13:22:09 +0100

Hi Ludo,

On Fri, 14 Mar 2025 at 22:45, Ludovic Courtès <[email-masked]> wrote:

> If you brought up ideas or concerns, consider submitting a patch against
> the existing proposal; what would you change to the text?

My concrete proposals:

  1. Drop the section of « Issue Tracker Migration Path ».

     It appears to me orthogonal.  And to my knowledge, it’s not a
     current bottleneck.  Moreover, for what my opinion is worth on that
     topic: I disagree to force people to register on Codeberg in order
     to report a bug.

  2. It’s missing:

    a) How to deal with moderation?

    b) How to deal with the backup of the history?

       If tomorrow, the Debbugs instance suddenly disappears for some
       unexpected reasons, nothing about our development history will be
       lost: We have many copies of guix-patches around; even on
       Software Heritage [1]. ;-)

       We need a plan about Codeberg.

    c) A discussion allowing write-access for dedicated branches.

       If that’s not currently possible, we probably need to open a
       request upstream and for sure mention this feature request under
       section « Drawbacks and Open Issues ».

       The short paragraph under section « Rights and Privileges » is
       unclear, IMHO.

       Under section « Teams », what does the paragraph “All these teams
       would have read-only access to the repositories […]” mean?

  3. More milestones for the « Repository Migration Paths ».

     Let aside my personal opinion, so I will not repeat [2]. ;-)

     Somehow, we are putting all our eggs in the same basket without any
     guarantees about this very same basket. :-)

     For sure, the Migration will be at worst a neutral thing – same
     bottlenecks as today – and at best a good thing!

     That’s said, do we all – The Reviewers™ – have enough a minimal
     experience with PR workflows?  In order to smooth the migration for
     The Reviewers™.  Concretely and today!  Because if my count is
     correct: on the 23rd of May, PR will be active and nothing more.

     I propose to condition the migration with milestones:

    a) “The [QA frontpage] and its [Data Service] does not support
        Forgejo webhooks yet but can be extended to do so without too
        much effort, possibly sharing or reusing the Forgejo interface
        code from Cuirass.”

        Why not make it first, before all the migration?

    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?

    c) “We will arrange so that the build status of a pull request is
        clearly visible right from that pull request.”

        Why not make it first, before all the migration?

    d) “This will have to be addressed to fully take advantage of the
        new pull-request workflow.”

        Why not make it first, before all the migration?

    e) Open a discussion on Guix Foundation side about how to support,
       etc.

     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.

    Well, that’s a proposal.  It’s up to many refinements. :-) Somehow,
    it could help many of us without any minimal experience with the PR
    workflow and in the same time also help to improve our infra
    (CI/QA).

    What I dislike – not to say I disagree – with the current Migration
    Path is the “sudden” switch.  The community is taking care about not
    breaking existing tools or let the time to adjust.  However, we do
    not apply such principle for our own workflow: worry-hurry. :-)

Cheers,
simon

1: The first patch sent to guix-patches.
   https://archive.softwareheritage.org/swh:1:cnt:ce7a09543926f7e5717b7a3f8fa3c1f6d5fdb5f1

2: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <[email-masked]>
Mon, 10 Mar 2025 13:30:44 +0100
id:[email-masked]
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/[email-masked]
https://yhetil.org/guix/[email-masked]