[GCD] Migrating repositories, issues, and patches to Codeberg

Hello Guix!

This is the formal submission of “Migrating repositories, issues, and

patches to Codeberg” (GCD 002), a preliminary draft of which I posted

before the Guix Days⁰.

In accordance with the GCD Process, discussion will end on April 23rd at

the latest.

I would like to remind everyone that you can try out Codeberg either by

contributing to one of the Guix-Science repositories¹, or by reviewing

or making a pull request for a trivial packaging change (and nothing

more!) in my Guix clone at Codeberg:

https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00313.html

Please do try it especially if you feel reluctant or wonder what the

workflow would be like.

Ludo’.

⁰ https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00218.html

¹ https://codeberg.org/guix-science

Hi Ludo’,

I think this is an excellent proposal. I've contributed over the years to Guix by sending email patches to debbugs, but I usually forgot each time exactly the best practices and usually someone (often you) has had to amend them slightly before merging. (And then I've got stuck contributing things like the `python-ical2orgpy', which required writing definitions for its python package dependencies, and figuring out how to properly send the patch series.) And finding things in email is often more cognitively difficult to keep all the pieces and steps involved in doing it properly. Since I've used to forge-based workflows from contributing to other projects, I think this would significantly reduce barriers for managing to actually getting round to contribute upstream. (I've got my own channel I use for things and a whole Org TODO list of things I want to submit upstream.)

I would also think a forge could make review and merge workflows smoother.

I'm very excited about this possibility. Thanks again for this proposal!

best,

 —Benjamin

--

 '(Dr Benjamin Slade (he/him)

     (website . https://lambda-y.net)

     `(pgp_fp: ,(B20E 444C FA80 B5F8 15FA 4AD8 6FBF CD68 3B05 2B84))

       "sent by [mu4e] 1.12.8 in [Emacs] 30.0.93 with [org-msg] on [GNU Guix] ([Linux])")

[mu4e] https://www.djcbsoftware.nl/code/mu/mu4e.html

[Emacs] https://www.gnu.org/software/emacs/

[org-msg] https://github.com/jeremy-compostella/org-msg

[GNU Guix] https://guix.gnu.org/

[Linux] https://opensource.com/resources/linux

Hello,

I am also in favour of this proposal. The email-based workflow was not

easy for me.

It requires significant configuration with Emacs or Vim, so that

convinience is unavailable folks who use text editors like VSCode,

Helix, Kakoune or Micro.

Forge-based workflow removes that cognitive load, and the focus stays

on the project itself.

I am fairly positive that if this proposal is accepted by a majority of

this community, it would improve the contributor's experience.

Regards,

Ashvith

Hi,

First off, full disclosure: Along with Ricardo, I wrote most of mumi and

the underlying guile libraries. So, I am simultaneously saddened and

relieved that we are deprecating mumi and moving to Codeberg—saddened

because mumi was many years of work, and relieved because I do not have

to bear any responsibility for the future! So, very mixed feelings. :-)

And, while I strongly prefer the email workflow, I concede that moving

to a pull request workflow will lower the barrier to entry simply

because it is more familiar thanks to GitHub's dominant mindshare. So,

unless there is significant support for mumi and the email workflow, I

will stand aside and go with the flow of the community. That said, my

arguments against Codeberg follow.

GitHub invented the fork+pull-request workflow. Despite git's

under-the-hood hardlinking magic, the pull request workflow is very

expensive in terms of disk space. Every fork takes up disk space, and we

need one fork per contributor. That's an enormous amount of disk space.

Now, I would think git's object storage model makes it easy to

deduplicate storage. But apparently, it's not that simple. GitHub does

complex software engineering behind the scenes to make it all seem easy.

See [1] for details. Cash-strapped and labour-starved community projects

like Codeberg/Forgejo don't (yet?) have the means to replicate such

cloud-scale software engineering. In fact, I am not speculating here;

Codeberg openly mentions this in [2]. Codeberg is already strapped for

storage and is introducing storage quotas[3] to make up for it.

The storage issue is particularly pertinent considering how big of a

project we are and how big our git repo is. At this moment, our git repo

is close to 1 GiB in size. Incidentally, that's already bigger than the

750 MiB Codeberg storage quota. Codeberg is willing to allocate more

storage on a per-project basis, but you have to request for it. Now, we

have a little more than 1K contributors. That means, we are already up

to 1 TiB in storage. That's enormous, especially considering that all

data on Codeberg combined adds up to only 12 TiB[3]. And, for

comparison, all our substitutes stored up from the founding of Guix only

add up to about 25 TiB[4]. Now, imagine we had a 10-fold increase in

contributors—a prospect that's pretty easy considering drive-by

contributors—we would be up to 10 TiB in storage for our git repo.

That's ginormous! We would be putting a lot of stress on a tiny

community organization.

Then, there's the bandwidth issue as well. Our git repo is not merely a

development repo. Every Guix user clones[5] it and pulls from it

regularly. As the Guix userbase grows, this will be an increasingly

heavy toll on Codeberg's bandwidth. [2] already alludes to occasional

slowness when the load is high. Even if we move to Codeberg, we should

maintain a mirror of the git repo on our own machines that is actually

capable of serving a large userbase.

I was present with Ludo and others when we visited the Codeberg stall at

FOSDEM, and enquired about the possibility of hosting Guix on Codeberg.

The person at the stall was hesitant about our large repo, and our many

users. In fact, in order to save on disk space, they suggested that we

encourage our contributors to delete their forks once done. :-D Needless

to say, that's never going to happen!

As well-intentioned as Codeberg is, a single non-profit hoping to host

all the git repos in the world in perpetuity and free of charge is a

very tough proposition. Technical solutions like federation that may

mitigate this are unlikely to materialize, especially in the short term.

More likely, Codeberg may go the way of Matrix, where federation is

possible in theory, but matrix.org is the only server in practice.

It would be nice if we were just a normal software project that could

fit well into a traditional forge. But, we are not. We are a

"distribution", and "distributing" is part of our core competency.

Critical parts of our distribution infrastructure should be directly

under our own control. We are a large enough and specialized enough

organization that this is necessary.

[1]: https://github.blog/open-source/git/counting-objects/

[2]: https://blog.codeberg.org/the-hardest-scaling-issue.html

[3]:

[4]: number from Chris Baines

[5]: Quick digression: Users must actually download about 1 GiB of data

on their first guix pull. That's frustrating to new users, and

effectively excludes users from parts of the world where a good Internet

connection cannot be taken for granted.

Cheers,

Arun

Hi Arun,

With the AGit workflow we can open pull requests without a prior fork.

I've done this before on the Guix Science channel:

https://codeberg.org/guix-science/guix-science/pulls/71

There is a little "AGit" tag linking to

The downside of using the AGit workflow is that it requires using an

unwieldy command, but personally I find it less cumbersome than the

common pull request workflow with an extra fork, clone of the fork (or

registering of an "upstream" remote), push to the fork, then pull

request from fork to upstream.

Your points about storage limits are important, though. We may have to

disable on-platform forks to nudge contributors to the AGit workflow.

--

Ricardo

Agit workflow is something to consider. Still, I wonder how Github

educated people, reluctant to email exchange, will react to a

git push origin HEAD:refs/for/<target-branch>/<session>

based workflow, and if this really lowers the barrier to entry[1].

Would it be a valid option to keep N mirrors, all in sync, aside from

the main repo ? Upon pulling, you randomly hit one of them. Is there a

reason to avoid this approach (even now) ?

Fully agree.

C.

[1] https://git-repo.info/en/2020/03/agit-flow-and-git-repo/

The linked page refers to a tool called “git-repo”, which smooths out the more technical bits to commands like “git pr”. From appearances it seems like using this tool is lower-investment for users than configuring (or changing!) their email client to interact with mailing lists and the mail-in patch workflow properly. It also helps that this (optional?) special tool is more “orthogonal” to other workflows, rather than involving something as central as emails.

On Tue, Feb 25, 2025 at 02:03:02PM +0000, Arun Isaac wrote:

I think we have similar feelings here. I'll miss living inside of Mutt

but I think we are losing a lot by not using a web-based platform.

I disagree that 1 TiB, or even 10 TiB, is enormous. It's certainly

large, but it's "entry-level" for a web service with 1000 users in 2025.

And a 10 TiB hard drive only costs ~$200. I know that's is a lot for

some people and places, but it's nothing for something like this. The

blog post you linked to even says "But storage is cheap!" And it really

is the cheapest thing in computing these days.

If Codeberg is really only hosting 12 TiB, then I suggest that either 1)

they can't handle Guix or 2) they are ready to scale up. And Guix should

think about helping them with scaling capital if necessary.

Interesting, that's not the impression I got from other emails from

people who were there. We need to clear this up with Codeberg now if we

want to make this change. It sounds like we would be their first

