Hello Guix devs, I concur with Ekaitz’s observation:
> We would be pushing that complexity only to committers, not to > ocasional contributors, which may help attracting people. But, on the > other hand, we would force people who is already very busy (and very > efficient with their current workflow) to discard their way to do > things and learn another. Almost all large-scale FOSS projects have fouond this time and time again, even something like Linux kernel, that occasional contributors are large in number but are not reliably persistent in continuing their contributions. Of course we should make it easier for more and more people to contribute and work with us, but we should be wary of what that might cost the existing state of contributions, the bulk of which are done by regular committers over more than a decade, and how that might be affected. Similarly, I also agree with Maxime’s concern: > The complexity of the flow can be partly explained by the fact that there > isn't only one flow possible, but a multitude of flows (Emacs Debbugs, > Mumi, git send-email, etc.), which is more of a strength than a defect > when it comes to the freedom of choice/flexibility for our contributors. > > I see the argument that there's an HTTP API for Forgejo; that's great, > but it requires that everyone relearn another way of doing something > that already works well enough for me and others, which I'm not too > excited about. I also assume the Forgejo-related tooling, given their > young age, would not be as mature and missing features in places, and > that it would require invested time to comfortably do all that can be > done today in Gnus and Emacs Debbugs, away from the web interface, in > the environment of choice (Emacs) of perhaps a majority of the Guix > contributors. We might be prone to underestimate not only the effort that we’ve already put into in continuing what exists, but also a bit too haste in judging it as dysfunctional. As has been said elsewhere by Suhail and others, the Codeberg migration is no panacea. That said, we of course need to admit that our existing workflow has a lot of cruft and problems. But as I’ve said before, both with regards to the Codeberg migration and the GNU affiliation, a more reflective and integrative approach is better than something that leaves a lot of things hanging. Maxime is accurate in being wary of a quick migration: > I'd like to suggest extending the 'trial' period to something much > longer, like a year or so, to make sure our parachute is properly > installed before jumping the cliff :-). Letting both systems co-exist > and compete for merit seems a good trial, and we could also extract > useful data (such as how many contributions were merged on one or the > other, etc.). It'd be a bit annoying to keep an eye at two places for > some time, but at least we wouldn't commit to something that may not > scale/match our peculiar requirements as well as we expected. > > After such trial we could then vote on whether we want to fully migrate > to Codeberg, when all regular contributors would have gotten a chance to > try the new tools and find a flow that works for them, hopefully. With > this insurance in place, I'd be happy to experiment with Codeberg and > see whether it truly improves things. We have a *humongous* backlog of patches, and the committers are probably more aware of this than me, of course, but I couldn’t find satisfactory proposals to resolve that in the GCD. Even if we were to move to Codeberg within the next week, what we already have will take at least a year, assuming a good chunk of the committers put a lot of work in reviewing the backlog *while* also handling the new PRs that are being issued from Codeberg. And since our whole point was to make it "easier" for new contributors, there’s a good probability that indeed initially there’ll be a surge of people trying to contribute PRs. That is *good*, but are we ready to handle it alongside the older patches? Here is a proposal which might be considered in keeping an integrative system: Assuming we *should* move to Codeberg, we recognize the fact that such a move primarily solves one problem *fully* without any reservations: letting a larger scale population of Guix users to have an easier pathway towards contribution. While some of us, including me, can consider it a misfortune that this is indeed the way people are conditioned, it’s beyond our scope to solve it. That said, we also have a smaller set of people, i.e. committers, who are proficient in a workflow that has several perks to it, and arguably better than the previous one, but it is not common among newcomers. To achieve our goal of helping newcomers, we keep a regularly updated mirror of Guix on Codeberg with issues and PR features enabled. Whoever wishes to contribute, can create an issue, or fork and make a pull-request directly on Codeberg with their desired workflow (which arguably is largely the web approach). Here we have a committer or two to handle the Codeberg repository, label issues, and organize things, but *not* for reviewing patches. Instead, we host a backend service that regularly checks the Codeberg repository for any new issues or PRs and then communicates to us through the Codeberg’s Forgejo API [0] the content of said issues and PRs. The data received from the API then gets directed to our Debbugs or Mumi backend, which parses the information from it and opens a new Debbugs issue for it. Thus, for every issue opened on Codeberg, we have a mirrored Debbugs issue, and same for PRs where the diff can be then parsed into a valid patch. To be noted that such mirroring is strictly one-directional initially, every issue opened previously or opened later shouldn’t get mirrored into the Codeberg repository. If we assume that only committers are the people fluent and wanting of email-based workflow, the new Debbugs issue would only be created by them, while we encourage newcomers to always report through Codeberg’s issue tracker. Since Codeberg already allows to communicate in issues over email, i.e. you can respond to someone in a particular issue over email, this shouldn’t be too difficult to arrange. Newcomer opens issue #xxyz -> Debbugs/Mumi mirror it and create x...@debbugs.gnu.org -> Interested committer responds to it over his desired email workflow -> It reaches the newcomer without him having to open email. I argue the same workflow can be replicated for pull-requests as well, without the need for any "merge button". We remind ourselves that the need for a PR/GitHub/Web workflow is to cater newcomers, who have nothing to do with merge issues but everything to do with forking and contributing changes. Ergo, the only part of the PR workflow we need is it’s creation, not the entire package of fork->pull->merge->commit. The latter two are to be under the responsibility of committers, who will not have to change any part of their workflow. As described above, they’ll get the PRs rendered to them as good ol’ git patches, over mail and they can apply them, work on merge issues and get back to the newcomer contributor over email. The only additional part in the case of PRs would be the need to replicate the patches also across guix-patches mailing list. I know this requires some setting up, but we need such time and effort in any case if we decide to migrate and not fall into the issues Ekaitz and Maxime pointed out. With the help of Codeberg people for their API, and the knowledgeable people on Debbugs such as Felix, Arun, Ricardo et.al, this might be a feasible task. I am also willing to contribute in whatever way and means possible, since I’m slowly working myself towards contributing more and more to Guix. And even though I’m not a committer, I retain the email-based workflow through Gnus and debbugs.el. So, it will help me as well. Let me know what you think. [0]: https://codeberg.org/api/swagger Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software. PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
