Hello Ricardo,
>> We have a *humongous* backlog of patches, [...] > >> [...] 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 [...] > > So at the end we'd have an even larger backlog of patches, and spread > across two systems...? [...] We would have that regardless of whether one follows my proposition or not. The old backlog is going nowhere. Even if we make a full-switch to Codeberg immediately, the committers would either have to work on both things tenaciously as they (committers such as Maxime) get used to an entirely new workflow. What is the probability that such an immediate increase in responsibilities will not lead to a further increase of existing backlog? I don’t think anything can solve the backlog quickly, what I proposed was with the intent of solving the issue of committers not having to learn a new workflow altogether to work on the backlog, ergo, not having another hurdle to it amidst a list of others. > And where do we source the time and motivation > to hack on yet another piece of software? Outside contributions to > mumi have been *very* few in all these years; that's not for a lack of > problems we've had with the system, and for once it's not for a lack > of > review either. Indeed, that is a problem. It was a mere proposition, so if enough people want it to happen, we can have it :) > As a long time contributor with commit access I have the impression > that > people new to Guix hold the assumption that the current system and > workflow works for long time contributors. I may just be wildly > incompetent, but for me it most assuredly does not work in enabling > reviews. I mostly review patches that were sent to me directly or > that > happen to solve a problem I'm trying to solve as part of my > maintainance > work. I acknowledge your experience, but we heard from others such as Maxime how to them it might require learning and changing the workflow. So the people for whom the email-based workflow works isn’t really a null set. > The haphazard GNU fork of Debbugs also lacks a number of features, has > odd unaddressed bugs, lacks people who even understand in what ways it > differs from the Debian version, lacks people working on improving it > and addressing these issues. (There is literally *one* person who > keeps > the lights on.) > > It does not even do simple things like delivering notifications to > *everyone* who participates in an issue discussion. This is the > reason > for the sudden eery silence that can be seen in many issues. > > I honestly have my doubts that the move to Codeberg would > automatically > solve all of my workflow issues, but let's please not eulogize the > email-based workflow too much. It makes sense to me to base our > efforts > on a system that is *actively* developed by a *team* of aligned free > software hackers. > > I don't see an active future for the GNU fork of Debbugs, and I think > it > is not a good use of our time to work on a system that won't improve > unless we burden ourselves with even more work (like taking over > hosting > and administration). I'd rather work on Guix. By all means, but I think you are confusing a plea for not breaking certain people’s workflow as a means to "eulogize" something. The goal here is to simply not put enough pressure on people who already have a lot on themselves to change their workflow in order to continue contributing to Guix. And my proposal is targetted towards an eventual move to Codeberg, just a more gradual approach, based on empirical feedback and with some time to clear the existing backlog and to learn the new system. Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software. PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