medium-sized user (I don't consider Guix to be large). Like I said, we

should be ready to offer help with fundraising.

Well, we already are in that position: we depend on the FSF completely

for our Git hosting.

I think it would be great if we could do this, but I haven't seen any

evidence that we can. In my years with Guix, we have always struggled to

operate our infrastructure. Also, I'll point out that it is an opinion,

not a fact, that we "should" do this. Very few free software projects

host their own Git servers. But like I said, the prospect does appeal to

me. But I don't volunteer to do it :)

Like I've said several times in this discussion so far, we should look

into the state of the art of shallow cloning. It might be efficient

enough on the server-side these days to be the smart move. I agree that

downloading 1 GB in this context is bad.

Hi Leo,

Aha, I'm not sure you read that article[1] carefully! :-) The very next

sentence immediately after "But storage is cheap!" is "It is not",

followed by "All data on Codeberg probably fits into a 12 TB drive".

That paragraph actually goes on to explain why storage is *not* cheap

and why it's more complicated than just buying a few more disks.

[1]:

True. I'm not saying our current situation is great. But, at least the

FSF is not planning to try and host all the world's git repos! That's

the point I'm making here.

Good idea. I don't know if our `guix authenticate' security model would

still work with a shallow clone. But, it's worth exploring.

Regards,

Arun

Hi Ricardo,

Interesting. I didn't know this was possible. If we can require all our

users to do this and disable forking of our repo, then that might solve

all our storage issues.

Regards,

Arun

Hi Cayetano,

Yes, that could be one possible solution. Another solution could be to

have a single URL but load balance at the DNS level based on your IP

address provided location.

Not that I'm aware of.

Regards,

Arun

Arun Isaac <arunisaac@systemreboot.net> writes:

If shallow cloning leads to a truncated commit history that doesn't

include the current introductory commit

(9edb3f66fd807b096b48283debdcddccfea34bad), then you'd need to specify a

later commit as the introductory commit during the first run of `guix

git authenticate`. Other than that, it should still work.

45mg <45mg.writes@gmail.com> skribis:

In practice, it always starts from the current commit. That is, if you

install 1.4.0, it assumes that the corresponding commit is authentic and

starts from there, rather than from the introductory commit. IOW, you

only need the history up to a known-good commit.

Ludo’.

Hi Arun,

Thanks for your feedback.

First, thank you and Ricardo for mumi. I didn’t write a single line of

it but I certainly encouraged it, enjoyed it (the version you deployed

yesterday or so is super nice, BTW!), and for a long time saw it as the

key to providing a good contributor experience “to those who don’t like

email”.

I think I was/we were wrong in two ways: first it’s not just about

providing a web interface, and second there are limitations in our

workflow that we just cannot overcome, as I tried to explain in the

“Motivation” section. We tried, very hard, and for a reason: a belief

(as far as I’m concerned) that we could not only be responsible for our

infra but also, in a way, that we could show fellow free software

hackers that an alternative development model was possible.

Your message raises concerns about the storage/bandwidth requirements of

Guix and the ability of a non-profit to keep up.

I agree with Leo and the GCD mentions it as well: we need to talk with

Codeberg e.V. from the start, possibly becoming a voting member, and to

offer funding. FWIW, we’re at 600 MiB¹ out of the 750 MiB quota². The

GCD documents AGit; we could make it the recommended way to contribute,

if that helps.

Will Codeberg manage to keep up? We don’t know. It’s not the first

non-profit doing it though. Framasoft has been running a popular GitLab

instance³ with 76k projects for 53k people⁴; its budget is higher but

they’re also doing primarily things unrelated to source code hosting.

Codeberg e.V. is specialized so I’d like to believe they have a lot of

headroom. That they’re transparent and upfront about their scalability

issues is a rather good sign to me.

Assuming we agree that a move along the lines of this proposal is

desirable (let me know if you think we don’t share that premise), what

other options would you think of?

Ludo’.

¹ https://codeberg.org/guix/guix-mirror

² https://blog.codeberg.org/more-power-for-you-what-a-storage-quota-will-bring.html

³ https://framagit.org/

⁴ https://framablog.org/2024/12/28/framasoft-en-chiffres-edition-2024/

Hi Ludo,

Thank you, I appreciate it. :-) I have more improvements (filtering

issues by team, for instance) in the pipeline, and will probably deploy

them in another week or so.

Good points, I agree.

I agree. I liked the honesty of the person we met at the FOSDEM stall.

And, I like it that their blog discusses their scaling issues openly.

I think we share the premise. I am not fundamentally opposed to the

proposal in any way. Lowering the barrier to entry and making the

project more accessible is a good thing. But…

According to the survey, only 9% want a pull request workflow, while 20%

just want timely reviews. My hunch (I have no data or proof) is that the

9% would also be perfectly happy if we just provide them timely reviews.

And, to provide timely reviews, we need to be focussing on entirely

different things—for example, the infinite growth of our package

collection and the strictness of our code reviews. If we could decompose

Guix into smaller channels, some of which have less stringent review

processes, we may get much faster reviews. To some extent, we see this

already in channels such as guix-science (less stringent review),

guix-cran (no review!), etc. Centralization of review and decision

making does not scale well. To grow, we need to devolve power. One day,

we aim to be as big as or bigger than Debian. We cannot do that without,

in some way, imitating their organizational structure. Shovelling more

coal into the fire may not be enough. It might work for a bit, but then

we'll just hit another limit and be stuck again. And, considering the

counterintuitive speed of exponential growth, we may reach that new

limit in no time. Some version of

https://en.wikipedia.org/wiki/Amdahl%27s_lawapplies here.

The proposal mentions better automation of our review process. But, many

of our review processes are not automatable—at least not easily so. For

example: the avoidance of marketing language in synopses and

descriptions, the listing of licenses for every single file in the

source tarball, the indentation of code[1], etc. Some rules such as the

use of double space[2] are antiquated and can be dropped with no

consequence. Our baroque Changelong format is another target of much ire

(even though I personally like it enough to use it in my own projects!).

[1]: there's human judgement involved (and for good reason) despite guix

style and other tools

[2]: Even the behaviour of Emacs sentence commands are not much of an

excuse here. I found out recently about the

sentence-end-double-space variable.

The Codeberg move aims to make it easier for contributors. But, if

anything, we already have too many contributions and are unable to keep

up with reviews! :-D Codeberg is likely to increase the number of

contributors without significantly increasing the number of reviewers. I

cannot be sure of this, nor can I provide much in the way of proof; only

time will tell.

I am sure a move to Codeberg can be seen as orthogonal to all these

concerns. And, perhaps it is. But, I'm just saying we should discuss the

limitations of this approach and be more aware of the larger

bottlenecks. What if we're throwing away the email workflow for nothing!

[half kidding] ;-)

Requiring the agit workflow and disallowing forks (preferably enforced

by technical means), thus solving the storage problem, would remove my

most important grievances with this proposal. I don't mean to block this

proposal at all. Let us proceed.

Thank you for your time and your patience.

Cheers!

Arun

Arun Isaac <arunisaac@systemreboot.net> writes:

The thing is, moving to Codeberg isn't just about the pull-request

workflow. I don't really care about that. What I care about is having a

/forge/, and all the features that come with it.

A forge would make the collaboration process far more accessible,

because it would provide a decent default experience for every

contributor (ie. the web interface). There would be no need to set up

isync/offlineimap/whatever + Notmuch/Mu4e/GNUs/mutt/whatever just for

the bare minimum of a decent UI for plain-text email.

And then, there are the additional features provided by a forge, which

are very difficult to provide in an email-based workflow. For example,

tagging issues. We have Debbugs usertags, but the majority of

contributors will not see them, because they'd have to use the Debbugs

web interface - and I struggle to imagine anyone ever doing that

willingly. I have tried to set up debbugs.el, but I couldn't get it

working the last time I tried, and frankly I don't have the energy to

configure even more Emacs-specific tooling that I will never use

anywhere else (as if contributing isn't difficult enough for non-Emacs

users...). Perhaps this is why I've observed that usertags don't really

get used much, outside of QA reviews maybe ('reviewed-looks-good').

Now compare this with the situation on GitHub or Codeberg, where there's

a web interface that even a child could figure out, that shows the same

view to everyone. So if you tag issues, you can be sure that everyone

will see the tags. It's that simple.

Also, more reliable and integrated QA would probably make a big

difference, since QA seems to be how committers find out whether a

series is ready to apply. While qa.guix.gnu.org is very impressive for a

volunteer effort, it suffers from a lot of issues that don't really

happen in modern forges (eg. failing to detect or apply patches from a

Debbugs submission), and we don't seem to have enough bandwidth to

improve it. A forge would provide most of what it does, and it would be

directly integrated with the rest of the tooling.

Could you share what aspects of Debian's organizational structure you'd

like us to mirror? I agree that decentralization is good in principle,

but I'm concerned about needlessly fragmenting the community. I'm not

familiar with how things work in Debian-land. If they've managed to

solve this problem, it'd be good for all of us to know about.

As I mentioned above, I think features like tagging, reliable detection

of merge conflicts, and a decent and consistent interface would remove a

lot of the friction involved in contribution/review. And since reviewers

are also contributors, a nicer and more efficient contribution process

would mean more time and energy left over for review.

On Wed, Feb 26, 2025, at 20:44, Arun Isaac wrote:

A minor point for those reading along: we do not list the licenses of every single file in source tarballs. We only describe the license of the package.

On 2025-02-27 01:44, Arun Isaac wrote:

TY!

Just a light comment on improvements, since I talked about that at Guix

Paris recently. One of the things is also the improvements on the

GNU/Debbugs side. On sourcehut, the server is able to recognise a patch

series / thread despite git send-email sending everything at once, since

the Message-ID contains the patch number in the series.

Is there someone working on that side? Would be weird if not, more than

5 years after Sourcehut has started.

FYI, I'm delving into both piem and emacs-git-email with 4 bugs sent

upstream (2 fixed already, 2 in the process). They are great tools, but

I've felt like many frustrated because of their lack of polish. Will

keep this up in the coming months.

--

Best regards,

Nicolas Graves

Hi Arun,

Arun Isaac <arunisaac@systemreboot.net> skribis:

You say “not fundamentally opposed”, but I’d like to stress that the

process is not about agreeing/disagreeing on an immutable proposal; it’s

about building it together to into account our concerns and needs.

There are many factors contributing to the lack of timely reviews. As

someone reviewing patches every week and who also tried the PR model and

tools despite a natural aversion, I can tell that tools play a role.

Examples: I easily lose track of updated patch versions and comments

because they’re just more unread email in my inbox; contributors

sometimes lose track of what they sent, so they open a new issue, and I

find myself digging for the original submission and review; people

comment on each other’s issues but there’s no way to know unless you

read every single message. And the list goes on.

Annoyances like this make reviewing tedious and discouraging.

These specific issues go away on Codeberg and similar platforms. Will

that be enough to achieve timely reviews? No, but I’m sure it can help.

(BTW, you should give Codeberg a try, as I mentioned in the cover

letter. It would ensure we’re all on the same page.)

[...]

I agree. And it’s also true that the important bit, qa.guix, does not

require Codeberg to exist. A “modern forge” just makes it easier to

automate things and to integrate them with the contribution workflow.

[...]

I don’t think there’s a “storage problem”. There’s a storage risk, and

