Subject: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

From: Vagrant Cascadian <[email-masked]>
Date: Mon, 10 Mar 2025 20:31:28 -0700

On 2025-03-04, Maxim Cournoyer wrote:
> Ludovic Courtès <[email-masked]> 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).