On 2025-03-04, Maxim Cournoyer wrote: > Ludovic Courtès <l...@gnu.org> writes: >> Within **30 days** following acceptance of this GCD, committers would >> migrate all these repositories to https://codeberg.org/guix. >> >> 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.git. A commit would reflect that by >> updating: > > 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.
Well, I am on year... 7 ... Seven! ... I had to count it out on my fingers ... of having been using both bugs.debian.org (Debbugs) and salsa.debian.org (Gitlab) concurrently. I have been merging merge-requests via the web interface, using regular old plain "git fetch && git merge && git push" (my favorite by far!), and applying patches via email... Admittedly Debian's Debbugs is not GNU's Debbugs, and Debian's Gitlab is not Codeberg's Forgejo, and Guix is not Debian, but... I suspect there is enough similarity for my experiences to be somewhat relevent to this conversation... My personal conclusion is that these very different models can coexist for... extended periods of time! Is it a bit fractured? Some people prefer one system over the other, so yeah, I guess... Is there duplication of issues? Yup. Sometimes one needs to get forwarded to the other manually. Whee. Do issues get automatically closed on both systems? Usually, if you remember to include the right incantations in your commit messages! Occasionally even if you forget, what magic is that?! Sometimes having an entirely different model is beneficial; just a couple days ago someone reported a bug in diffoscope on IRC, but was having difficulty getting an account set up on salsa.debian.org, but was able to send an email to bugs.debian.org ... so we did not loose track of the issue. Having both options has been more beneficial than harmful, at least in my eyes. Over these seven years I have encountered people who absolutely refuse to deal with email who had interesting contributions and happily submitted stuff via salsa.debian.org. Some people do not have time or interest in getting another account on yet another platform configured and are happy to send a patch via email. I have been accomodating both sorts of people, and all sorts of folks in between (such as myself!), and it is fairly easy because the common denominator is git! So yes, maintaining multiple systems has some serious drawbacks, and I have not actually had to maintain any of the Debian infrastructure really, but transitions are always hard, and some resistance to change is an absolutely reasonable strategy, especially amoung volunteers with limited time. Nearly every time I need to explore some new technology, I grump and squint and maybe even work up a good scowl. I have skipped multiple generations of the shinest new things, only to spend my time on the one that actually stuck around a while. So I understand that reluctance. I have also found new ways of thinking about problems when I explore some new approaches, so I understand that enthusiasm. I do feel, given what I have heard from several people in this discussion, that proposing a flag day with a short time of overlap is going to be very hard for this community, and possibly more divisive than whatever fracturing we might encounter by maintaining two concurrent technical systems over an extended time period... Yet that is at odds with what sounds like people burning out on maintaining parts of the old system as well... mainly from what I have heard, mumi, as the glue making debbugs at all usable? Or is it more than that? Whew! Thanks for making it this far! If you still are craving more, there are a few postscripts below that did not quite fit in anywhere, but I just could not resist... live well, vagrant P.S. I also had used alioth.debian.org ~2004-2018(?), which just so happens to be based off of the same code base that savannah.gnu.org was (which was based off of a version of sourceforge.net I had used ~2000-2002)... also concurrently with using Debbugs. So forgive me if I sway under a mild bit of deja-vu. P.P.S. I do think a huge difference between Debian's Debbugs and the way Guix uses GNU's Debbugs is that Guix has precisely two buckets (that I am aware of) ... "guix" for bug reports and "guix-patches" for patches. In contrast, Debian has approximately one bucket for each upstream source. The difference of granularity can be somewhat met with various forms of tagging, searching, etc. but it is also more cumbersome and requires some additional development (e.g. mumi) to abstract that stuff out. P.P.P.S. Guix has subjected itself to complicated policy choices that are not limitations of Debbugs, per se, like sending one patch per email for a patch series, which increase the complication for some submitters and reviewers alike (perhaps limitations of email size limits have required this, though).
signature.asc
Description: PGP signature