it’s one of several—there are other ways Codeberg could fail, some are

spelled out in the GCD.

In my view, what we need to do during the discussion period is to find

ways to mitigate and deal with those risks in the months and years to

come. We already discussed the storage risk before; what more do you

think should be done?

How would you amend the proposal to better address this and other

concerns your raised?

Thank you,

Ludo’.

Hi Ludo,

Indeed, my bad. Sorry.

The only amendment I would strongly recommend is to require the agit

workflow in order to mitigate the storage problem/risk. This may require

changes to Forgejo. I say this without ever having used the agit

workflow. So others who know better should say so if this is a bad idea.

I do want to. But I didn't because I didn't want to overload your

personal repo with too many pull requests. Perhaps we can have a pilot

period (say 30 days) when both mumi/debbugs patches and codeberg pull

requests would be accepted methods to contribute. This may help put

people's minds at ease about the transition, and give them some time to

adapt their contribution/review worklows.

Finally, I understand that the move to Codeberg is a tough decision, and

I wish to express my appreciation for the leadership you are providing

the project.

Thank you,

Arun

Hi 45mg,

The mumi CLI can now tag issues[1], but I take your point that it is

never going to be as easy as a web interface.

[1]: https://yhetil.org/guix/87v7t15zl0.fsf@systemreboot.net/

I believe we will still be using most of our QA system with Codeberg.

Codeberg will simply trigger our QA system in some way. The Codeberg CI

will likely not have sufficient compute power to do what our QA system

does.

Also, I don't think the problem with the QA system is that it cannot

detect our patches. For some reason, it stopped working at some point.

Chris Baines should know the details. I am not very familiar with it.

I am not too clear about Debian's organizational structure either. I was

hoping channels can do for us what Debian's teams do for Debian.

Regards,

Arun

Hi,

thanks for the updated GCD. I'm in favor of it.

Anyhow, some remarks:

1) Regarding the AGit workflow discussed: This looks interesting

(haven't tried yet). I suggest adding a section to the GCD that this

will be documented within 30 days following acceptance of this GCD (or

even earlier). Beside this, I'm curious whether this would be possible

without "contributor" permissions – so everybody can submit patches this

way.

2) Regarding the issue tracker: I support not migrating issues. Anyhow,

i have two concerns, which OTHO can eventually be targeted in another

GCD or two:

be interesting whether we could automatically extract the latest patch

set and create a pull-request for it, including any cover letter

(amended with a link to the original issue). WDYT?

- or be closed. If we start using the Codeberg tracker, chances are high

issues.guix.gnu.org (and debbugs) will go out of sight and these issues

will get lost. Again this can be decided later on. Maybe many old issues

could be closed anyway.

3) Regarding workflow and tagging of issues/patches: It might be worth

giving some guidance how to tag issues in case. E.g. tagging as "won't

fix", "invalid". etc. Again, this can be discussed after migration as

this is unrelated to the actual migration. OTOH, if there already is

some practice on this, you could add it to the GCD  already.

--

Regards

Hartmut Goebel

| Hartmut Goebel | h.goebel@crazy-compilers.com |

| www.crazy-compilers.com | compilers which you thought are impossible |

Ludovic Courtès <ludo@gnu.org> writes:

I went through the Terms of Use and picked few points I considers

problematic and/or note worthy.

§ 2 (1) 3. looks pretty annoying for occasional contributors.

§ 2 (1) 4. forces us to rewrite repository history in case of

compromise, instead of just reverting the malicious commits. I do not

know what the Guix's current policy is for such a case, but it is worth

to keep in mind that we would no longer have a say in the matter.

§ 2 (4) is annoying for people not familiar with German law (which

includes me). Savannah is in the US, where the rules (possibly aside

the copyright laws) are bit less strict (at least that is my

impression).

§ 2 (5), especially the "its reputation" part, can easily lead to

loosing Codeberg account, and therefore ability to contribute to Guix,

over, for example, Mastodon toot complaining that Codeberg it down

again. After all, that could very well be considered "Action intended

to damage the [Codeberg's] reputation".

§ 3 (4) is pretty WTF. They could at least send an email. I plan to

keep working from the Emacs, so I am pretty sure I will not check the

dashboard for announcement messages regarding ToU changes every three

months.

§ 4 (4) is the typical "we can nuke your account at any time for any

reason". Nice.

And the "You must make sure that we have a way to contact you by keeping

the email address of your account up-to-date." is just a final middle

finger, because while I *have* to keep mail address up to date, they

cannot be bothered to use it to send me information that ToU did change.

I am not sure I agree to these (definitely not to all of them), so I

would probably be precluded from further contributions (since I would

need an account on Codeberg, which I cannot get without agreeing to the

ToU).

Also, there is a pretty nasty failure state when they do change the ToU,

and none of the committers would agree to the change. At that point

they (per the ToU) have to close their accounts and the whole repository

would be just stuck in the void with no way to migrate it away. I agree

this is pretty unlikely though.

All of this would be solved by self hosting, but I definitely understand

your reasons for wanting to avoid that.

Tomas

--

There are only two hard things in Computer Science:

cache invalidation, naming things and off-by-one errors.

Ludovic Courtès <ludo@gnu.org> writes:

I have opened the https://codeberg.orgin a browser with the LibreJS

extension installed, and two scripts are blocked due to "External script

with no known license":

https://codeberg.org/assets/js/webcomponents.js

https://codeberg.org/assets/js/index.js

They indeed do not seem to contain any kind of license notice.

Since Forgejo is Free software, I assume it is just a matter of some

mark missing somewhere. I am not sure on who this is to fix, whether

Codeberg (Forgejo?) or LibreJS, but I think it would be preferable if

site hosting our repository was not blocked by GNU LibreJS.

Have a nice day,

Tomas

--

There are only two hard things in Computer Science:

cache invalidation, naming things and off-by-one errors.

Hello Guix!

I have a question after reading most of this discussion:

Git has a 'request-pull' sub-command:

git request-pull [-p] <start> <URL> [<end>]

On the plus side, most probably, repo duplication on Codeberg would be

avoided by contributors who use the 'request-pull' sub-command

exclusively. No need for those contributors to deal with a web

interface. Most importantly, no mandatory account creation!

However, the pull request can be public while under review only if the

it is published somehow... probably in some kind of passive mailing

list.

The contributor must have his own git repository exposed at <URL>,

accessible to the official Guix committer(s), which means it won't be

convenient or feasible for everybody.

There are potential issues with the transparency of the review process,

but even if this is considered a problem, then I guess '-p' switch could

probably be made mandatory to alleviate any concerns.

There's also the question of how this would feed into your QA process, I

suppose the QA process would have to be completely unreliant on Codeberg

for 'git request-pull' to work with QA.

All in all, it couldn't replace forgejo completely without leaving aside

some contributors. However, leaving open the options to create or not

create a website account on Codeberg would be a * big * thing in that it

tackles what I personally see as the most serious objection to the GCD,

correctly identified by the initial description message, thanks for that

by the way.

Hence my question, I guess the answer is probably "no" but let's make

sure:

Might 'git request-pull' be made an option for Guix contributors in

parallel with the forgejo web process, if the GCD goes through?

Runciter

<#secure method=pgpmime mode=sign>

Ludovic Courtès <ludo@gnu.org> writes:

Possible typo in "create add"? :)

This seems reasonably simple to do, if this GCD does not pass, I will

take a stab at that.

If the AGit flow will be mandatory, new process will also be unfamiliar.

Just saying.

How do pull request templates work together with AGit flow that (as far

as I understand it) is being considered to be mandatory?

Maybe "listed below" instead?

The https://git.guix.gnu.org/guix.gitseems like a good idea regardless

of whether this GCD is accepted or not. It would allow us to switch the

hosting on moments notice in case the underlying infrastructure goes

down.

This contradicts GCD 001 no? The 001 requires the GCD to be sent as

patch to guix-patches@gnu.org. How will this be handled? Once 002 is

accepted, will we rush out 004 replacing the 001? Will there be enough

time for that? Once you close the guix-patches, you cannot propose a

*new* GCD per the current rules (and you cannot change the rules without

a GCD), so at least the initial posting *must* happen within those 30

days.

On separate note, there are other projects (well, I know just of

Shepherd, are there others?) than Guix using bug-guix and guix-patches,

so maybe this GCD should go a bit into how that will be handled.

This is not true. There is no API for getting the Terms of Use.

Changes in those are announced only as a banner on the website (as far

as I can tell).

One thing it does not support (based on the README) is the ability to do

an actual code review, which is a bummer.

Does this still require a Codeberg account? Can anyone update other

people's pull requests, the way I can currently sent n+1 version of a

patch started by someone else?

On Sun, Mar 02, 2025 at 07:10:26PM +0100, Tomas Volf wrote:

Yeah, I don't think we should require non-standard Git tooling.

Especially if the reason is a "storage problem" that doesn't seem to

exist with any other Git hosting service, and maybe doesn't for Codeberg

either. I think we have gotten ahead of ourselves talking about the

hypothetical "storage problem".

Hello.

On Sun, 02 Mar 2025 18:18:09 +0100

Tomas Volf <~@wolfsden.cz> wrote:

Codeberg developers expressed willingness to resolve this issue, but it

looks like they cannot decide on the approach. See this issue for

details: https://codeberg.org/Codeberg/Community/issues/64

The issue is also tracked upstream:

* in Gitea: https://github.com/go-gitea/gitea/issues/13393

* in Forgejo: https://codeberg.org/forgejo/forgejo/issues/1654

Meanwhile, another effort is to have the currently deployed source code

automatically disclosed, so that users could whitelist the website

manually. See: https://codeberg.org/Codeberg/Community/issues/1416

FSF associate members may also find this forum discussion relevant:

Roman

Hi Tomas,

Thanks for reading the proposal. I pushed a fix for the typos you

reported.

Tomas Volf <~@wolfsden.cz> skribis:

Good question, I don’t know, we’ll need to check.

That’s not how I see it; I think suggesting it is an option (but also

from because it provides an interface that some may prefer), but making

it mandatory now doesn’t seem justified to me.

