Hi Simon! Simon Tournier <zimon.touto...@gmail.com> skribis:
> 1. Drop the section of « Issue Tracker Migration Path ». To be clear, are you suggesting to not use Codeberg for bug reports at all? To me using Codeberg’s bug tracker is an integral part of the proposal (it’s in the title). We could change it to “Migrating repositories and patches to Codeberg”; that has less appeal to me, because I’m confident that (1) this would lead to confusion, and (2) we’d miss out on cross-referencing and other niceties. I too hate having to create an account, but let’s face it: we’re used to it these days, and Codeberg allows you to sign in with a gitlab.com or github.com account (I don’t support any of these, but it’s a fact that many people have an account there already.) “Necessary evil” for me. As I wrote elsewhere, we’ll also gladly take bug reports on guix-devel in practice (we already get bug reports occasionally on mailing lists, IRC, etc.), so nobody would be “forced” to sign in on Codeberg. > a) How to deal with moderation? Conversations (PRs, issues) can be locked by the “owners” of the project on Codeberg; it’s also possible to block individual users. Is that the kind of moderation you have in mind? > b) How to deal with the backup of the history? I would rely on backups done by Codeberg e.V. after checking with them what’s in place. We could also set up our own thing; I’ll inquire to see if there are tools to do that for regular users. (Keep in mind though that nobody stepped up to help out with backups of our existing infrastructure, though.) > 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? > The short paragraph under section « Rights and Privileges » is > unclear, IMHO. The goal is to explain how to transfer rights from Savannah to Codeberg. I’m happy to rewrite it if you can tell me more. > Under section « Teams », what does the paragraph “All these teams > would have read-only access to the repositories […]” mean? I’ll drop it; it remains from the pre-GCD draft I sent and is beyond the scope of this document. > 3. More milestones for the « Repository Migration Paths ». On experience: collectively, we have experience with Codeberg and with other forges; many of us frequently interact with this kind of forge. So, while switching to Codeberg is a big change, I think we should also not downplay the ability of contributors to adapt to something many/most of them already know. > 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? I did not make that a blocker because then someone would have to commit to doing the work. My contribution here is to make sure that what is done for Cuirass can easily be reused elsewhere; that’s largely the case¹ and I’m also happy to give a hand with integration efforts. ¹ https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/src/cuirass/forges/forgejo.scm > 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? How would we do that? (The Guix project is not an admin of bugs.gnu.org.) > 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? We (Romain and myself) have been working on that and eating our own dogfood by using it for the Guix-Science channels: <https://hpc.guix.info/blog/2025/01/join-the-guix-science-community/>. Yet, I think that requiring it to be production-ready on Day 1 would be too much to ask. Also, because we don’t have anything close to this feature right now, I think it would be “unfair” to make it a prerequisite. > e) Open a discussion on Guix Foundation side about how to support, > etc. On how to support Codeberg e.V.? I can email guix-europe to test the waters. > 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. Thanks for your feedback! Ludo’.
