Ludovic Courtès <l...@gnu.org> writes:
[...] > Anyway, the proposal is about migrating repositories, issues, and > patches to Codeberg. You’ll find the rationale, plan, and open issues > in the attached draft. I already found two “sponsors” for the proposal > (meaning they agree with the general direction and are willing to > participate in discussions) but if anyone else would like to sponsor it, > I’m happy to add them. Right off the bat, I want to say that I think this would be a good move in the long run. While I've come to enjoy the efficient tooling I've painstakingly assembled to deal with the mailing lists, an email-based workflow is simply not accessible enough for the majority of users today, for a number of reasons. (I won't go into details right now; I'll wait for the discussion to develop a bit.) [...] > - the project added a commit hook to create add unique `Change-Id` > headers in commit messages in an attempt to correlate commits in the > repository with messages send to `guix-patches`; none of the > existing tools takes advantage of it though, and it is up to > contributors to manually close entries in the bug/patch tracker once > they have been fixed/applied. I do hope we keep the Change-Id hook, as one of my upcoming contributions will make use of it ;) [...] > For Guix itself, we would decide on a **flag day** 14 days after > acceptance of this GCD at the earliest, and 30 days at the latest. > On that day, the official URL of the Guix repository would become > https://codeberg.org/guix/guix. A commit would reflect that by > updating: > > 1. the `url` field in `.guix-channel`; > 2. the `%default-channel-url` variable in `(guix channels)`; > 3. any other reference to the URL that may appear in the repository. There'd probably be a lot of references in the manual that would need to be updated as well. Just something to remember. [...] > ## Issue Tracker Migration Path > > Importing all the issues and patches from Debbugs/mumi into Codeberg > would be impractical: it would require the development of specific > tools, would be a lossy process due to the fundamental mismatch between > plain text email threads and Forgejo issues and pull requests, and would > bring little in return. > > Our proposal is the following: > > - https://issues.guix.gnu.org will remain up and running for at least > **two years** following acceptance of this GCD. Note that once > issues.guix.gnu.org is down, issues will remain visible at > https://bugs.gnu.org and email archives will remain visible at > https://mail.gnu.org. > - 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. It > will still be possible to interact on individual issues via > `n...@debbugs.gnu.org`. > - The switchover will be advertised before it takes place with a post > to `info-g...@gnu.org`, to `guix-devel@gnu.org`, as well as through > a blog post. > - The “Contributing” section of the manual will be updated accordingly > at that time. I strongly feel that the Guix project itself needs to maintain a permanent (read-only) archive of all its mailing lists, and ensure that it is searchable and downloadable. This may not seem related to the main topic of the GCD, but it very much is. Hear me out here. On one hand, the lists are an invaluable source of information. Without the ability to search them (locally, via Notmuch), I don't think I would have gotten as far as I have with Guix. There's over a decade of discussions and bugfixes and workarounds that aren't documented anywhere else, and moreover the project's history itself is contained in those lists. Having them permanently accessible, in an easily searchable manner, is of paramount importance. On the other hand, such access is NOT provided by lists.gnu.org (is this what you meant by mail.gnu.org?) and bug.gnu.org. You've acknowledged in your GCD that Debbugs' user interface is substandard. lists.gnu.org is infinitely worse. Here are just a few assorted gripes: - It only shows one message at a time, so you have to actually find and click a 'next in thread' button, repeatedly, to read an entire thread, as though the concept of scrolling had never been invented; - The 'thread index' view does not show more than 4 levels of nesting, meaning that the thread structure is completely lost in sufficiently deep threads, thereby casually discarding the primary UI advantage of email discussions; - There is a separate thread index for each month, so that the page for this thread [1] will only link to replies until the end of this month, and people not used to this bizarre design will think the discussion just died out abruptly and not see anything in future replies; - Primitive search options, including the advanced search, which I have never used successfully even once; ...and countless other complaints. Right now, probably the only reason people learn to live with this nonsense is that it's really the only meaningful place to look (apart from IRC archives, don't get me started...). If we move to Codeberg, that repository's issue tracker will become the place for usage-related discussions, and the place where most people look for information. With the list archive interface being as primitive as it is, the majority of new users will never utilize it effectively. Over a decade's worth of precious information will functionally cease to exist for a large section of the community, with the rest of us busy fielding the same questions that have been answered a million times before. Luckily, there's a decent solution to this problem - public-inbox. No sales pitch I could give will surpass the evidence of your own eyes; just compare this thread on lists.gnu.org [1] to the same thread on an unofficial public-inbox mirror of guix-devel: [2] https://yhetil.org/guix-devel/871pwnc8jt....@inria.fr/t/#u The advanced search works great as well, and it's possible to produce a maildir from a clone of a mailing list [3]. What I'm proposing is that once we archive the lists, we create a public-inbox archive of them, and just host that permanently. That way, the archives become actually usable without the need to download them in their entirety and index them with Notmuch/Mu. I'm actually fine with sunsetting issues.guix.gnu.org; while it was a significant improvement over the list archives, it still needed a lot more love. Moreover, it was fundamentally trying to turn threaded email discussions into flat lists of messages, with mixed results. > Care will be taken to advertise the various interfaces to > Codeberg/Forgejo that exist in addition to its web interface, such as > [forgejo-cli](https://codeberg.org/Cyborus/forgejo-cli/) and > [fj.el](https://codeberg.org/martianh/fj.el/). For fellow Emacs users, I'd also like to mention that magit-forge [4] recently added rudimentary Forjego support: [5] https://github.com/magit/forge/commit/0c81b44fb21e95719035a38e81ff088e808318dc This is likely the best possibility for Emacs integration, since it's integrated with Magit. [...] > 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. This is a security > feature that we want but it limits scalability as actual merges lays on > the shoulders of committers. To reduce the load on committers, we could > use a scheme as follows: > > - contributors create pull requests against a `staging` branch (TODO: > check PR templates to force `staging` by default); > - the `staging` branch is *not* signed and team members can somehow > enact (TODO: figure how) merging into that branch; > - committers periodically rebase and marge that branch into `master` > after a cursory look, with the understanding that it has been > reviewed and merged by authorized people. > > That way, pushes to `master` will be limited to changes that have > already been validated and built. > > XXX: Does it really belong in this document? Should we just keep that > for later? > > - Committers can write to `master` (branch protection rule) > - Python members can write to `python-team` and `staging` I do think it's important to discuss this here. Even seemingly minute details of workflow changes could have more of an impact than one would expect. In my case, I'm interested in how this would affect `guix git authenticate`, as I'm currently in the process of writing a `guix fork` subcommand to support authenticated forks. With the 'staging branch' workflow described here, I don't think we'd actually need any changes to the authentication mechanism or interface. In particular, the 'staging' branch could still be signed; we could just authorize team members as well as committers in that branch via .guix-authorizations. It could even be merged in directly - a committer could add an empty 'sign-off' commit signed with their key, then merge that into master. Or we could just do the rebase-and-fast-forward-merge as suggested in the GCD. In fact that would make more sense; just wanted to give an idea of the possibilities here. [...] There's one more potential consequence of this GCD that I want to bring up - namely, the eventual stagnation of the discussion mailing lists (guix-devel and help-guix). As I discussed above, people will be even more reluctant to communicate via email once bug-guix and guix-patches are replaced by Codeberg's issue tracker and pull requests. We will end up in a situation where the official place for discussion (guix-devel / help-guix) will be frequented less and less often. This has been observed before, for example with the Python community: [6] https://lwn.net/Articles/901744/ There are many possible consequences of this. One is that GCDs like this one would be seen by fewer people, so there would be less useful discussion and feedback. And in general, people outside of a small circle of old contributors already subscribed to the lists will not participate in, or even be aware of, core community discussions. I'm not bringing this up because I want to preserve the mailing lists at all costs; rather, I'm suggesting that we switch away from them as well. For some of us, this will be just as painful as a switch to a web-based forge, if not more; but we need to think of the project's future. As for concrete alternatives, I'd suggest Discourse; though it's also web-based, it does have a fully-featured API [7], so if enough of us care about plain-text clients, that can happen :) Also worth noting - support for threads, apparently [8]. [1] https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00218.html [2] https://yhetil.org/guix-devel/871pwnc8jt....@inria.fr/t/#u [3] https://github.com/wkz/notmuch-lore [4] https://packages.guix.gnu.org/packages/emacs-forge/ [5] https://github.com/magit/forge/commit/0c81b44fb21e95719035a38e81ff088e808318dc [6] https://lwn.net/Articles/901744/ [7] https://docs.discourse.org/ [8] https://meta.discourse.org/t/introducing-chat-threads/270613