Yes, I think so too.

I think we would amend GCD 001 to change references to the email

workflow with references to the Codeberg-based workflow. We should

probably spell it out here in an extra bullet, along these lines:

- Once the guix-consensus-document.git repository has been moved to

Codeberg, authorized people will apply [the

patch](https://issues.guix.gnu.org/XXX)amending GCD 001 to refer to

the Codeberg-based workflow.

And so we’d send the patch in question beforehand so everyone can see

how the GCD is amended.

WDYT?

Maybe with by extending the bullet above:

[…] meaning that messages will not get through anymore.

Other projects that were using bug-guix and guix-patches (the

Shepherd, Cuirass, etc.) must have set up their own bug-reporting

and patch-tracking tools by then.

In practice I believe Shepherd is the only one not under the Guix

project at Savannah that will have to do something special[*]; the other

projects will be able to use the Codeberg tools.

[*] I’d like to migrate Shepherd to Codeberg as well soon, under its own

organization.

I was thinking about this:

https://codeberg.org/api/swagger#/

Yes; I saw what you (re)wrote on this topic and I plan to reply

separately.

Concretely, it does not let you comment line-by-line so far, which is

what you would do in the web interface.

Of course you can still use ‘fj.el’ to send comments about changes

(that’s what I’ve been doing with those at

https://codeberg.org/civodul/guix/pulls), but for more complex code

reviews, one may have to resort to the web interface to pinpoint

specific issues in the code.

I agree that it’s a bummer, but I find that the overall benefit still

outweighs this annoyance (and it’s an annoyance for some of us but not

for everyone out there).

Yes.

If I’m not mistaken, the person who creates the pull request decides

whether they allow others to update it. (As a reviewer and “owner”,

I’ve definitely updated other people’s pull requests.)

Yes, I added a sentence to that effect and pushed it; let me know if

anything more should be done in your view.

That is true, but the same can be said of the current workflow.

I imagine this is technically feasible, but the problem is that setting

up bidirectional communication (so developers can ask questions to

reporters) is probably out of reach; in that case it would lose its

interest.

In practice, if someone sends a bug to guix-devel, we won’t ignore it,

but I think it’s in the project’s interest to direct bug reports to one

channel.

Thanks for your thorough review and insightful comments!

Ludo’.

Tomas Volf <~@wolfsden.cz> skribis:

As mentioned in my initial reply¹, this shouldn’t be frame as us-vs-them

(let alone harsh language), but rather as:

1. Is it a blocker?

2. If not, how can we work with Codeberg e.V. on that once we’ve

switched to Codeberg.

Having now read them, I personally find the ToU reasonable.

¹ https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00030.html

That’s reasonable: it’s a non-profit, they have to make space once in a

while, but that’s okay: Git is distributed, people have a local copy.

I definitely don’t read it that way: it’s not about “compromised” code

as in “CVE in guix-daemon”, and it’s not about genuine bugs either.

This is quite theoretical (whereas takedown notices in the US on GitHub

and the likes are something very tangible.)

Again that’s a bit of a stretch, but more importantly it’s framed as if

(1) we were dealing with a hostile adversary, and (2) we were customers

not owing respect to the volunteers making it work.

Let’s be very clear: that’s not the spirit of this proposal. We’ll be

using a service set up by other volunteers and we’ll be joining forces

in some way—financially or otherwise. There’s going to be downtimes and

problems, but we’re going to deal with them together.

I agree it’s not great, but it’s typically the kind of thing to discuss

with them, once we’ve moved; perhaps sending email would be acceptable

for them.

Yes, that makes sense to me.

The remaining paragraphs are harsh if not hostile (please avoid that

tone in the future) and hopefully covered by the rest of that reply.

Thanks,

Ludo’.

Thank you for addressing the points one by one. Few reactions below, I

have omitted those where I have nothing more to say.

Ludovic Courtès <ludo@gnu.org> writes:

Probably not for the project. ^_^ Though for me personally the § 3 (4)

is a blocker. I cannot in good faith agree to check the website every

three months, because I know I will not be doing that. I have already

failed at it once and I know it would happen again.

Hm I probably was not clear enough. I simply do not know what Guix

policy here is, so I just wanted to bring this up.

If some committer is compromised, and malicious commit gets pushed

upstream, what will Guix do? Revert the commit? Or rewrite the history

and remove it completely?

If latter, this point is moot and you can stop reading.

If former, I am not sure that would comply with the ToU.

I agree it might be a stretch, but at the same time I assume they had

*some* reason to put a fairly specific point like this into the ToU.

Let us hope.

Yes, I apologize for that. I just copy&pasted my original message

written in a bit heated state of mind. I should have adjusted the

language. Sorry.

Tomas

--

There are only two hard things in Computer Science:

cache invalidation, naming things and off-by-one errors.

Ludovic Courtès <ludo@gnu.org> writes:

I am pretty sure it should have not been pushed to the main branch, but

to wip-codeberg (or something similar). My understanding of GCD-001 and

the README is that main is for approved documents only.

Agree.

Yes, that seems good process wise.

I am not really looking forward to reading the debate (given the volume)

in the linear format in the Codeberg's issue tracker (no threading, no

dormant marks, ...), and I am not happy about limiting people able to

comment on GCD proposal to holders for Codeberg account, but both are in

the spirit of this (002) proposal, so it makes sense.

(Hypothetical funny situation would be a GCD about moving *off* Codeberg

due to people having troubles creating account, on which people it is

about would not be able to comment, due to not having an account. Yes,

yes, just joking.)

Sounds good.

Does it at least let you see line-by-line comments from other people?

Sorry for constant questions, but as you might have guessed from the

other thread, I do not have Codeberg account to try it myself.

Can this be enforced on repository level? So that we could mandate that

all pull requests are editable by anyone, to match how the debbugs work

currently?

Nothing more required, the addition looks good.

People having a working email are a strict superset of people having

Codeberg account, by definition. ^_^

Tomas

--

There are only two hard things in Computer Science:

cache invalidation, naming things and off-by-one errors.

Hi everyone,

A few comments which I will prefix with a summary of my own perspective:

1. I am an occasional contributor to Guix, contributing mainly packages

that I make for my own needs and wish to share.

2. I am a voting member of Codeberg e.V., because I believe that

Codeberg and its Forĝejo project are a step in the right direction,

which I see as transitioning forges from platforms to services

that don't "own" projects, nor user accounts.

Overall, I am very favorable to moving to a forge because of point 1. I

don't see anything objectively wrong or bad about the current e-mail

workflow, but for an occasional (or new) contributor its hard to become

fluent with it. In contrast, forges are becoming standard even for many

non-coders.

I won't comment on topics I am ignorant about, in particular the storage

debate. Nor much on other points that I think can be solved in

collaboration with the Codeberg team, e.g. the LibreJS issues.

That leaves the problem of becoming dependent on a platform, which

implies that all contributors must create an account and accepts terms

of services, and that, at least in theory, the platform owners can do

harm to the project.

As I said above, the long-term goal should, in my opinion, be forges as

services, much like e-mail servers. Projects bring their own domain,

terms of services, etc., and pay a service provider for keeping the

servers running, retaining the option of switching service providers. We

don't have this possibility right now, but the federation approach of

Forĝejo makes it look reachable in a small-integer number of years.

For me, moving to Codeberg is a stepping stone towards this goal. It

looks like Guix would be their larges project, meaning that we would

have a lot of influence on how Codeberg and Forĝejo will evolve towards

serving projects like ours. I see that as an opportunity.

As for the current terms of services, I have personally no issues with

them. Any set of written rules leaves a potential for abuse, so I am not

a fan of overinterpreting written rules. I'd rather look at how the

rules are applied, and from that perspective, I am not aware of any

project having had issues with Codeberg.org.

Cheers,

Konrad.

Konrad Hinsen <konrad.hinsen@fastmail.net> writes:

One more point that I forgot: moving to a forge could be even more

beneficial for increasing the number of people reviewing patches. For

submitting a patch, the current workflow is unusual but not so

complicated. For reviewing, I don't even know how to do it, in

particular how to apply and test patches from an e-mail message in a

sufficiently automated way. In contrast, on a forge, I could well

imaging participating in reviewing patches for ecosystems I am familiar

with.

Cheers,

Konrad.

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

[...]

I don't think maintaining the infrastructure *that would be replaced*

has been too time consuming. Sure, Mumi has had some issues and needed

some fixing, but most of what is used today:

- Savannah (git hosting)

- Debbugs (bug tracker) & Mumi

- Git configs/hooks

- Contributing documentation

rarely ever changes and has been stable, all while being generously

hosted, without limits on repository size or other criteria, on

freedom-respecting hardware and a friendly associated org (FSF/GNU),

which I assume can't be said of Codeberg (w.r.t. using free software

friendly hardware, such as using the GNU Boot bootloader). 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.

The parts that have required the most maintenance would be, I assume, CI

(Cuirass) and QA (Guix Build Coordinator), but these components will

continue to be used in the event we migrate to Codeberg, so we wouldn't

gain much on the maintenance side, it seems.

I believe some of the above, such as notifying everyone involved in a

ticket's discussion when replying, has been/could be tackled in the

improved GNU Debbugs rewrite that Felix has been refining and testing

[0, 1]. I think improving Debbugs for the whole of GNU (the Emacs

project actively use it still for example) would make sense and is

something I've been meaning to do, but not high in my priority list

(since it already works well enough for the most part). Hacking a small

Perl code base doesn't appear much more daunting than the modern

Go-written, web framework library heavy mastodon I assume

Gitea/Forgejo is, so I'm not sure why we wouldn't try this first

instead. I can't help but feel like we'd be throwing the baby out with

the bathwater: in my view, the current situation is not as bad as

suggested in your outlook, though I agree further automation and

simplifications would be welcome.

[0] https://codeberg.org/lechner/mumi

[1] https://patchwise.org/

My reading of the survey's results was that the main concern of the

community was packages' freshness and availability. Our backlog is

already larger than we can handle. Opening contributions from more

people, if that's what Codeberg would help with, wouldn't solve the real

problem of lack of eyes & hands to review and merge the contributions,

while giving us more work documenting the new workflows and their

quirks.

One serious usability quirk I can foresee is that given our current

PGP-based security design, committers would still need to push the

commits manually from their local machine so they can sign the commits

with their key, which probably defeats the streamlined and automated

niceties of the PR flow:

- The merge button in web UI would need to be disabled or documented as

prohibited (I doubt we'd even be able to disable it? or we'd need to

ensure the merge can be fast-forwarded and is already signed, which

would be a bit annoying since we'd need to not only fetch + rebase but

then visit the web interface to merge a change). It can all be

automated via the HTTP API I'm sure, but that wouldn't be much of an

improvement (if at all) over our current flow.

I suspect not being able to follow the expected way of merging things

probably further implies that:

- Issues won't be closed automatically since we can't use the merge

button.

- Both PR and issues must then be closed manually, which is what we

currently have

- The flow would be *even* more confusing than now, since it'd look

like Github but require committers to use it very differently.

Which would again need more custom tools/scripts as a workaround.

[...]

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.

Thank you for proposing this GCD!

--

Maxim

On 2025-03-04 12:22, Maxim Cournoyer wrote:

This is a very interesting take.

I have a similar view when we mention A-Git-Flow or whatever that is.

We would be using a tool in a very surprising way. I don't know if

that's good, at all.

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.

I like the proposal, but at the same time, I feel very comfortable with

Guix due to the fact that I can collaborate with email only (I even

decided to use the same model for my projects!).

Some of the things we have are very disturbing though: savannah is

weird, patches being mixed with issues, debbugs is not very comfortable

to use... I think that would be improved with Codeberg.

I don't know if this adds anything, but there it is.

Cheers,

Ekaitz

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

The Github workflow is more complicated:

- fork the repository on the forge website

- clone your fork from the forge to your local machine

- checkout a new branch

- make a commit

- push the commit from your local checkout to your fork on the

forge

- go to the forge website to open a pull request from your fork to

the upstream repository

The AGit flow:

- clone the upstream repository

- checkout a new branch

- make a commit

- push the commit as a PR to the forge.

Am I overlooking something?

--

Ricardo

Hello,

Arun Isaac <arunisaac@systemreboot.net> skribis:

The problem I see with requiring AGit is that we’d be making a decision

based on what we understand is a potential risk on Codeberg’s side.

I would rather not require use of AGit until Codeberg volunteers ask us

to do so or at least express concern in relation with Guix activity on

Codeberg. But of course, this could only happen after migration.

WDYT?

Alternatively (or in addition to the above), perhaps I can solicit

feedback from a Codeberg volunteer during this discussion period?

Yes, having a period where both methods are accepted sounds doable.

The risk is that some things would go unnoticed on one side or the

other, and during that period we’d be effectively splitting the

community between “those who prefer email” and “those who prefer

Codeberg”, but if it’s limited to 30 days max, that’s probably OK.

What do people think?

Ludo’.

Hi Ludo,

Talking to Codeberg sounds good. We have to do it anyway to discuss

other aspects of the migration.

Regards,

Arun

On 2025-03-04 18:19, Ricardo Wurmus wrote:

Yes but no.

It's easy, but if we are going to make any contributor do that, we are

still going to need documentation and people will come and complain.

Isn't the email based workflow as simple as:

- clone the upstream repository

- make commits

- send email

I would say that's even simpler (it doesn't even involve branches!). But

still people seem to struggle with it.

Codeberg is born from a software that intends to be a Github clone and

was originally designed with that workflow in mind. So people would

deduce we work using the Github workflow, and probably be frustrated

when they realize we don't.

I wouldn't be surprised if this is discussed as something problematic in

the future.

I'm not saying I dislike it (I do like it), but we have to be prepared.

I don't think the email workflow was specially difficult, I think this

change has been advocated for because people wanted to use the Github

workflow instead (the main argument was "it's what people is used to").

I know Ludovic's proposal doesn't try to overcome that specific "please

do what I'm used to because I don't want to think" problem, but we have

to be aware that those who want this change to happen because of it are

not going to be happy with the result.

Having the PR would be better for them than what we had. That's also true.

Also, now I'm thinking about it, the complexity of a-git-flow is

directly pushed to any contributors, and not only people with commit

access like the website being unable to merge things. So there's that, too.

Cheers,

Ekaitz

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

Here’s my point of view:

- clone the upstream repository

- make commits

- format patches

- configure git send-mail

- …or find out which addresses to send the mail and who to cc with

etc/teams.scm

- send email

Which is more complicated than the AGit flow IMO. And we will need

documentation on how to contribute no matter which way we choose.

What I especially like about the AGit flow is that it just uses git,

which is a common factor. No need for an alternate patch format, or

email.

Cheers,

Noé

On 2025-03-04 19:55, Noé Lopez wrote:

Of course, I was just making it simple on purpose. Those points you

address here have "easy" answers (my point being: as "easy" as

agit-flow, with quotes), once you configure, you don't have to type the

email addresses anymore.

The point what I wanted to make is not that it is really easier or not

(without quotes), but the fact that it doesn't matter. It's different to

what people expect, and that's going to create friction.

The heavy use of --push-option/-o is pretty weird for people that never

did that before (I never used that before and I have quite a long

experience collaborating in free software projects), the refspec usage

agit-flow needs is not widely known either.

- Was it refs/for/master or was it /for-review/ or what?

- Oh the -o description="..." takes a string but I want a multiline

thing that is getting too long.

- Oh no! the pr messed up my formatting again!

...

Well, at least the email we can write it in a proper editor very easily.

I don't know if that's the case in the -o unless we hack around...

(anyway, that's not the point here)

Well, patches are a part of git as --push-option is (Codeberg PRs are

not part of Guix, though), so I don't think this makes a good argument.

But regardless, my point was that when this issue was discussed, for

example, in a thread I started a while ago about the future of Guix, the

arguments I found were that Guix was too hard on newcomers and that we

needed to use a forge like any body else, because that's what people is

used to.

I still doubt that applying the Github workflow (or any other workflow)

is going to increase the amount of meaningful contributions (Guix is

already too hard as it is, it's not like the email workflow was the

hardest part of Guix) and I'm aware the move to Codeberg doesn't only

try to fix the commit workflow but also many other things, which I agree

with.

I just wanted to emphasize that if we are not letting people use the

merge button and we are going to use agit-flow or anything like that, we

are not going to make it obviously simple.

And it's going to make the committers' (our real bottleneck) life a

little bit hard for some time until we get used to this and we become as

efficient with it as we are now.

Cheers,

Ekaitz

Hi,

Andrew Wong <wongandj@icloud.com> writes:

You'd still need an email client to interact with guix-devel and our

other mailing lists, or to create the request to merge a feature branch

that QA understand (until this is adapted/changed to use something

else).

--

Thanks,

Maxim

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

[...]

At least two of the points this GCD is supposed to improve on is:

What would arguably be most familiar to newcomers is the Github-style PR

flow, whether we like it or not, and Gitea/Forgejo is a designed as a

clone of Github, even at its API level, so I'm pretty sure the PR flow

would be the intuitive expectation of newcomers interacting with it.

Using other flows that require typing command lines or abstracting these

via other tools is just changing a set of "weird" tools to another set

of "weird" tools, from a newcomer's perspective.

I'm not saying I don't see any positives to migrating to Codeberg, but

that if we can't use the PR flow then the points I quoted above do not

appear improved much by such a move.

--

Thanks,

Maxim

Hello,

I don't really understand this whole thread and worry about the Agit

flow. I think some information was lost along the way.

From my understanding of the GCD and other discussions, both the

classic PR github-like flow and Agit can live happily together. And the

GCD does not propose to only allow the Agit flow.

Everyone preferring (or simply only knowing) the classic fork-PR can go

this way.

Any person that would prefer not forking and working mostly from the

command-line can do so through the Agit flow.

But from the commiter/reviewer POV, this will look identical, i.e. a PR

on the repo.

Am I missing something?

The issue of not having a merge button comes from another set of

considerations (signing).

Cheers,

Alexis

On 05/03/2025 02:00, Maxim Cournoyer wrote:

Alexis Simon <alexis.simon@runbox.com> writes:

Correct.

This is correct.

--

Ricardo

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

The difference is that you don't need to configure "git

send-email" or

configure a local msmtp to send email to guix-devel or other

mailing

lists. For patches sent to guix-patches we recommend configuring

"git

send-email" to avoid garbled patches.

I know from mentoring people that setting up "git send-email" is a

real

hurdle, whereas sending simple emails to participate in

discussions on a

mailing list is not.

--

Ricardo

On Tue, Mar 04, 2025 at 08:22:59PM +0900, Maxim Cournoyer wrote:

I grabbed the following from one of the projects I've found on codeberg,

from an open pull request. The formatting didn't copy over, so I've

reformatted it a bit. I assume if we have "autodetect manual merge"

turned on then we wouldn't get the warning listed next to merge.

x This pull request has changes conflicting with the target branch.

* src/actions/repo/create.rs

↓ View command line instructions

# Checkout

From your project repository, check out a new branch and test the changes.

```

git fetch -u https://codeberg.org/gekkowrld/codeberg-clilist:gekkowrld-list

git checkout gekkowrld-list

```

# Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

```

git checkout main

git merge --no-ff gekkowrld-list

git push origin main

```

--

Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

On 2025-02-23 16:20, Ludovic Courtès wrote:

There is one thing I'm not sure someone raised earlier about ownership

and ease of access to data.

I hate a lot of AI usage/goals , but I think we should take advantage of

the research in this field when convenient and for a worthwhile goal

(that is : not making money by stealing people's attention). It seems we

have a tremendous amount of data (for git commits, git commit messages,

email exchanges) that could be used to train specialized AI agents that

could be very useful in CI / development contexts. A few examples on the

top of my mind:

- a commit message help complying with GNU standards

- a "rebuilder" agent, to try and rebuild a package that has failed when

the change is trivial (such as ignoring a test / try updating a

dependency). (This could be a "crew" of agents checking for

compilability, lints, build failures... with MCP protocoal and each

agent having its specific training data / RAG). (The goal is not to make

the user less responsible but instead waste less time doing what is

trivial.) Think about it : when rebuilding a package that is core to a

build-system, such as python, instead of spending the most part of a

week doing minor tweaks on hundreds packages, just let the background

job run a week until it only leaves "truly" difficult packages for teams

and maintainers. With some luck, since the tasks could be specialized,

we might already have enough data to train internally.

What's really good is that we might be able to only use guix data to

train and use this kind of helpers. Accessing this data in batch,

through the git repository, mailing lists, failed logs from build

farms..., is possible at this date.

Even if that would demand a coordinated effort anyway, I think the move

to codeberg would make this more difficult ; I also think guix's guile

and lists coherence is a strong advantage we don't take enough in

consideration (I don't think Nix would be able to have these kind of

helpers around, whereas it seems doable in Guix).

(This is not against moving to codeberg, but more about being mindful of

what we might loose on this aspect).

--

Best regards,

Nicolas Graves

Hi Nicolas,

Nicolas Graves <ngraves@ngraves.fr> skribis:

I’m skeptical to say the least, as I wrote elsewhere regarding

https://doi.org/10.1109/SC41406.2024.00090 — but this is off-topic.

Overall, the API that Codeberg and similar services provides makes it

easier to grab data about a project, not more difficult, first and

foremost because there’s one uniform API to access everything: issues,

pull requests, CI/CD reports, repo activity, and much more.

This can be seen in “empirical software studies” such as those submitted

to the Mining Software Repositories (MSR) conference. None of what’s

done in these studies would be possible when dealing with a patchwork of

informally-connected tools like the one we have.

Ludo’.

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Let’s not underestimate the development work by Ricardo, Arun, and Chris

over these tools for years (7 years for mumi), but also the everyday

sysadmin work done to keep things running.

I wouldn’t say that Savannah has been stable; debbugs.gnu.org is running

an unpublished, non-version-controlled fork of the original Debbugs

running on a single machine, manually-modified every now and then (I

know because I tried to rectify this back then, and so did Felix I

believe).

I agree that maintenance of these is largely a given for Guix. But

let’s not idealize it: there is a huge technical debt in all this

infrastructure.

That may be true, but I wouldn’t blame them given what it costed us to

run one server with a free BIOS¹. Codeberg/Forgejo volunteers are free

software activists though.

¹ Andreas gave a good account of this story in

https://10years.guix.gnu.org/video/ten-years-of-failures/.

Correct. Though, as the GCD states, it would reduce the number of

services and amount of code to maintain (Patchwork, email parsing, etc.)

I held this view for many years, which is part of why we have this

infrastructure; we’re not throwing the baby with the bathwater, we have

a decade of experience. I think this endeavor hasn’t been as fruitful

as we had hoped for and that it’s holding back the project now.

(For the record, Forgejo is known to be lightweight; the code base is

“human-sized” and easy to navigate IME.)

As others noted, better tooling is likely to improve reviewer

throughput. Of course nobody can guarantee any speedup, but there are

hints suggesting that.

I have been using the PR style (initially reluctantly) for Guix-Science,

Guix-HPC, and related repositories; I find it easier to see where my

attention is needed and what the status of patches is.

That’s also the reason I’ve been inviting people to give it a try: I

initially knew very well what I loved about the email workflow and what

I hated about the PR workflow, but only through experience did I

discover good things about the PR workflow.

The “Merge” button would be disabled, as noted in the GCD.

There’s an “autodetect manual merge” feature; it’s not as “auto” as one

might like but it’s okay.

Issues are closed automatically upon “Fixes #123” messages in commits.

Please give it a spin; it’s not perfect but it’s much better than what

you suggest. :-)

As noted in my reply to Arun², I think there’s a risk of splitting the

community if this experiment were too last for several months (Arun

proposed 30-day coexistence period, with eventual migration to Codeberg).

But maybe you can propose wording to amend the GCD?

² https://issues.guix.gnu.org/76503#37

The GCD process is about collectively building a proposal; there’s no

voting. I would encourage everyone to propose changes to the proposal

to address their concerns—it’s a living document.

As for experimenting, I agree and I reiterate my invitation to send

trivial patches to https://codeberg.org/civodul/guix (or to

Guix-Science, Guix-Past, etc.). I think this GCD’s discussion period is

the right time to give it a try as it can better inform discussions.

Thanks for your feedback!

Ludo’.

Hi,

Ricardo Wurmus <rekado@elephly.net> writes:

[...]

I believe git has good documentation for that, but yes, someone would

need to put this blurb in their ~/.gitconfig file:

Which shouldn't be much more difficult than setting up SSH keys to be

able to push to your Codeberg fork, it seems.

--

Thanks,

Maxim

Also, very good instructions are available at https://git-send-email.io/

I don't see why this is particularly hard. But, for some reason, that

seems to be the general perception. Perhaps it is seen as hard simply

because it is not the mainstream way to do things, and we end up having

to expend a lot of effort to compensate for that. One more hurdle, as it

were.

Hi,

Arun, thanks for this analysis. I concur on many points!

On Tue, 25 Feb 2025 at 14:03, Arun Isaac <arunisaac@systemreboot.net> wrote:

Moreover, this raises another concern: Such removal also make the

history harder to access and do not really save disk space, IIUC.

For one example, consider

https://codeberg.org/guix-science/guix-science/pulls/63.

As you can see, there is no “Commit“ and no “Files changed“. Why?

Because Alexis deleted the PR branch. Therefore, harder to know what

the PR was about; annoyances.

And the history seems still around. For example, we can access to the

first version [1,2] and compare with the second (force-pushed) version

[3].

Therefore, even using AGit workflow, we need to do some

back-to-the-envelope computations and estimate what is the scale of

Guix. Then ask if Codeberg has the capacity to host us.

Somehow, that’s not an unilateral decision, IMHO.

1: https://codeberg.org/guix-science/guix-science/commit/a333ccb9b729336501ae6c51f2c410b0e84ed200

2: https://codeberg.org/guix-science/guix-science/commit/8ecbff34229c0be0fc06fbd3d20122937fea1967

3: https://codeberg.org/guix-science/guix-science/compare/8ecbff34229c0be0fc06fbd3d20122937fea1967..efa112e41ec881bce47a6a287cad6bf2aaad1a96

Hum, a bit less than 1GiB of data, no?

Hi all,

On Wed, 05 Mar 2025 at 10:39, Ricardo Wurmus <rekado@elephly.net> wrote:

While I agree with that about the annoyances of “git send-email”, I also

think that forcing reviewers to have a Codeberg account is a real

hurdle.

Maybe I’ll appear “elitist” but if a person is able to prepare a patch,

then configuring “git send-email” isn’t an issue, IMHO.

Somehow, my opinion on this topic is: we should not focus too much on

the Contributor’s point of view – do not take me wrong, for sure I’m all

for being friendly, welcoming and inclusive; that’s not the point.

Instead, we need to focus on Reviewer’s point of view.

Our main issue: too much contributions and not enough reviewers and not

enough mergers. Nothing new and the same with most of all Free Software

projects, to my knowledge. However, we reach a point where we need to

act because merging patches is too much friction; and sadly both sides,

Contributors and Reviewers.

Therefore, for me, what does the forge bring that helps the reviewers?

For now, the only tiny difference I see is about CI. It’s easier to

automatically build a PR than to automatically extract patches for

building them.

The first time I met* Guix community, it was on December 2018 in

Paris. Well, I also remember that Chris spoke about Continuous

Integration, patchwork and what Chris was doing at the time.

Over the time Chris did an incredible piece of work. When we see QA and

all that, that's amazing! And Ricardo’s initiative with Mumi is also

very nice and helpful – and thanks Arun for nice features!

All that to say, this GCD raises this question: Do we want to put more

effort on CI and QA? Somehow, improve and/or make various bridges

between QA, CI and guix-patches? Or do we drop that part?

Cheers,

simon

*first time I met: If I remember correctly, Ricardo you came by

night-bus and you took a chocolate cake. <3

Hi Ludo,

On Fri, 28 Feb 2025 at 23:33, Ludovic Courtès <ludo@gnu.org> wrote:

Switch from Gnus to Notmuch. ;-)

Joke aside, I agree that’s annoying…

…and that’s too. Well, I agree it’s become a mess when the thread’s

broken and another issue is open.

However, weeks or months later, you can still easily give a look to the

submission. That’s not the case with PR: when Contributor deletes its

own branch then it’s more complicated, I guess.

One example: https://codeberg.org/guix-science/guix-science/pulls/63

As you see, there’s no Commit or Files Changes because Alexis deleted

the branch – yeah because the PR had been merged! :-) Yeah too that the

PR and history is somewhere but not easily accessible.

Just to point it can also become messy. :-)

Well, I do not have a strong experience on reviewing so I trust your

words when you say Codeberg might help here, eventually.

However, I think I have an experience about dealing with issues. Well,

for what my words are worth, most of what I’ve done are because all the

issues are emails. Somehow, coupling Emacs, Debbugs.el, Notmuch,

piem.el and Org-mode is my way to scale. For sure, I will never do

bug-triage without such tools.

Yes, Codeberg provides a nice API. Yes, it’s up to us to exploit it!

Yes, I’ve started to give a look. :-) But to my knowledge, nothing is

ready.

Therefore, I propose to postpone the discussion about the migration of

the “Issue Tracker”. Currently, it’s not part of our current

limitations, IMHO.

Somehow, I propose to delay the migration of the “Issue Tracker” and

open a GCD once we have 2-3 months of a full experience with the PR

workflow.

WDYT?

Or do I miss a radically awesome feature? :-)

Cheers,

simon

Hi Ludo,

On Wed, 26 Feb 2025 at 22:01, Ludovic Courtès <ludo@gnu.org> wrote:

Have we really tried hard? Not about the maintenance, big thanks for

all guix-sysadmin!

About developing the tools: As a project, I would not say “we tried very

hard”. Chris did, almost alone – thanks Chris for this heroic long-term

commitment effort. And about Cuirass, the last effort had been years

ago, to my knowledge.

As I wrote elsewhere, what are the concrete current features that

Codeberg offers against our limitations?

Our main limitation isn’t about contributing but about reviewing, IMHO.

Therefore how Codeberg is concretely helping? Not what are the

potentialities that Codeberg offers, but what does Codeberg bring on the

table right now compared to our current workflow?

Well, from my understanding, it’s easier to automatically build a PR

than to automatically extract patches and build them. So, Codeberg

helps right now because of CI. Do I miss another feature that helps

reviewing?

Hum, are we not putting the eggs before having the basket? :-)

Somehow, instead of a “Big Move”, it seems more approachable to only

move some teams, for example. Something like an incremental

“improvement”. It would help to have a concrete basis for discussing

how we can help them to have a sustainable solution for the Guix

project.

What if tomorrow Codeberg closes for whatever the reasons? Obviously,

we will find another solution. :-)

However, what about all the history hosted there? Yes, there is a nice

API and everything is doable. :-) To my knowledge, nothing is done for

having a backup of all the history.

About Debbugs, we have one public-inbox at least. Maybe archived [1] in

Software Heritage since public-inbox is Git-based. ;-)

I do not know if I share the premise… Well, for sure, as discussed with

a beer \o/ in Guix Days, I agree that we need to act now because the

current situation raises too much friction and that will be detrimental

for the project in the “short” term.

What I’m not sure about is the path for moving. Somehow, I find it too

much in a hurry. For instance, the GCD reads,

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.

when we have not yet discussed hard numbers with Codeberg. Or when we

do not have discussed on Guix Foundation side what could be done for

supporting them.

Similarly, why do we need to move in the same time the Issue Tracker?

Somehow, I would prefer a more incremental move. Because it would help

to improve step after step. Maybe using 2 or 3 steps over the whole

2025 year.

Cheers,

simon

1: The first patch sent to guix-patches, SWH still ingesting when

writing this. :-) So maybe here…

Hi,

On Tue, 04 Mar 2025 at 18:26, Ludovic Courtès <ludo@gnu.org> wrote:

Well, I think it’s doable to exploit Codeberg API [1]. Maybe an

implementation on Mumi side.

Somehow, it’s doable to have a tool that collects all PR submissions and

opens an issue on Debbugs side. This issue would contain the PR message

and the link to the PR and would have a special subject. For example,

one PR from Guix-Science [2] looks like:

PR#87 WIP: update ghdl to 5.0.1, and add ghdl-lsp.

Please review this submission at:

https://codeberg.org/guix-science/guix-science/pulls/87

This pr updates ghdl to its most up to date release, and renames

ghdl-clang to ghdl-llvm for consistency with upstream

artifacts. It also fixes the two other packages affected by this

renaming.

Then, it adds a new package, ghdl-lsp, including the language

server capabilities of ghdl (in addition to synthesis and

compiler, that we already have). Updating of python-pyvhdlmodel

and python-pytooling (see 76709) is necessary, so I set this pr

to WIP.

Then, we could list all open issues with the subject “PR#“ and query

Codeberg via the API to have the still open PRs. For the closed PR

ones, Mumi just sends a ’done’ control message to Debbugs.

That way, things would not go unnoticed. And you are raising, hey the

submissions to guix-pacthes will be unnoticed by people looking only to

Codeberg. Yes, but! 1. The aim is to move so to encourage people to go

via Codeberg. If the submission is merged faster when open on Codeberg,

then we’ll see the natural migration. ;-)

2. In that cases, etc/teams.scm will still CC teams people so it’s a

mitigation.

This way, it would avoid “The Big Move” and would allow something more

incremental. For example, I would prefer to have a spread team-basis

migration instead of some quick all-or-nothing migration.

Cheers,

simon

1: https://codeberg.org/api/swagger

PS: Obviously, I volunteer to contribute in the implementation of such

bridging tools. :-)

Hi,

On Sun, 02 Mar 2025 at 18:07, runciter--- via Guix-patches via <guix-patches@gnu.org> wrote:

Do you mean send to guix-patches the output of this command?

If yes, it would still require that the emails is well-formed. Then, it

would also require to adapt current extractors in order to get the

repository.

Such submission would create a temporary branch somewhere, because the

Contributor who submitted the request-pull could delete their own branch

and/or repository and/or the repository could be down. Therefore, it

would also require to adapt current tooling in order to delete the

branch once the submission is merged (Debbugs issue closed, roughly).

In addition, it would require to adapt again when it’s the second, third

or more revision of the submission.

Last, it would not be possible – to my knowledge – to comment on a patch

basis but you could only have one unique diff of the whole series.

This latter point appears to be a blocker for an alternative.

Cheers,

simon

Hi,

I agree with most of Maxim’s message. I add two points.

On Tue, 04 Mar 2025 at 20:22, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

a) Today, it’s not possible to work offline or by batch. To my

knowledge, there is no tool; at least nothing compatible with

Emacs.

b) Today, it’s not possible to comment on patches without the

web-interface, to my knowledge; least nothing compatible with

Emacs.

( Aside, through my own glasses, it would be a blocker. But I’ve myopia

and I know all people do not have the same lenses. ;-) I mean, I agree

that our workflow reach some limitations and that we need to act now

for helping the review/merge workload. Well, I’m adjusting my

glasses. :-) )

I agree. I propose 1. To design the move of the basis of teams in order

to be a bit more incremental [1]. And 2. To help in implementing a

simple one-way bridge [2]: report the open PR inside Debbugs.

Cheers,

simon

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

Simon Tournier <zimon.toutoune@gmail.com>

Thu, 06 Mar 2025 17:36:29 +0100

id:874j066rqq.fsf@gmail.com

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

Simon Tournier <zimon.toutoune@gmail.com>

Thu, 06 Mar 2025 17:35:25 +0100

id:875xkm6rsi.fsf@gmail.com

Hi Simon,

I agree, you are right about this.

I must admit that while I'm in favor of this GCD I'm not familiar

with

the PR workflow *at the scale of Guix*.

We will need tools in support of a reviewer's workflow. I tend to

easily get lost, whether that's on issues.guix.gnu.org and mailing

list

discussions, or on forges with many issues. In the documentation

of API

endpoints for codeberg.org I have not seen anything that roughly

equates

to "needs my attention".

It seems that on Codeberg the primary means of keeping track of

things

is through notifications. I fear I might still end up dropping

the ball

when a PR requires my attention if it gets buried in countless

notifications -- especially if I have to keep them unread to ever

have a

chance of finding them again. Obviously, a fix here would be to

adjust

my behaviour and not let notifications pile up, but this has no

chance

of ever happening. (In completely unrelated news: I've got 17532

unread

Guix emails.)

--

Ricardo

Hi Simon,

Thanks for raising this. This is a very important point. Losing history

like this seems very bad. Ideally, we want to have an archive of every

conversation and contribution that went into the project. Emails provide

this. If Codeberg does not, we should rethink our move.

I would also be in favour of postponing this GCD so that the

guix-science channel team can gain more experience with Codeberg and the

PR workflow. Quirks and annoyances like the above can only be found with

more time. guix-science moved to Codeberg only in January, IIUC. It's a

bit too soon to move the rest of Guix. Postponing the migration will

also give us more time to develop automation around Codeberg and see how

well that works out.

Yes, indeed, I said "about" 1 GiB. I was providing approximate

human-readable numbers. :-)

Regards,

Arun

Hello Guix devs,

I concur with Ekaitz’s observation:

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:

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:

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 xxyz@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

Hi Divya,

On Fri, Mar 07 2025, Divya Ranjan via Guix-patches via wrote:

I don't think this is a fair summary of the goal. The first sentence of

the GCD[1] is:

The contribution workflow in Guix has been facing several challenges:

difficult onboarding, lack of legibility, complex, unreliable, and

labor-intensive infrastructure, and lack of automation.

Of these, only "difficult onboarding" is about newcomers. Your proposal

(which I might describe as "proxy Codeberg into debbugs") involves

building new infrastructure without helping the other issues.

This is not true today. While Forgejo supports replying via email,

Codeberg does not have that enabled due to bugs. They have an issue

tracking it: https://codeberg.org/Codeberg/Community/issues/1562

Even if it was true, the big disconnect here would be around commenting

on specific lines of code. An email with a comment on a patch would come

through as a top-level comment on the PR, which is not natural in that

context.

Carlo

Arun Isaac <arunisaac@systemreboot.net> writes:

If you read through the Conversation section, you can see a message for

every time commits were added to the branch or it was force-pushed. If

you click on the commit hashes or subjects in these messages, it takes

you to a description of the commit, featuring a diff and files changed.

In this way you can see every iteration of the PR, just like we have

every patch revision in our mailing-list archives.

One thing I particularly like is that the final message (well, the one

before 'deleted branch *typst*') shows you the commit that was finally

merged. On the mailing lists, many of the issues are closed with a

message like 'applied with minor tweaks, thanks', and not all committers

will note the commit hash - so you're left grepping for the patch

subject line in `git log` if you want to know what tweaks were made.

Codeberg automatically notes the hash, and you can see the final

iteration just by clicking on it!

Hello Carlo,

You are correct, Carlo, the GCD does have multiple goals. But in my email I also elaborated how the onboarding issue is a high-priority task, reflective from the last survey and also something that can be achieved without risking too much. I believe we are at a probabilistic trade-off decision here, do we wish to achieve all the goals, including a complete change of infrastructure, workflow etc. in the proposed timeline of 15 days or so, and thus incurring a lot of problems that a team of committers would’ve to put a lot of effort into resolving? Or, do we wish to slowly achieve some of the goals, take those goals as a litmus test for the overall proposal and proceed gradually? I believe latter would be a safer bet, with less to risk immediately and opportunity to fix mistakes from feedback.

So, yes, my proposal cannot resolve all the goals, but I am trying to find a way to integrate what we have with what we might switch to. I might be at fault here, and feel free to elaborate on that, such as how can we approach the proposed quick migration to Codeberg while having a huge backlog of patches?

Thank you for this. I had tried it on a Forgejo repository, not a Codeberg one, so I believed the same could be possible here as well. From the discussions I see, if we spend enough time with them--which we need to do either ways--for the migration, they might get it working? Does not look far from possible to me.

Also thank you for bringing this issue, indeed this is a crucial functionality. But to be clear, this is specifically for a pull-request. The issues functionality is totally doable out of the box with Forgejo, we just need to make it work with Codeberg and polish it. With regards to the PR, one has to remember that the entire process needs to be wrapped around Forgejo’s API, not as our used to method of plain text. We’d be parsing JSON to-and-fro. For "reviewing a Pull Request" in Codeberg methodology, Forgejo provides a =/repos/{owner}/{repo}/pulls/{index}/reviews= API[0] to initiate a review. This API will take the comments from the patch in the Email, place them in the "body" string of the JSON, and the respective positions from the diff, the commit_id and so on. I agree it is non-trivial, but so is switching a workflow that has been in-place for years, also a non-trivial task. I think the API has enough things for what we need. And again, we don’t need all of them, we only require implementing those for now that bridge existing email workflow and the newcomers’ onboarding. Merging, for example, I propose to be done in the usual way of taking a patch and applying it. Eventually once we have less of a backlog, and more ease of migration, one might consider moving these core tasks to the Codeberg as well.

Either ways, we are at the crossroads and we need to decide which trade-off is worth the pain. I believe it is *not* certain that once we entirely migrate to Codeberg, the goals of "complexity" and "lack of legibility" would be immediately reaped. It creates a possibility of enjoying them, but given the assumption that the switch from existing architecture is smooth. And, once again, if we were a relatively smaller project such as the Guix-Science, this could’ve been a decision much simpler and with less at stake, but that is not the case. But I think it *is* certain that if we take an approach that doesn’t directly replace one workflow with another, but bridges the new one with the previous one, the committers will have a better way to switch. Simply because they can try to finish the backlog using the existing workflow, and the new patches can come to them with that as well. Where we go from there, can be decided upon how good the litmus test goes.

[0]: https://codeberg.org/api/swagger#/repository/repoCreatePullReview

Regards,

--

Divya Ranjan,

Philosophy, Mathematics, Libre Software.

PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A

Divya Ranjan <divya@subvertising.org> writes:

So at the end we'd have an even larger backlog of patches, and

spread

across two systems...? 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.

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.

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.

--

Ricardo

Hello,

I also agree that we should either not switch, or switch with a short

period of overlap. It does not make sense to spread our limited time to

work on two systems at the same time. And it definitely does not make

sense to spend additional development work (by whom?) to create a bridge

between the two.

Am Fri, Mar 07, 2025 at 10:21:48AM +0100 schrieb Ricardo Wurmus:

And it is something I learnt just recently after more than ten years of

contributing to Guix! If I understood correctly, it does not even alert

the original submitter. Probably I have closed a few issues because the

submitter had not read my comments or request for more information and

I had deduced that they were no longer interested. This alone would be a

reason for me to switch to a different system. We claim that our workflow

is "email based", but in fact it is not: To be informed about issues I

have contributed to, I need to keep each and every one in a bookmark and

visit it with my web browser regularly. At least in the forges I have seen

so far, I get an (often cryptic) email message when something happens

that entices me to connect to the web.

Anyway, I usually look at QA and the issues on the web when I have time

for a little committer work. The situation in which email works is when

I get an automatic copy for a patch touching one of my teams (and this

is very useful).

The overly graphic nature of these web forges makes them somewhat

confusing. For instance, it took me a little while to understand where

the trivial little patch was for an issue on Ludovic's test instance,

until I realised I needed to click once more. issues.guix.gnu.org is

much more focussed and less cluttered.

On the other hand, as soon as there is a patch series on issues, it also

becomes more or less unreadable; after 5 versions of a 6-patch series,

it becomes difficult to find the start of the current version and all

comments in between.

Andreas

Re,

On Thu, 6 Mar 2025 at 17:36, Simon Tournier <zimon.toutoune@gmail.com>

wrote:

Modulo the typo 's/;/:/' :-) The first patch sent to guix-patches is

archived in Software Heritage, FWIW.

Cheers,

simon

Ludovic Courtès <ludo@gnu.org> writes:

Based on Andreas's observations in [1]:

#+caption: https://yhetil.org/guix/Z8rJyIIUR84pWdLS@jurong/

#+begin_quote

On the other hand, as soon as there is a patch series on issues, it also

becomes more or less unreadable; after 5 versions of a 6-patch series,

it becomes difficult to find the start of the current version and all

comments in between.

#+end_quote

It seems if we are basing our experimentations on only "trivial patches"

that are sent to https://codeberg.org/civodul/guix, we may not be

observing the instances where a forge-style review process actually

struggles; our conclusions may be flawed.

[1]: https://yhetil.org/guix/Z8rJyIIUR84pWdLS@jurong/

--

Suhail

Suhail Singh <suhailsingh247@gmail.com> writes:

We have had non-trivial patches with a number of revisions on the

guix-science channel.

Examples:

--

Ricardo

Hi Ricardo,

On Fri, Mar 07 2025, Ricardo Wurmus wrote:

Then why is there a backlog of bugs?

I only see a group of software developers unable to close more bugs than

are being opened.

It's not because of technical limitations, but because the committers

are overwhelmed by the overall bug volume, are afraid to trigger

rebuilds or make other big changes, and are generally overworked

volunteers who also want to do other things in their lives.

There could be. I mated Debbugs with Public Inbox.

My system scans Debbugs for changes [1] but does not yet maintain

inboxes by bug number. The information is available via the NNTP news

protocol, for example with the Gnus configuration below. People could

subscribe to bugs via a news reader and reduce their mail load.

Debbugs does not copy folks automatically because many do not want it.

In Debian, submitters are often non-technical people. They do not care

about how a problem is solved, only when it is. Debbugs does that.

Kind regards

Felix

[1] https://patchwise.org/inbox/bugs-to-scan/

(setq gnus-select-method

'(nnimap "patchwise.org"

(nnimap-authenticator anonymous)

(nnimap-port "imap")

(nnimap-stream network)))

Hello,

Am Fri, Mar 07, 2025 at 09:40:28AM -0500 schrieb Suhail Singh:

my observation was rather the inverse: our current debbugs approch

struggles for patch series. For the submitters, this starts with a

series of size 2 (whenever I have one of these, I look up the Guix

manual on the web and follow the process described there; yet another

example where what I do is actually web based). For reviewers and

committers, series with a few commits are still okay.

Which says nothing about the experience on a forge, logically.

Andreas

Felix,

This is such an odd thing to ask, I cannot convince myself that

it's a

serious question asked in good faith. Surely you are not

suggesting

that my desire to work on Guix rather than doing sysadmin work or

hacking on infrastructure (which I *have* in fact been doing for

years

in service of the Guix project, even if you might be unaware of

it)

would be sufficient in reducing the backlog of bugs?

I don't know how you can make this claim with confidence. You

are, of

course, welcome to reject my experience here, but (like your

question

above) that's a really odd way of conducting yourself in a

discussion.

--

Ricardo

Andreas Enge <andreas@enge.fr> writes:

Ah, my bad. I mistook "issues" to mean issues on a forge as opposed to

a debbugs issue. Thank you for correcting.

True.

--

Suhail

Ricardo Wurmus <rekado@elephly.net> writes:

Thank you for sharing!

--

Suhail

Hi Ricardo,

On Fri, Mar 07 2025, Ricardo Wurmus wrote:

The remainder of my message made that clear but you were offended and

hit reply too fast.

My observation was about the group. I suggested as a hook for my

argument that your desire to contribute, which you have done more than

most, was not sufficient to reduce the backlog of bugs.

Isn't that how you and many other committers feel as well?

Kind regards

Felix

P.S. Questioning my good faith or my conduct was below the belt.

Hi Ricardo,

On Thu, 06 Mar 2025 at 21:05, Ricardo Wurmus <rekado@elephly.net> wrote:

Yes, I agree. IMHO, it would be a mistake to think that Codeberg would

ease how to deal with all the submissions. Even, because there is no

simple tools at hand – as Maxim said in [1] – the current interface

makes the process harder, from my point of view.

For example, Leo wrote [2]:

For me, the big problem with email is that resolved tickets don't get

removed from my inbox. Currently, my guix-patches inbox has 7000

messages. And 520 for bug-guix. Since April 2024.

and yeah that’s an issue! Well, maybe I’ve missed the obvious but my

Notifications are not removed when the PR is merged.

Somehow, the way Codeberg Notifications is currently implemented does

the same way as “my inbox”, IIUC, except that instead of being able to

manipulate these tickets with the comfort on a good email reader, now we

need API queries or live in the browser.

To say it explicitly, only at the scale of guix-science, I was spending

boring time only to manage with these Notifications already processed,

so the fix of my annoyance: fully turn off the Notifications – too old

to be bored again and again and not enough free time to scratch my itch.

Result: the exact same situation as with Debbugs.el – but a bit worse

because fj.el provides less capabilities compared to Debbugs.el and

Notmuch.

To me, moving from “patch by email” to PR is a good thing, potentially.

However, I am not aligned with the proposed “Migration Path”.

Somehow, we need something more gradual. For instance, 2 or 3 steps with

concrete and detailed milestones; targeting the end of “patch by email”

something as next December.

Why? Because we need to learn more where the friction could be, what is

really lacking, what makes too much hurdle, etc. And adapt accordingly.

All that to say, I am not convinced that completely jumping to something

fully new for most of us is a good approach; especially when the same us

already know the pitfalls of our tools or behaviour.

Cheers,

simon

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

Maxim Cournoyer <maxim.cournoyer@gmail.com>

Tue, 04 Mar 2025 20:22:59 +0900

id:8734ftdoq4.fsf@gmail.com

2: Re: [GCD] Migrating repositories, issues, and patches to Codeberg

Leo Famulari <leo@famulari.name>

Thu, 06 Feb 2025 14:39:26 -0500

id:Z6UP7nNeJlrnkA4U@jasmine.lan