* [GCD] Migrating repositories, issues, and patches to Codeberg
@ 2025-01-28 14:33 Ludovic Courtès
2025-01-28 18:09 ` Leo Famulari
` (17 more replies)
0 siblings, 18 replies; 76+ messages in thread
From: Ludovic Courtès @ 2025-01-28 14:33 UTC (permalink / raw)
To: Guix Devel
[-- Attachment #1.1: Type: text/plain, Size: 1006 bytes --]
Hello Guix!
I’m anticipating on the acceptance (hopefully) of the Guix Consensus
Document (GCD) process:
https://issues.guix.gnu.org/74736
(Speaking of which, if you’re member of a team as per ‘etc/teams.scm’
and haven’t replied yet as part of the deliberation period, now is the
time to do it!)
I believe this GCD can only be in “submitted” state if and after the GCD
process is accepted, which would be on February 5th. That doesn’t
prevent us from having preliminary discussions, including in Brussels
for those of us attending the Guix Days.
Anyway, the proposal is about migrating repositories, issues, and
patches to Codeberg. You’ll find the rationale, plan, and open issues
in the attached draft. I already found two “sponsors” for the proposal
(meaning they agree with the general direction and are willing to
participate in discussions) but if anyone else would like to sponsor it,
I’m happy to add them.
Feedback welcome!
Ludo’.
[-- Attachment #1.2: Draft of GCD 002 --]
[-- Type: text/plain, Size: 19286 bytes --]
title: Migrating repositories, issues, and patches to Codeberg
id: 002
status: draft
discussion: https://issues.guix.gnu.org/<number assigned by issue tracker>
authors: Ludovic Courtès
sponsors: Tobias Geerinckx-Rice, Ricardo Wurmus
date-submitted: <date when you send the first draft>
date: <date when the discussion period starts>
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
---
# Summary
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. All these lead
to an experience that contributors often find frustrating and hinders
quality assurance efforts. We propose to address these limitations by
migrating repositories, issue tracking, and patch tracking to Codeberg,
a “modern” forge hosted by a non-profit.
# Motivation
To keep track of bug reports and patches, Guix historically chose tools
that were *simple* in their design:
- bug reports and patches can be sent by plain email, without having
to create an account or even subscribe to a mailing list;
- discussion and patch review happen naturally by email, without
requiring special tools;
- the Debbugs instance at https://bugs.gnu.org keeps track of bug
reports and patches by assigning them an identifier and creating a
mailing list specifically for each bug or patch.
However, to overcome several limitations, the project developed
processes and tools, which can be characterized as *incidental
complexity*:
- because the Debbugs web interface is crude by today’s standards and
hard to search and navigate, the project developed
[mumi](https://git.savannah.gnu.org/cgit/guix/mumi.git/), the web
interface running at https://issues.guix.gnu.org;
- to navigate bugs and patches more conveniently than what an email
client supports, contributors were
[encouraged](https://guix.gnu.org/manual/devel/en/html_node/Debbugs-User-Interfaces.html)
to use interfaces like `debbugs.el` or `b4`;
- sending patch series by email does not play well with Debbugs’
automatic identifier assignment, so [contributors were told to send
their “cover letter”, wait for an identifier to be assigned, and
then send the
rest](https://guix.gnu.org/manual/devel/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches-1);
- to help sending and applying patch series, mumi was extended to
provide a command line interface;
- to build patch series submitted by email, the [QA
service](https://qa.guix.gnu.org) has to rely on a [Patchwork
instance](https://patches.guix-patches.cbaines.net/project/guix-patches/list/)
that is subscribed to the `guix-patches` mailing list, coupled with
its own [parsing of incoming
email](https://git.savannah.gnu.org/gitweb/?p=guix/data-service.git;a=blob;f=guix-data-service/branch-updated-emails.scm;h=aeb1570dfda725864a77780d0541f26c090b0e55;hb=c886685e9284da4bbed9377f70dd70da9e7ca29f);
- the project added a commit hook to create add unique `Change-Id`
headers in commit messages in an attempt to correlate commits in the
repository with messages send to `guix-patches`; none of the
existing tools takes advantage of it though, and it is up to
contributors to manually close entries in the bug/patch tracker once
they have been fixed/applied.
Developing and maintaining this software and infrastructure is
time-consuming. Worse, it leaves contributors largely dissatisfied for
a variety of reasons:
- the process is unfamiliar to most newcomers;
- the tools and infrastructure in Guix have become a maze;
- apart from the happy few using `debbugs.el` in Emacs, navigating
open issues and patches is hard; filtering incoming messages is
equally hard, even for those with 10+ years of experience with
advanced email tools (Gnus, mu4e, notmuch, b4, etc.);
- because the various parts of the development process (repository,
issue tracking, QA automation, `etc/teams.scm`) are largely
disconnected, even long-time contributors can hardly follow issues
relevant to them; issues may remain open after they’ve been fixed,
new activity on an issue may go unnoticed, cross-references among
issues are not visible in any of the interfaces, etc.
All this contributes to a [poor
experience](https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-3/)
for those who choose to contribute despite the barrier to entry,
probably discourages many to even start contributing, and adds to the
load of committers and infrastructure maintainers.
# Detailed Design
This section explains the chosen solution among the available options,
the scope of the proposed migration, a migration path, and an outlook on
automation.
## Choice of a Forge
We set out to choose a “modern forge” that supports a pull-request style
workflow and provides good integration between the repository, the issue
tracker, and the merge request tracker. The software behind the forge
has to be free software that is *plausibly* self-hosted on Guix
System—this probably rules out GitLab Community Edition and makes
[Forgejo](https://forgejo.org/) the main contender.
[Sourcehut](https://sourcehut.org/), the other interesting option, does
not offer the same convenience when it comes to dealing with patches and
runs the risk of reproducing onboarding and integration issues
surrounding an email-based workflow and “read-only” web interface that
Guix is already experiencing.
Forgejo has several features to support collaboration among a large
number of people and on a large code base, including
[teams](https://docs.codeberg.org/collaborating/create-organization/#teams)
and [issue and pull request
templates](https://forgejo.org/docs/latest/user/issue-pull-request-templates/)
Support for
[federation](https://forgejo.org/2023-01-10-answering-forgejo-federation-questions/)
is also under development and is a promising way to avoid
centralization.
Instead of self-hosting, this GCD suggests using the Forgejo instance on
codeberg.org, run by the [Codeberg e.V.](https://codeberg.org/about)
non-profit, registered in Germany. The non-profit has a good track
record of running codeberg.org with minimal downtime, is [committed to
supporting free software
development](https://codeberg.org/Codeberg/org/src/branch/main/en/bylaws.md#preamble),
[transparent](https://codeberg.org/Codeberg/org), and has governance set
up to achieve its mission.
The Guix-Science umbrella project [has been using Codeberg for several
months
now](https://hpc.guix.info/blog/2025/01/join-the-guix-science-community/),
which has allowed us to gain confidence in its suitability for a project
like Guix.
## Rights and Privileges
Migration should preserve rights and privileges regarding access to the
repositories. To that end, we propose the following rules:
- Committers to several of the repositories listed above and [Savannah
“group admins”](https://savannah.gnu.org/projects/guix) can request
membership in the [“Owners”
team](https://docs.codeberg.org/collaborating/create-organization/#teams)
of the [Guix *organization*](https://codeberg.org/guix). As of this
writing, only three people are members.
- Anyone listed the `.guix-authorizations` file of Guix can request
membership of the https://codeberg.org/guix/guix once it is created.
- Committers to one of the other repositories can request membership
of that repository.
In the future, we should extend the [“Commit
Rights”](https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html)
section of the manual to clarify the distinction between being a member
of the organization and being a member of a specific repository, in a
specific team.
## Repository Migration Path
The Guix project at Savannah contains the following repositories:
- [Guix itself](https://git.savannah.gnu.org/git/guix.git);
- [the bootstrappable.org web
site](https://git.savannah.gnu.org/git/guix/bootstrappable.git);
- [the DHCP client in
Guile](https://git.savannah.gnu.org/git/guix/dhcp.git) (forgotten
2015 Google Summer of Code project);
- [Guile bindings to
GNUnet](https://git.savannah.gnu.org/git/guix/gnunet.git) (forgotten
2015 Google Summer of Code project);
- [Guix artwork and web
site](https://git.savannah.gnu.org/git/guix/guix-artwork.git);
- [Cuirass](https://git.savannah.gnu.org/git/guix/guix-cuirass.git);
- [“maintenance”
repository](https://git.savannah.gnu.org/git/guix/maintenance.git)
(includes Guix System infrastructure configuration, talks, and other
documents);
- [scripts for videos presenting
Guix](https://git.savannah.gnu.org/git/guix/videos.git);
- [Guix Data
Service](https://git.savannah.gnu.org/git/guix/data-service.git);
- [Emacs-Guix](https://git.savannah.gnu.org/git/guix/emacs-guix.git);
- [Guix Build
Coordinator](https://git.savannah.gnu.org/git/guix/build-coordinator.git);
- [nar-herder](https://git.savannah.gnu.org/git/guix/nar-herder.git);
- [QA
Frontpage](https://git.savannah.gnu.org/git/guix/qa-frontpage.git);
- [mumi](https://git.savannah.gnu.org/cgit/guix/mumi.git);
- [Guix Consensus
Documents](https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git).
Within **30 days** following acceptance of this GCD, committers would
migrate all these repositories.
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. A commit would reflect that by
updating:
1. the `url` field in `.guix-channel`;
2. the `%default-channel-url` variable in `(guix channels)`;
3. any other reference to the URL that may appear in the repository.
Following this commit, an entry in `etc/news.scm` would explain the
migration. See [this entry in
Guix-Science](https://codeberg.org/guix-science/guix-science/commit/fd1b2dacd8d37c9d1939f9dc5a5b74256171ccbd)
for an example.
The Savannah `guix.git` repository would become a mirror of the one at
Codeberg, with a script periodically updating it, as a way to ease
migration to the new repository for users.
## Issue Tracker Migration Path
Importing all the issues and patches from Debbugs/mumi into Codeberg
would be impractical: it would require the development of specific
tools, would be a lossy process due to the fundamental mismatch between
plain text email threads and Forgejo issues and pull requests, and would
bring little in return.
Our proposal is the following:
- https://issues.guix.gnu.org will remain up and running for at least
**two years** following acceptance of this GCD. Note that once
issues.guix.gnu.org is down, issues will remain visible at
https://bugs.gnu.org and email archives will remain visible at
https://mail.gnu.org.
- Within **30 days** after acceptance of this GCD, mailing list
administrators will set up the `bug-guix` and `guix-patches` mailing
lists in “Emergency Moderation” mode in the Mailman
interface—meaning that messages will not get through anymore. It
will still be possible to interact on individual issues via
`NNN@debbugs.gnu.org`.
- The switchover will be advertised before it takes place with a post
to `info-guix@gnu.org`, to `guix-devel@gnu.org`, as well as through
a blog post.
- The “Contributing” section of the manual will be updated accordingly
at that time.
Care will be taken to advertise the various interfaces to
Codeberg/Forgejo that exist in addition to its web interface, such as
[forgejo-cli](https://codeberg.org/Cyborus/forgejo-cli/) and
[fj.el](https://codeberg.org/martianh/fj.el/).
## Teams
All the teams currently defined in `etc/teams.scm` will be reified as
[teams](https://docs.codeberg.org/collaborating/create-organization/#teams)
in the [Guix organization](https://codeberg.org/guix).
All these teams would have read-only access to the repositories, with
the exception of a new *Committers* team, with read-write access to the
repository, which would contain all the people who already have [commit
rights on
Savannah](https://savannah.gnu.org/project/memberlist.php?group=guix)
(“on-duty members”).
Team scopes in `etc/teams.scm` will be converted to a `CODEOWNERS` file
similar to [that found in
Guix-Science](https://codeberg.org/guix-science/guix-science/src/branch/master/CODEOWNERS).
That way, pull requests will automatically have them suggested as
reviewers for changes in their scope.
## Continuous Integration
Forgejo supports
[*webhooks*](https://forgejo.org/docs/latest/user/webhooks/), `POST`
requests that are sent to the server of one’s choice upon events such as
pull request creation. Cuirass (running at ci.guix.gnu.org) already
[supports](https://hpc.guix.info/blog/2025/01/join-the-guix-science-community/)
them and automatically creates a *jobset* when a pull request is made.
The [QA frontpage](https://qa.guix.gnu.org) and its [Data
Service](https://data.qa.guix.gnu.org) does not support Forgejo webhooks
yet but can be extended to do so without too much effort, possibly
sharing or reusing the Forgejo interface code from Cuirass.
In the Guix repository, we will set up webhooks to trigger the creation
of a new jobset at ci.guix.gnu.org (Cuirass) as soon as migration is
complete. While this has been successfully used for several months for
[Guix-Science](https://codeberg.org/guix-science), scalability will be
the major concern here; additional developments may be needed to
consolidate this support. Eventually the QA frontpage will also support
those webhooks.
We will arrange so that the build status of a pull request is clearly
visible right from that pull request.
Eventually, the QA service or a [Forgejo
*action*](https://forgejo.org/docs/latest/user/actions/) may
automatically provide feedback from `guix lint` as a reply to pull
requests.
## Workflow
Once continuous integration (CI) is fully operational, pull requests may
be merged if and only if they successfully built. “World-rebuild” pull
requests would still follow the [existing branching
process](https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html).
To help scale better, we will look for ways to empower team members who
are not members of the “Committers” team such that they can trigger a
merge even though they do not have commit access. This probably
involves a bot (TODO: think through it).
Since Guix requires signed commits by people listed in
`.guix-authorizations`, we will *not* be able to click the “Merge”
button nor to enable auto-merge on build success. This is a security
feature that we want but it limits scalability as actual merges lays on
the shoulders of committers. To reduce the load on committers, we could
use a scheme as follows:
- contributors create pull requests against a `staging` branch (TODO:
check PR templates to force `staging` by default);
- the `staging` branch is *not* signed and team members can somehow
enact (TODO: figure how) merging into that branch;
- committers periodically rebase and marge that branch into `master`
after a cursory look, with the understanding that it has been
reviewed and merged by authorized people.
That way, pushes to `master` will be limited to changes that have
already been validated and built.
XXX: Does it really belong in this document? Should we just keep that
for later?
- Committers can write to `master` (branch protection rule)
- Python members can write to `python-team` and `staging`
## Translation
We may eventually consider migrating translation work from [Fedora’s
Weblate](https://translate.fedoraproject.org/projects/guix/) to
[Codeberg’s](https://docs.codeberg.org/codeberg-translate/), as a way to
make it more discoverable and better integrated.
# Cost of Reverting
While the project *could* migrate back from Codeberg to bugs.gnu.org
(Debbugs), migrating issues and pull requests from Codeberg to Debbugs
would be practically infeasible. It is unlikely that anyone would want
this.
A more interesting question is: what would it take to migrate to a
different Forgejo instance or to a different forge?
Migrating to a different Forgejo instance would be rather simple since
Forgejo is able to *import* entire repositories with their settings
(including teams) and issues and pull requests from other instances.
Users would have to create accounts on the new forge instance though.
However, if federation support matures in Forgejo, one may be able to
operate on a repository from distinct but *federated* instances. That
would make any move much easier.
Forgejo appears to support
[“mirroring”](https://forgejo.org/docs/latest/user/repo-mirror/) to
GitLab instances, for instance, which could help migrating to a GitLab
instance. Migrating to a sourcehut instance would probably be more
difficult because of the feature mismatch.
Note that Forgejo offers a [rich HTTP
interface](https://forgejo.org/docs/latest/user/api-usage/) that
essentially allows users to get the raw data behind issues, pull
requests, and more, meaning that it is theoretically always possible to
grab the data.
# Drawbacks and Open Issues
Leaving it up to an external organization to manage critical
infrastructure of our project comes with risks.
Codeberg e.V., the non-profit that runs Codeberg, could always go
bankrupt, suffer from governance issues, or run into problems that any
non-profits face and which could lead to service discontinuation. This
could be mitigated by weaving close ties with Codeberg e.V., for
instance by financially supporting it or by setting a joint team to
monitor resource consumption induced by Guix and discuss any issues
encountered by either parties proactively.
The self-hosting option has its appeal for a project with the size and
values of Guix—it is not uncommon for similar projects to do that, an
example being the [Lix project](https://git.lix.systems/); there even
exists a [preliminary Forgejo service for
Guix](https://git.boiledscript.com/hako/Rosenthal/src/commit/7a6a28e872b3168f9b6513ccf797e247cd8a366d/rosenthal/services/web.scm#L32).
However the author thinks that, as it stands, Guix system administrators
have more than enough on their plate and are perhaps not up to the task
of providing the availability guarantees we expect from such a service.
As of this writing, Forgejo integration in Cuirass is functional but
partial (useful configuration options and hardening mechanisms are
missing) and missing from QA-Frontpage. This will have to be addressed
to fully take advantage of the new pull-request workflow.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
@ 2025-01-28 18:09 ` Leo Famulari
2025-01-28 21:08 ` Tomas Volf
2025-01-28 21:41 ` Tomas Volf
` (16 subsequent siblings)
17 siblings, 1 reply; 76+ messages in thread
From: Leo Famulari @ 2025-01-28 18:09 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel
On Tue, Jan 28, 2025 at 03:33:26PM +0100, Ludovic Courtès wrote:
> title: Migrating repositories, issues, and patches to Codeberg
> id: 002
> status: draft
I support this proposal, in general, in its draft state.
I'm very interested to hear about any discussions on this topic at the
Guix Days... please take notes!
I'd miss the ability to reply to things via email, but its a minor
complaint for me.
Overall, I think we should try to make this change in the interest of
growing the project.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 18:09 ` Leo Famulari
@ 2025-01-28 21:08 ` Tomas Volf
0 siblings, 0 replies; 76+ messages in thread
From: Tomas Volf @ 2025-01-28 21:08 UTC (permalink / raw)
To: Leo Famulari; +Cc: Ludovic Courtès, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 951 bytes --]
Leo Famulari <leo@famulari.name> writes:
> On Tue, Jan 28, 2025 at 03:33:26PM +0100, Ludovic Courtès wrote:
>> title: Migrating repositories, issues, and patches to Codeberg
>> id: 002
>> status: draft
>
> I support this proposal, in general, in its draft state.
>
> I'm very interested to hear about any discussions on this topic at the
> Guix Days... please take notes!
>
> I'd miss the ability to reply to things via email, but its a minor
> complaint for me.
I know that for example both GitHub and GitLab support replying to
notifications by emails. It seems[0] that Forgejo supports this as
well. So I assume there is no reason that could not be the case with
Codeberg (since my understanding from Ludovic's email is that it runs
Forgejo).
Tomas
0: https://forgejo.org/docs/latest/user/incoming/
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
2025-01-28 18:09 ` Leo Famulari
@ 2025-01-28 21:41 ` Tomas Volf
2025-01-30 7:35 ` Andreas Enge
` (2 more replies)
2025-01-28 23:32 ` Tomas Volf
` (15 subsequent siblings)
17 siblings, 3 replies; 76+ messages in thread
From: Tomas Volf @ 2025-01-28 21:41 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel
[-- Attachment #1: Type: text/plain, Size: 3805 bytes --]
Ludovic Courtès <ludo@gnu.org> writes:
> [..]
>
> Anyway, the proposal is about migrating repositories, issues, and
> patches to Codeberg. You’ll find the rationale, plan, and open issues
> in the attached draft. I already found two “sponsors” for the proposal
> (meaning they agree with the general direction and are willing to
> participate in discussions) but if anyone else would like to sponsor it,
> I’m happy to add them.
>
> Feedback welcome!
My personal point of view here is that I would somewhat miss the
integration to Emacs the current tooling has. I like Gnus and I like
debbugs.el. I noticed that you mentioned fj.el, but this sentence from
README
> If you find you are still being asked for the repo when calling a
> command from inside a repo with a Forgejo remote, check to make sure
> the local root directory matches the name of the Forgejo repo!
sound like using it from git worktree will be somewhat annoying. The
README recommend to just "set fj-token", I *hope* it can be integrated
with (auth)Top somehow. So I definitely have some research to do here.
From more ideological point of view, I think it is a strict downgrade
regarding the entry barrier. The very first thing new contributor needs
to do before contributing to GNU Guix is to read Terms of Service
document of a third party and agree to it.
I took the time to read it, and there are few points I have an issue
with:
§ 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 ToS 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 ToS 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
ToS).
Also, there is a pretty nasty failure state when they do change the ToS,
and none of the committers would agree to the change. At that point
they (per the ToS) 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.
Any opinions here? All of this would be solved by our own instance,
however I fully understand your point about the admin team being busy
enough already.
Have a nice day,
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
2025-01-28 18:09 ` Leo Famulari
2025-01-28 21:41 ` Tomas Volf
@ 2025-01-28 23:32 ` Tomas Volf
2025-01-29 3:05 ` Ian Eure
2025-02-03 21:00 ` Ludovic Courtès
2025-01-29 9:19 ` Cayetano Santos
` (14 subsequent siblings)
17 siblings, 2 replies; 76+ messages in thread
From: Tomas Volf @ 2025-01-28 23:32 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel
[-- Attachment #1: Type: text/plain, Size: 3297 bytes --]
Sorry for second email, few more comments and questions.
Ludovic Courtès <ludo@gnu.org> writes:
> ## Choice of a Forge
>
> The software behind the forge has to be free software that is
> *plausibly* self-hosted on Guix System—this probably rules out GitLab
> Community Edition
I am curious about this. GitLab Community Edition is under MIT (so
ticks the free software checkbox). While I am not an expert, I *think*
it is mix of golang and ruby code, so that seems feasible to self-host
on top of Guix system?
And GitLab would have the advantage that (Magit) Forge works with it.
> The Savannah `guix.git` repository would become a mirror of the one at
> Codeberg, with a script periodically updating it, as a way to ease
> migration to the new repository for users.
Will all the repositories listed above be mirrored? Or just the
guix.git?
> ## Issue Tracker Migration Path
>
> Importing all the issues and patches from Debbugs/mumi into Codeberg
> would be impractical: it would require the development of specific
> tools, would be a lossy process due to the fundamental mismatch between
> plain text email threads and Forgejo issues and pull requests, and would
> bring little in return.
I understand the impracticality, but just want to make sure I understand
the implications. Will this mean that I will have to go over all my
patches and resend them to Codeberg one by one, or is it expected the
patches already sent will still be processed (just new ones will not be
accepted)?
> Care will be taken to advertise the various interfaces to
> Codeberg/Forgejo that exist in addition to its web interface, such as
> [forgejo-cli](https://codeberg.org/Cyborus/forgejo-cli/) and
> [fj.el](https://codeberg.org/martianh/fj.el/).
I took a look at the fj.el and I did not figure out how to for example
create a pull request. So I assume people will need to create their own
tooling, probably around the forgejo-cli.
> ## Workflow
>
> [..]
>
> Since Guix requires signed commits by people listed in
> `.guix-authorizations`, we will *not* be able to click the “Merge”
> button nor to enable auto-merge on build success.
Out of curiosity, is it possible to disable the merge button? I am
pretty sure it is just a matter of time until someone presses it by
accident.
> [..]
>
> XXX: Does it really belong in this document? Should we just keep that
> for later?
In my opinion this deserves separate document later. That would help to
keep the debate focused on a single topic.
> Migrating to a different Forgejo instance would be rather simple since
> Forgejo is able to *import* entire repositories with their settings
> (including teams) and issues and pull requests from other instances.
> Users would have to create accounts on the new forge instance though.
> However, if federation support matures in Forgejo, one may be able to
> operate on a repository from distinct but *federated* instances. That
> would make any move much easier.
The federation looks interesting and I really hope it will get finished.
Would be pretty neat solution to lot of problems.
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 23:32 ` Tomas Volf
@ 2025-01-29 3:05 ` Ian Eure
2025-02-03 21:00 ` Ludovic Courtès
1 sibling, 0 replies; 76+ messages in thread
From: Ian Eure @ 2025-01-29 3:05 UTC (permalink / raw)
To: Guix Devel
Hi Tomas,
Tomas Volf <~@wolfsden.cz> writes:
> Sorry for second email, few more comments and questions.
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> ## Choice of a Forge
>>
>> The software behind the forge has to be free software that is
>> *plausibly* self-hosted on Guix System—this probably rules out
>> GitLab
>> Community Edition
>
> I am curious about this. GitLab Community Edition is under MIT
> (so
> ticks the free software checkbox). While I am not an expert, I
> *think*
> it is mix of golang and ruby code, so that seems feasible to
> self-host
> on top of Guix system?
>
> And GitLab would have the advantage that (Magit) Forge works
> with it.
>
I’m not sure what the current state is, but when I was looking at
setting up a self-hosted forge, GitLab was operationally very
difficult, and I would say it arguably fails to clear the bar of
"plausibly self-hostable." And, having used it as a day-to-day
system for work, it’s very buggy and complex; and the public
gitlab.com instance has frequent outages.
And if you take issue with Codeberg’s ToS, I don’t think you’re
going to like GitLab’s. https://about.gitlab.com/terms/
>> ## Issue Tracker Migration Path
>>
>> Importing all the issues and patches from Debbugs/mumi into
>> Codeberg
>> would be impractical: it would require the development of
>> specific
>> tools, would be a lossy process due to the fundamental mismatch
>> between
>> plain text email threads and Forgejo issues and pull requests,
>> and would
>> bring little in return.
>
> I understand the impracticality, but just want to make sure I
> understand
> the implications. Will this mean that I will have to go over
> all my
> patches and resend them to Codeberg one by one, or is it
> expected the
> patches already sent will still be processed (just new ones will
> not be
> accepted)?
>
I’m also wondering about the mechanics of this. With the volume
of patches Guix gets, any single cutover date will impact
someone’s work in flight. If it’s possible transition by:
- Setting a date for new work to occur in codeberg.
- Disabling the creation of new bugs in debbugs on that date.
- Allowing work in progress which was started in debbugs to be
completed in debbugs.
...that seems like a reasonable way to shift over.
>> ## Workflow
>>
>> [..]
>>
>> Since Guix requires signed commits by people listed in
>> `.guix-authorizations`, we will *not* be able to click the
>> “Merge”
>> button nor to enable auto-merge on build success.
>
> Out of curiosity, is it possible to disable the merge button? I
> am
> pretty sure it is just a matter of time until someone presses it
> by
> accident.
>
Yes. The repo settings lets you control which merge styles are
offered, and unchecking everything other than "Manually merged"
will disable the button.
-- Ian
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (2 preceding siblings ...)
2025-01-28 23:32 ` Tomas Volf
@ 2025-01-29 9:19 ` Cayetano Santos
2025-02-03 21:03 ` Ludovic Courtès
2025-01-29 9:55 ` Steve George
` (13 subsequent siblings)
17 siblings, 1 reply; 76+ messages in thread
From: Cayetano Santos @ 2025-01-29 9:19 UTC (permalink / raw)
To: ludo; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
Given the current work in progress status of tooling at Codeberg side,
would it be feasible to consider a period of time during which the two
strategies overlap ? Kind of a testing cohabitation period.
For sure, this would imply manual intervention and some degree of
overload to committers during this time, to keep the two repositories in
sync: we should have to keep on accepting email patches, as well as new
pull requests so as to compare benefits and drawbacks of each strategy,
based on existing tooling.
I’m asking because moving to a completely different approach, based on
current obvious difficulties, seems to me like a relevant decision,
which implications in terms of a non-return jump to unknown. As for
today, qa, ci, auto patch checking, facilitating committers life and the
like are the biggest obstacles to move forward, from my perspective.
Remains to be tested that such a change improves current situation so
as to compensate for the lack of flexibility it imposes.
--
Cayetano Santos
GnuPG Key: https://meta.sr.ht/~csantosb.pgp
FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (3 preceding siblings ...)
2025-01-29 9:19 ` Cayetano Santos
@ 2025-01-29 9:55 ` Steve George
2025-01-29 10:08 ` Divya Ranjan
` (12 subsequent siblings)
17 siblings, 0 replies; 76+ messages in thread
From: Steve George @ 2025-01-29 9:55 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel
On 28 Jan, Ludovic Courtès wrote:
> Hello Guix!
>
> I’m anticipating on the acceptance (hopefully) of the Guix Consensus
> Document (GCD) process:
>
> https://issues.guix.gnu.org/74736
>
> (Speaking of which, if you’re member of a team as per ‘etc/teams.scm’
> and haven’t replied yet as part of the deliberation period, now is the
> time to do it!)
>
> I believe this GCD can only be in “submitted” state if and after the GCD
> process is accepted, which would be on February 5th. That doesn’t
> prevent us from having preliminary discussions, including in Brussels
> for those of us attending the Guix Days.
>
> Anyway, the proposal is about migrating repositories, issues, and
> patches to Codeberg. You’ll find the rationale, plan, and open issues
> in the attached draft. I already found two “sponsors” for the proposal
> (meaning they agree with the general direction and are willing to
> participate in discussions) but if anyone else would like to sponsor it,
> I’m happy to add them.
>
> Feedback welcome!
(...)
Hi,
I'm supportive as I think this will help the project develop and retain more developers.
The Survey shows the #1 piece of feedback from contributors is that the **speed and capacity of reviews** is a massive challenge: in one question 63% of contributors specified this as the biggest challenge. I think we know this - but seeing it at those levels really brings the point home! I can see that using a well-known forge would be give us ways to focus on automating patch review and simplify our overall process over time.
Second, people who've stopped contributing directly cited the overall friction and the email-based model as reasons why they stopped contributing. There were many comments about the unfamiliarity of the current process compared to the standard PR-based system. I infer that this change will help us reach out to develop our community of contributors.
I do think there's a cost for those of us who have a comfortable workflow (or in my case about 5 files of instructions!) - so I appreciate it's going to be uncomfortable/bumpy - but I believe the project will benefit.
Personally, I like Codeberg from what I've seen. I'd be interested in understanding how we can build a relationship with them?
Can we work with them as we migrate, what is their situation, and how do we support them financially since infrastructure isn't free?
Running less of our own infrastructure would be great, but we should be good citizens with Codeberg as a small non-profit (that's my current understanding of their situation).
Steve / Futurile
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (4 preceding siblings ...)
2025-01-29 9:55 ` Steve George
@ 2025-01-29 10:08 ` Divya Ranjan
2025-01-29 11:10 ` Ricardo Wurmus
2025-01-29 11:24 ` 45mg
` (11 subsequent siblings)
17 siblings, 1 reply; 76+ messages in thread
From: Divya Ranjan @ 2025-01-29 10:08 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel
Hello Ludo,
> All this contributes to a [poor experience](https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-3/) for those who choose to contribute despite the barrier to entry, probably discourages many to even start contributing, and adds to the load of committers and infrastructure maintainers.
While I have differing views on the poor experience, from the 3rd part of survey’s results, don’t we see the answers to "What would help you contribute more to the project?" has answers of differing priorities? Only 9% of contributors feel like the addition of a PR-based workflow ála Github/Codeberg/Gitlab would lead to them contributing further but while 203 respondents (a total of 20%) report that it’s the timely reviews and actions on contributions that inhibit motivation for further contribution.
I have started contributing over the last few months, and the current (Savannah, email based) workflow was a bit difficult but I overcame it in a few days, not even a week. And I’d certainly accept that I had an existing workflow for similar projects I contribute to, and have had used Gnus, and debbugs.el, but the learning curve isn’t really that much of an issue, from my personal opinion.
What I do think could lead to better contributions is what’s reported in the survey before the workflow change, i.e, timely reviews, better REPL debugging and most importantly a guidance/mentoring setup. Guix Social goes far enough to enable this to some extent, thanks to Steve, but we should have a workflow where we keep certain issues/upgrades as low-hanging fruit for the beginners, and walk them through it over time. I had Ekaitz do the same with me, when i was contributing my first package to Guix. And I’d always be grateful for that, because if I hadn’t had that mentoring for a day or two, I’d have gotten frustrated and kept contributing to Guix aside for a while.
I use and have used Codeberg and Sourcehut, it’d be not an issue for me to switch either way. Though I do have to ask, would there be an intent to maintain a mirror at Savannah, if Guix chooses to primarily shift to codeberg/forgejo? And also, it is better to go with Forgejo as a self-hosted instance than relying on codeberg.org since the latter has limitations on how big repositories you can host[0]. I’ve heard they can provide more, but since we already have existing infrastructure, why not go the self-host path?
I’d be glad to contribute to the migration however I can, but I suggest we reflect on the necessity and consequences of this a bit more.
[0]: https://docs.codeberg.org/getting-started/faq/
Regards,
--
Divya Ranjan,
Philosophy, Mathematics, Libre Software.
PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-29 10:08 ` Divya Ranjan
@ 2025-01-29 11:10 ` Ricardo Wurmus
2025-01-30 10:42 ` Divya Ranjan
2025-02-04 12:54 ` Maxim Cournoyer
0 siblings, 2 replies; 76+ messages in thread
From: Ricardo Wurmus @ 2025-01-29 11:10 UTC (permalink / raw)
To: Divya Ranjan; +Cc: Ludovic Courtès, Guix Devel
Divya Ranjan <divya@subvertising.org> writes:
> Only 9% of contributors feel like the addition of a PR-based workflow
> ála Github/Codeberg/Gitlab would lead to them contributing further but
> while 203 respondents (a total of 20%) report that it’s the timely
> reviews and actions on contributions that inhibit motivation for
> further contribution.
[...]
> What I do think could lead to better contributions is what’s reported
> in the survey before the workflow change, i.e, timely reviews, [...]
In the short time that we've used Codeberg for guix-science I've found
it much easier to see at a glance what patches await my review and what
their current status is. This directly improved my ability to review
and merge patches.
I'm no stranger to debbugs and had previously built mumi (which powers
issues.guix.gnu.org); we never managed to reach the same level of
convenience. People send patches without X-Debbugs-Cc-ing the
associated team and so patches wait for a review for months. Or they
*do* Cc the team, but the email drowns in all the other Guix emails and
I have no way of listing all patches affecting my field of
responsibility, etc.
Search on mumi has always been a little wonky, and my very limited time
was better used to maintain the ever-growing package collection than
working on improving mumi, which was never been very enthusiastically
received by the community and which inherits all the problems and
limitations of debbugs. A year ago (or longer?) I decided to only
resume contributions to mumi if the community overwhelmingly commits to
supporting it. Aside from the very good sustained work by Arun this has
not happened.
I think we've accepted this dysfunctional state for long enough to state
with confidence that there isn't enough collective will, time, and
energy to improve our custom systems to support a more streamlined
review process. These are not independent topics. I do expect that
migrating to Codeberg will improve review throughput.
--
Ricardo
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (5 preceding siblings ...)
2025-01-29 10:08 ` Divya Ranjan
@ 2025-01-29 11:24 ` 45mg
2025-02-02 11:13 ` Ricardo Wurmus
2025-01-29 17:34 ` Noé Lopez via Development of GNU Guix and the GNU System distribution.
` (10 subsequent siblings)
17 siblings, 1 reply; 76+ messages in thread
From: 45mg @ 2025-01-29 11:24 UTC (permalink / raw)
To: Ludovic Courtès, Guix Devel
Ludovic Courtès <ludo@gnu.org> writes:
[...]
> Anyway, the proposal is about migrating repositories, issues, and
> patches to Codeberg. You’ll find the rationale, plan, and open issues
> in the attached draft. I already found two “sponsors” for the proposal
> (meaning they agree with the general direction and are willing to
> participate in discussions) but if anyone else would like to sponsor it,
> I’m happy to add them.
Right off the bat, I want to say that I think this would be a good move
in the long run. While I've come to enjoy the efficient tooling I've
painstakingly assembled to deal with the mailing lists, an email-based
workflow is simply not accessible enough for the majority of users
today, for a number of reasons. (I won't go into details right now; I'll
wait for the discussion to develop a bit.)
[...]
> - the project added a commit hook to create add unique `Change-Id`
> headers in commit messages in an attempt to correlate commits in the
> repository with messages send to `guix-patches`; none of the
> existing tools takes advantage of it though, and it is up to
> contributors to manually close entries in the bug/patch tracker once
> they have been fixed/applied.
I do hope we keep the Change-Id hook, as one of my upcoming
contributions will make use of it ;)
[...]
> 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. A commit would reflect that by
> updating:
>
> 1. the `url` field in `.guix-channel`;
> 2. the `%default-channel-url` variable in `(guix channels)`;
> 3. any other reference to the URL that may appear in the repository.
There'd probably be a lot of references in the manual that would need to
be updated as well. Just something to remember.
[...]
> ## Issue Tracker Migration Path
>
> Importing all the issues and patches from Debbugs/mumi into Codeberg
> would be impractical: it would require the development of specific
> tools, would be a lossy process due to the fundamental mismatch between
> plain text email threads and Forgejo issues and pull requests, and would
> bring little in return.
>
> Our proposal is the following:
>
> - https://issues.guix.gnu.org will remain up and running for at least
> **two years** following acceptance of this GCD. Note that once
> issues.guix.gnu.org is down, issues will remain visible at
> https://bugs.gnu.org and email archives will remain visible at
> https://mail.gnu.org.
> - Within **30 days** after acceptance of this GCD, mailing list
> administrators will set up the `bug-guix` and `guix-patches` mailing
> lists in “Emergency Moderation” mode in the Mailman
> interface—meaning that messages will not get through anymore. It
> will still be possible to interact on individual issues via
> `NNN@debbugs.gnu.org`.
> - The switchover will be advertised before it takes place with a post
> to `info-guix@gnu.org`, to `guix-devel@gnu.org`, as well as through
> a blog post.
> - The “Contributing” section of the manual will be updated accordingly
> at that time.
I strongly feel that the Guix project itself needs to maintain a
permanent (read-only) archive of all its mailing lists, and ensure that
it is searchable and downloadable. This may not seem related to the main
topic of the GCD, but it very much is. Hear me out here.
On one hand, the lists are an invaluable source of information. Without
the ability to search them (locally, via Notmuch), I don't think I would
have gotten as far as I have with Guix. There's over a decade of
discussions and bugfixes and workarounds that aren't documented anywhere
else, and moreover the project's history itself is contained in those
lists. Having them permanently accessible, in an easily searchable
manner, is of paramount importance.
On the other hand, such access is NOT provided by lists.gnu.org (is this
what you meant by mail.gnu.org?) and bug.gnu.org. You've acknowledged in
your GCD that Debbugs' user interface is substandard. lists.gnu.org is
infinitely worse. Here are just a few assorted gripes:
- It only shows one message at a time, so you have to actually find and
click a 'next in thread' button, repeatedly, to read an entire thread,
as though the concept of scrolling had never been invented;
- The 'thread index' view does not show more than 4 levels of nesting,
meaning that the thread structure is completely lost in sufficiently
deep threads, thereby casually discarding the primary UI advantage of
email discussions;
- There is a separate thread index for each month, so that the page for
this thread [1] will only link to replies until the end of this month,
and people not used to this bizarre design will think the discussion
just died out abruptly and not see anything in future replies;
- Primitive search options, including the advanced search, which I have
never used successfully even once;
...and countless other complaints.
Right now, probably the only reason people learn to live with this
nonsense is that it's really the only meaningful place to look (apart
from IRC archives, don't get me started...). If we move to Codeberg,
that repository's issue tracker will become the place for usage-related
discussions, and the place where most people look for information. With
the list archive interface being as primitive as it is, the majority of
new users will never utilize it effectively. Over a decade's worth of
precious information will functionally cease to exist for a large
section of the community, with the rest of us busy fielding the same
questions that have been answered a million times before.
Luckily, there's a decent solution to this problem - public-inbox. No
sales pitch I could give will surpass the evidence of your own eyes;
just compare this thread on lists.gnu.org [1] to the same thread on an
unofficial public-inbox mirror of guix-devel:
[2] https://yhetil.org/guix-devel/871pwnc8jt.fsf@inria.fr/t/#u
The advanced search works great as well, and it's possible to produce a
maildir from a clone of a mailing list [3].
What I'm proposing is that once we archive the lists, we create a
public-inbox archive of them, and just host that permanently. That way,
the archives become actually usable without the need to download them in
their entirety and index them with Notmuch/Mu.
I'm actually fine with sunsetting issues.guix.gnu.org; while it was a
significant improvement over the list archives, it still needed a lot
more love. Moreover, it was fundamentally trying to turn threaded email
discussions into flat lists of messages, with mixed results.
> Care will be taken to advertise the various interfaces to
> Codeberg/Forgejo that exist in addition to its web interface, such as
> [forgejo-cli](https://codeberg.org/Cyborus/forgejo-cli/) and
> [fj.el](https://codeberg.org/martianh/fj.el/).
For fellow Emacs users, I'd also like to mention that magit-forge [4]
recently added rudimentary Forjego support:
[5] https://github.com/magit/forge/commit/0c81b44fb21e95719035a38e81ff088e808318dc
This is likely the best possibility for Emacs integration, since it's
integrated with Magit.
[...]
> Since Guix requires signed commits by people listed in
> `.guix-authorizations`, we will *not* be able to click the “Merge”
> button nor to enable auto-merge on build success. This is a security
> feature that we want but it limits scalability as actual merges lays on
> the shoulders of committers. To reduce the load on committers, we could
> use a scheme as follows:
>
> - contributors create pull requests against a `staging` branch (TODO:
> check PR templates to force `staging` by default);
> - the `staging` branch is *not* signed and team members can somehow
> enact (TODO: figure how) merging into that branch;
> - committers periodically rebase and marge that branch into `master`
> after a cursory look, with the understanding that it has been
> reviewed and merged by authorized people.
>
> That way, pushes to `master` will be limited to changes that have
> already been validated and built.
>
> XXX: Does it really belong in this document? Should we just keep that
> for later?
>
> - Committers can write to `master` (branch protection rule)
> - Python members can write to `python-team` and `staging`
I do think it's important to discuss this here. Even seemingly minute
details of workflow changes could have more of an impact than one would
expect.
In my case, I'm interested in how this would affect `guix git
authenticate`, as I'm currently in the process of writing a `guix fork`
subcommand to support authenticated forks. With the 'staging branch'
workflow described here, I don't think we'd actually need any changes to
the authentication mechanism or interface. In particular, the 'staging'
branch could still be signed; we could just authorize team members as
well as committers in that branch via .guix-authorizations. It could
even be merged in directly - a committer could add an empty 'sign-off'
commit signed with their key, then merge that into master. Or we could
just do the rebase-and-fast-forward-merge as suggested in the GCD. In
fact that would make more sense; just wanted to give an idea of the
possibilities here.
[...]
There's one more potential consequence of this GCD that I want to bring
up - namely, the eventual stagnation of the discussion mailing lists
(guix-devel and help-guix).
As I discussed above, people will be even more reluctant to communicate
via email once bug-guix and guix-patches are replaced by Codeberg's
issue tracker and pull requests. We will end up in a situation where the
official place for discussion (guix-devel / help-guix) will be
frequented less and less often. This has been observed before, for
example with the Python community:
[6] https://lwn.net/Articles/901744/
There are many possible consequences of this. One is that GCDs like this
one would be seen by fewer people, so there would be less useful
discussion and feedback. And in general, people outside of a small
circle of old contributors already subscribed to the lists will not
participate in, or even be aware of, core community discussions.
I'm not bringing this up because I want to preserve the mailing lists at
all costs; rather, I'm suggesting that we switch away from them as well.
For some of us, this will be just as painful as a switch to a web-based
forge, if not more; but we need to think of the project's future. As for
concrete alternatives, I'd suggest Discourse; though it's also
web-based, it does have a fully-featured API [7], so if enough of us
care about plain-text clients, that can happen :) Also worth noting -
support for threads, apparently [8].
[1] https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00218.html
[2] https://yhetil.org/guix-devel/871pwnc8jt.fsf@inria.fr/t/#u
[3] https://github.com/wkz/notmuch-lore
[4] https://packages.guix.gnu.org/packages/emacs-forge/
[5] https://github.com/magit/forge/commit/0c81b44fb21e95719035a38e81ff088e808318dc
[6] https://lwn.net/Articles/901744/
[7] https://docs.discourse.org/
[8] https://meta.discourse.org/t/introducing-chat-threads/270613
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (6 preceding siblings ...)
2025-01-29 11:24 ` 45mg
@ 2025-01-29 17:34 ` Noé Lopez via Development of GNU Guix and the GNU System distribution.
2025-02-03 21:16 ` Ludovic Courtès
2025-01-29 21:27 ` Liliana Marie Prikler
` (9 subsequent siblings)
17 siblings, 1 reply; 76+ messages in thread
From: Noé Lopez via Development of GNU Guix and the GNU System distribution. @ 2025-01-29 17:34 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Hi Ludovic,
This is great!
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
GCD#0001 says GFDL 1.3 or later, but has « only » in the license
identifier. So this should be GFDL-1.3-no-invariants-or-later. Or maybe
not, I don’t know the legal implications of saying two different things
in the same document. I already sent a mail to Simon to make an
erratum.
On the topic of merging pull-requests, it should still be possible to
apply the commits from git, since you can access them easily:
git fetch -u origin +refs/pull/<id>/head:pull-request
IMO, the staging branch seems like an easy way for a bad patch to make
its way into master, since overlooking a commit would be easier. I
personnaly would like it if the reviewed-looks-good tag would be kept
for non-committers to mark pull requests as « probably ready to merge ».
Have a nice day,
Noé
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (7 preceding siblings ...)
2025-01-29 17:34 ` Noé Lopez via Development of GNU Guix and the GNU System distribution.
@ 2025-01-29 21:27 ` Liliana Marie Prikler
2025-02-03 21:20 ` Ludovic Courtès
2025-01-30 5:22 ` Thanos Apollo
` (8 subsequent siblings)
17 siblings, 1 reply; 76+ messages in thread
From: Liliana Marie Prikler @ 2025-01-29 21:27 UTC (permalink / raw)
To: Ludovic Courtès, Guix Devel
Hi Guix,
I'm in support of having a forge, but not exactly thrilled to structure
my workflow around it(s web interface). IMHO, Forgejo/Codeberg is a
good choice however, so I won't debate that.
Am Dienstag, dem 28.01.2025 um 15:33 +0100 schrieb Ludovic Courtès:
> To keep track of bug reports and patches, Guix historically chose
> tools that were *simple* in their design:
>
> - bug reports and patches can be sent by plain email, without
> having to create an account or even subscribe to a mailing list;
> - discussion and patch review happen naturally by email, without
> requiring special tools;
I think we should still have simple tools at our disposal, even if they
end up talking to Forgejo in the end.
Perhaps instead of
> - Within **30 days** after acceptance of this GCD, mailing list
> administrators will set up the `bug-guix` and `guix-patches`
> mailing
> lists in “Emergency Moderation” mode in the Mailman
> interface—meaning that messages will not get through anymore. It
> will still be possible to interact on individual issues via
> `NNN@debbugs.gnu.org`.
we can make it so that emails to these addresses get forwarded to
Forgejo's bug tracker?
> Since Guix requires signed commits by people listed in
> `.guix-authorizations`, we will *not* be able to click the “Merge”
> button nor to enable auto-merge on build success. This is a security
> feature that we want but it limits scalability as actual merges lays
> on the shoulders of committers. To reduce the load on committers, we
> could use a scheme as follows:
>
> - contributors create pull requests against a `staging` branch
> (TODO:
> check PR templates to force `staging` by default);
> - the `staging` branch is *not* signed and team members can somehow
> enact (TODO: figure how) merging into that branch;
I think we could go harder on the automation through the use of a merge
bot. On a successful build+lint of a pull request, that request would
be merged into staging for a reviewer to look at.
Either way, having a single staging branch might be an issue if
submissions target different branches; e.g. one for python-team, one
for gnome-team. Perhaps "teams" should be given their own
repositories, where they are free to create feature branches as they
like and have their "staging" branch(es) tail a particular branch.
Another idea would be that "staging" keeps the patches themselves as
files in a particular directory (e.g. patches/${bugnumber}), and
committers can apply them by doing something like
$ # git worktree add staging staging
$ git am staging/patches/${bugnumber}/latest/* --signoff
OTOH, whether this is preferable to grabbing the actual issue/PR is
debatable.
> That way, pushes to `master` will be limited to changes that have
> already been validated and built.
Perhaps we should rename 'master' to something else too. Food for
thought for a future GCD :)
Cheers
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (8 preceding siblings ...)
2025-01-29 21:27 ` Liliana Marie Prikler
@ 2025-01-30 5:22 ` Thanos Apollo
2025-01-30 6:48 ` Ricardo Wurmus
2025-01-30 13:13 ` Simon Tournier
` (7 subsequent siblings)
17 siblings, 1 reply; 76+ messages in thread
From: Thanos Apollo @ 2025-01-30 5:22 UTC (permalink / raw)
To: Ludovic Courtès, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]
Hello guix-devel,
I find the email-based workflow used by GNU projects intriguing. While
it may not be as popular as modern web-based systems, it doesn't
inherently constitute a barrier to entry. On the contrary, my
experience attempting to commit to Guix exposed me to this 'exotic'
workflow, and I found that I prefer working directly within Emacs,
avoiding reliance on web-based UIs. I would not have created an account
on Codeberg just to submit a PR.
Moreover, the current workflow exemplifies a "hacker" ethos, valuing
custom tools and minimizing third-party dependencies. This approach was
quite inspiring to witness & actually pushed me to keep using Guix as a
daily driver as well as to use try using guile more often.
Switching to a new system might render the efforts put into tools like
mumi and the wealth of information on issues.guix.gnu.org and mailing
lists less relevant or accessible to newcomers. Perhaps enhancing the
existing tooling could be a more effective strategy than moving to
third-party solutions.
Cheers,
--
Thanos Apollo ☧
https://thanosapollo.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-30 5:22 ` Thanos Apollo
@ 2025-01-30 6:48 ` Ricardo Wurmus
2025-01-30 9:02 ` Ekaitz Zarraga
0 siblings, 1 reply; 76+ messages in thread
From: Ricardo Wurmus @ 2025-01-30 6:48 UTC (permalink / raw)
To: Thanos Apollo; +Cc: Ludovic Courtès, Guix Devel
Thanos Apollo <public@thanosapollo.org> writes:
> Moreover, the current workflow exemplifies a "hacker" ethos, valuing
> custom tools and minimizing third-party dependencies.
I'd just like to note that (the GNU instance of) Debbugs is a third
party dependency, and it is inflexible enough that mumi cannot
effectively work around all its defects or annoyances. Both (this fork
of) Debbugs and Savannah---while operated by dedicated volunteers---are
not in active development, as far as I know. Extending them for our
puproses is not a realistic option.
> Switching to a new system might render the efforts put into tools like
> mumi and the wealth of information on issues.guix.gnu.org and mailing
> lists less relevant or accessible to newcomers.
As the original author of mumi, I don't worry too much about lost
*efforts*. Mumi was an improvement *at the time*, and in the historical
context it remains useful. It still serves us today (thanks primarily
to the work put in by Arun), but it is abundantly clear that it does not
serve us *well enough* to rely on it for the next decade.
I don't see why moving away from debbugs/mumi/issues.guix.gnu.org would
mean that previously accumulated information would be less accessible.
We would likely still work on backlog in debbugs for months to come.
Closing new submissions to the old system does not mean that the archive
would be trashed.
guix-devel also won't disappear.
> Perhaps enhancing the
> existing tooling could be a more effective strategy than moving to
> third-party solutions.
Many people have suggested this (some even demanded it) over
the past years, but very few people have actually successfully
contributed to the tooling for bug tracking and facilitating reviews.
Christopher Baines and Arun Isaac have been the most prolific in that
area, and I'm very interested in their comments on this GCD.
--
Ricardo
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 21:41 ` Tomas Volf
@ 2025-01-30 7:35 ` Andreas Enge
2025-01-31 12:25 ` Giovanni Biscuolo
2025-01-30 21:28 ` Suhail Singh
2025-02-03 17:50 ` Ludovic Courtès
2 siblings, 1 reply; 76+ messages in thread
From: Andreas Enge @ 2025-01-30 7:35 UTC (permalink / raw)
To: Ludovic Courtès, Guix Devel
Hello Tomas,
Am Tue, Jan 28, 2025 at 10:41:40PM +0100 schrieb Tomas Volf:
> From more ideological point of view, I think it is a strict downgrade
> regarding the entry barrier. The very first thing new contributor needs
> to do before contributing to GNU Guix is to read Terms of Service
> document of a third party and agree to it.
> I took the time to read it, and there are few points I have an issue
> with:
definitely a new barrier to entry is the need to create an account.
I just did, and interestingly, at no point in time was I provided with
a checkbox to accept and a link to read the ToS. So now I have an
account without agreeing to anything.
Actually at the bottom of the page there is a link "Terms of Use" under
the heading "Legal". I just went through it and found it amazingly
light, and containing mainly commonplace assertions. In particular, it
does not contain the infamous lines I have seen elsewhere (git*, I
think, but forgot which) that I would indemnify the organisation for any
legal fees that would arise from my actions, or other essentially
unacceptable clauses.
It mainly describes under which circumstances codeberg reserves the
right to close my account; and there is no reason to believe this would
happen following normal work on Guix.
So I am fine sticking to these ToS and do not see them as a big blocker
for contributors.
Nevertheless, we would probably lose bug reports by people who cannot be
bothered to create an account just to help Guix. This could be mitigated
by the continued existence of the help-guix and guix-devel mailing
lists.
Andreas
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-30 6:48 ` Ricardo Wurmus
@ 2025-01-30 9:02 ` Ekaitz Zarraga
2025-02-03 14:47 ` Cayetano Santos
0 siblings, 1 reply; 76+ messages in thread
From: Ekaitz Zarraga @ 2025-01-30 9:02 UTC (permalink / raw)
To: guix-devel, Ricardo Wurmus
Hi,
In general I've been trying to avoid to take part in the conversation
because I basically don't know what to say.
I have a codeberg account that I use with my students, and I also have
github and gitlab accounts. I also have one account in many gitlab
instances of projects I contributed to... I don't like having that many,
but I have no choice.
You don't need an account to contribute to Guix (committers have the
account in your behalf). That's a very good point, and I'd like to keep
that if possible.
Also, I'd prefer some platform that keeps the process similar to what we
currently have. Sr.ht has been proposed before, but it's really hard to
operate and US based if I'm not mistaken. So that leaves us with only
one reasonable option, which is the one that has been proposed.
It's a good proposal. I was unsure if the "noise" that people who wanted
the change was payed attention to a little bit too much, and the survey
also shows that is a minority, but is a large one and I predict that
most of the people don't actually care about the process, but about the
software. I'm in that team.
I don't know if I like the proposed contribution process, but I think it
will be fine. Or at least as good as the current one is.
My main concern was about the sustainability of Codeberg, and that's
being taken in account so: It looks good to me.
On 2025-01-30 07:48, Ricardo Wurmus wrote:
> I'd just like to note that (the GNU instance of) Debbugs is a third
> party dependency, and it is inflexible enough that mumi cannot
> effectively work around all its defects or annoyances. Both (this fork
> of) Debbugs and Savannah---while operated by dedicated volunteers---are
> not in active development, as far as I know. Extending them for our
> puproses is not a realistic option.
About this, Ricardo, you have a great point here. Savannah and Debbugs
are very old and they are not under development. Maybe it's the FSF who
should migrate their infrastructure to some better forge that fits their
needs. Sr.ht fits more with their style, and they have the energy to
operate it. In any case, and thankfully, it's not our goal to fix the FSF.
On the other hand, everything won't be lost in the process! We could
keep some of our tools if we don't mind to rewrite some parts. Forgejo
has an API we can exploit:
https://codeberg.org/api/swagger#/issue
Cheers!
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-29 11:10 ` Ricardo Wurmus
@ 2025-01-30 10:42 ` Divya Ranjan
2025-02-04 12:54 ` Maxim Cournoyer
1 sibling, 0 replies; 76+ messages in thread
From: Divya Ranjan @ 2025-01-30 10:42 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: Ludovic Courtès, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
Hello, Ricardo
Indeed, I trust that over the years you and others must have tried their best.
> Or they *do* Cc the team, but the email drowns in all the other Guix emails and I have no way of listing all patches affecting my field of responsibility, etc.
This I agree with, after being part of teams, I had been looking for such methods. One way is to get patches which mention the branch name (Rust Team, Emacs Team etc.) but maybe we should have also another tag in the subject every time it's directed to a team? Akin to labels in a web-based setup.
Also, since you and others have had such experience with these tools, I'd like some suggestions from you and everyone else on what Savannah and FSF can do to have the workflow smoother. I believe the "learning curve" issue is irrelevant to this, but mostly infrastructure wise, what can be improved/repaired/maintained better?
I ask this because I'm slowly taking responsibilities at FSFSysOps and Savannah. I communicated with the FSFSysOps team last night, and they're open to working on improvements. While of course, I'm not suggesting Guix to rely on this or wait for it, I'm simply asking what we can learn from this to go forward in having other GNU projects to be better.
Thank you.
Regards,
Divya Ranjan
Divya Ranjan, Mathematics, Philosophy and Libre Software
[-- Attachment #2: Type: text/html, Size: 1471 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (9 preceding siblings ...)
2025-01-30 5:22 ` Thanos Apollo
@ 2025-01-30 13:13 ` Simon Tournier
2025-02-03 21:32 ` Ludovic Courtès
2025-01-30 16:56 ` Christopher Baines
` (6 subsequent siblings)
17 siblings, 1 reply; 76+ messages in thread
From: Simon Tournier @ 2025-01-30 13:13 UTC (permalink / raw)
To: Ludovic Courtès, Guix Devel
Hi,
First, since we bounded the various periods, could you be clear about
them? Because, you already found two “sponsors” and the GCD has not
been sent to info-guix, if I read correctly.
In order to stay focused, I skip the minor comments I have and directly
jump to the major one. :-)
On Tue, 28 Jan 2025 at 15:33, Ludovic Courtès <ludo@gnu.org> wrote:
> # Drawbacks and Open Issues
I would add two roadblocks (at least for me):
1. Not being able to process offline.
2. Not being able to comment patches directly from the editor of my own
choice.
To say it explicitly, for now it’s two main concerns for me. For sure I
agree and share many (if not all!) motivations behind this GCD, but
still, I’ve not solved yet the dilemma: collaborate to a Free Software
project promoting user autonomy and freedom and also accept to be locked
via only one front-end requiring continuous Internet connection and
modern web-browser.
It’s not only about my own choice of using Emacs*. ;-) My main concern
is a kind of dogfooding applied to the principles and values we promote.
Again, I support all the efforts in order to reduce the barrier. Yes,
make the process “easier” (more familiar), i.e., having a workflow more
“friendly” is clearly one principle and value the project cares too.
The question is to find the right balance. There is a trade-off between
what we accept and what we don’t. For instance, moving from the
Translation Project and its stringent Robot to the Weblate instance
falls in this kind of choice. Do not take me wrong about this move: it
was a good one.
All in all, I do not have yet a definitive opinion on the GCD and I
think we need to include (at least) a paragraph about this “dilemma“ /
trade-off / balance. WDYT?
Cheers,
simon
*about working with Emacs: Independently of this GCD, I’ve started to
scratch the itch [1]. That’s why I’m still hesitating. And I’ve not
yet given a look to magit-forge and something like it.
1: https://codeberg.org/martianh/fj.el/pulls/79
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (10 preceding siblings ...)
2025-01-30 13:13 ` Simon Tournier
@ 2025-01-30 16:56 ` Christopher Baines
2025-02-03 21:38 ` Ludovic Courtès
2025-01-30 21:48 ` Suhail Singh
` (5 subsequent siblings)
17 siblings, 1 reply; 76+ messages in thread
From: Christopher Baines @ 2025-01-30 16:56 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel
[-- Attachment #1: Type: text/plain, Size: 5122 bytes --]
Ludovic Courtès <ludo@gnu.org> writes:
> Anyway, the proposal is about migrating repositories, issues, and
> patches to Codeberg. You’ll find the rationale, plan, and open issues
> in the attached draft. I already found two “sponsors” for the proposal
> (meaning they agree with the general direction and are willing to
> participate in discussions) but if anyone else would like to sponsor it,
> I’m happy to add them.
>
> Feedback welcome!
>
> Ludo’.
>
> title: Migrating repositories, issues, and patches to Codeberg
> id: 002
> status: draft
> discussion: https://issues.guix.gnu.org/<number assigned by issue tracker>
> authors: Ludovic Courtès
> sponsors: Tobias Geerinckx-Rice, Ricardo Wurmus
> date-submitted: <date when you send the first draft>
> date: <date when the discussion period starts>
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
> ---
...
> ## Continuous Integration
>
> Forgejo supports
> [*webhooks*](https://forgejo.org/docs/latest/user/webhooks/), `POST`
> requests that are sent to the server of one’s choice upon events such as
> pull request creation. Cuirass (running at ci.guix.gnu.org) already
> [supports](https://hpc.guix.info/blog/2025/01/join-the-guix-science-community/)
> them and automatically creates a *jobset* when a pull request is made.
> The [QA frontpage](https://qa.guix.gnu.org) and its [Data
> Service](https://data.qa.guix.gnu.org) does not support Forgejo webhooks
> yet but can be extended to do so without too much effort, possibly
> sharing or reusing the Forgejo interface code from Cuirass.
>
> In the Guix repository, we will set up webhooks to trigger the creation
> of a new jobset at ci.guix.gnu.org (Cuirass) as soon as migration is
> complete. While this has been successfully used for several months for
> [Guix-Science](https://codeberg.org/guix-science), scalability will be
> the major concern here; additional developments may be needed to
> consolidate this support. Eventually the QA frontpage will also support
> those webhooks.
>
> We will arrange so that the build status of a pull request is clearly
> visible right from that pull request.
>
> Eventually, the QA service or a [Forgejo
> *action*](https://forgejo.org/docs/latest/user/actions/) may
> automatically provide feedback from `guix lint` as a reply to pull
> requests.
I think this section would either be better changed to a commitment to
setup particular things, or a shorter statement that "Continuous
Integration" at least shouldn't be any harder.
I'm not sure about the argument that "Continuous Integration" would be
easier on Forgejo/Codeberg, since I think the main problems we're having
in this area wouldn't be helped by this proposal.
> ## Workflow
>
> Once continuous integration (CI) is fully operational, pull requests may
> be merged if and only if they successfully built. “World-rebuild” pull
> requests would still follow the [existing branching
> process](https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html).
Given this proposal isn't to get "continuous integration" to be fully
operational, I don't think this paragraph is really relevant.
> To help scale better, we will look for ways to empower team members who
> are not members of the “Committers” team such that they can trigger a
> merge even though they do not have commit access. This probably
> involves a bot (TODO: think through it).
Also on the subject that we don't have automated testing for changes, I
think this is also too vauge to be useful.
> Since Guix requires signed commits by people listed in
> `.guix-authorizations`, we will *not* be able to click the “Merge”
> button nor to enable auto-merge on build success. This is a security
> feature that we want but it limits scalability as actual merges lays on
> the shoulders of committers. To reduce the load on committers, we could
> use a scheme as follows:
>
> - contributors create pull requests against a `staging` branch (TODO:
> check PR templates to force `staging` by default);
> - the `staging` branch is *not* signed and team members can somehow
> enact (TODO: figure how) merging into that branch;
> - committers periodically rebase and marge that branch into `master`
> after a cursory look, with the understanding that it has been
> reviewed and merged by authorized people.
>
> That way, pushes to `master` will be limited to changes that have
> already been validated and built.
>
> XXX: Does it really belong in this document? Should we just keep that
> for later?
Personally I think the most safe workflow is to turn off the merge
feature (which seems possible), then committers push things as usual.
> - Committers can write to `master` (branch protection rule)
> - Python members can write to `python-team` and `staging`
I think this is proposing commit access for branches for team members,
which might not be committers. Given that seems unnecessary I'd remove
it from this proposal.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 21:41 ` Tomas Volf
2025-01-30 7:35 ` Andreas Enge
@ 2025-01-30 21:28 ` Suhail Singh
2025-02-03 17:50 ` Ludovic Courtès
2 siblings, 0 replies; 76+ messages in thread
From: Suhail Singh @ 2025-01-30 21:28 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel
Tomas Volf <~@wolfsden.cz> writes:
> The README recommend to just "set fj-token", I *hope* it can be
> integrated with (auth)Top somehow. So I definitely have some research
> to do here.
The best I came up with was this:
#+begin_src elisp
((nil . ((eval . (setq fj-token
(funcall
(plist-get
(car
(auth-source-search :host "codeberg.org/api/v1"
:type 'netrc))
:secret)))))))
#+end_src
Tomas, if you find something better, please share.
--
Suhail
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (11 preceding siblings ...)
2025-01-30 16:56 ` Christopher Baines
@ 2025-01-30 21:48 ` Suhail Singh
2025-01-31 15:10 ` Suhail Singh
[not found] ` <87frkzhvb8.fsf@housseini.me>
` (4 subsequent siblings)
17 siblings, 1 reply; 76+ messages in thread
From: Suhail Singh @ 2025-01-30 21:48 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel
Ludovic Courtès <ludo@gnu.org> writes:
> ## Workflow
While this section talks in some detail about CI and the merge workflow,
it leaves unstated what the actual review process would look like (and
what demands it may or may not make of the reviewers). Could you please
elaborate on that?
--
Suhail
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-30 7:35 ` Andreas Enge
@ 2025-01-31 12:25 ` Giovanni Biscuolo
2025-01-31 13:27 ` Ekaitz Zarraga
0 siblings, 1 reply; 76+ messages in thread
From: Giovanni Biscuolo @ 2025-01-31 12:25 UTC (permalink / raw)
To: Guix Devel
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
Andreas Enge <andreas@enge.fr> writes:
[...]
> Nevertheless, we would probably lose bug reports by people who cannot be
> bothered to create an account just to help Guix.
I seldom send bug reports but I will not create any account just to send
one (if having an account is the only way to send bug reports via
codeberg.org)
> This could be mitigated by the continued existence of the help-guix
> and guix-devel mailing lists.
I don't think so: who would open issues on behalf of other users sending
emails to that mailing lists?
[...]
Happy hacking, Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-31 12:25 ` Giovanni Biscuolo
@ 2025-01-31 13:27 ` Ekaitz Zarraga
2025-01-31 19:37 ` Cayetano Santos
0 siblings, 1 reply; 76+ messages in thread
From: Ekaitz Zarraga @ 2025-01-31 13:27 UTC (permalink / raw)
To: Giovanni Biscuolo, Guix Devel
On 2025-01-31 13:25, Giovanni Biscuolo wrote:
> I don't think so: who would open issues on behalf of other users sending
> emails to that mailing lists?
We could make a bot that gets email bugs from bug-guix and files them to
codeberg. Codeberg has an API that supports issue creation.
That shouldn't be the blocker for this GCD.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-30 21:48 ` Suhail Singh
@ 2025-01-31 15:10 ` Suhail Singh
2025-01-31 16:37 ` Attila Lendvai
2025-02-03 21:47 ` Ludovic Courtès
0 siblings, 2 replies; 76+ messages in thread
From: Suhail Singh @ 2025-01-31 15:10 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Suhail Singh, Guix Devel
Suhail Singh <suhailsingh247@gmail.com> writes:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> ## Workflow
>
> While this section talks in some detail about CI and the merge workflow,
> it leaves unstated what the actual review process would look like (and
> what demands it may or may not make of the reviewers). Could you please
> elaborate on that?
I gave it some more thought, and I think there is a concern that the
proposal fails to address (unless I missed it, in which case my
apologies for the noise). IMO this concern ought to be discussed for
individuals to have an informed opinion in favor or against.
Presently, we are faced with a situation where the throughput of patch
submissions is greater than the throughput of the combination of
reviewing and committing patches. Further, between reviewing and
committing patches, it's the throughput of committing patches that is
the rate limiting step (as evidenced by the, not uncommon, long delay
between the review by a non-committer, and the merge of said patch by a
committer).
The move to codeberg has the potential to alleviate the rate limiting
step (the throughput of committing patches). This has been discussed.
However, said move also has the potential to reduce the throughput of
reviews. It's not clear that the number of Guix contributors who
contribute by participating in the review process won't find the web
interface less convenient. And that this effect won't be greater than
the positive effect of attracting more reviewers. Finally, it's
possible that the reduction in throughput is so great that it offsets
any gains in commit throughput.
I think that this is a factor that warrants some discussion. And since
nobody has a crystal ball, it would be prudent to outline what the
mitigation strategy is if the above were to be true. I.e., say we move
to codeberg, and we find out reviews have dried up, what's the plan to
deal with that possibility? Somewhat relatedly, is there a world where
email-based reviews (and to a lesser extent, patch submission) could
co-exist with a forge?
--
Suhail
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
[not found] ` <87frkzhvb8.fsf@housseini.me>
@ 2025-01-31 15:12 ` reza
2025-01-31 20:43 ` Tomas Volf
0 siblings, 1 reply; 76+ messages in thread
From: reza @ 2025-01-31 15:12 UTC (permalink / raw)
To: Ludovic Courtès, Guix Devel
Hello Guix!
I am also in favor of this GCD. It may not directly address the most
urgent pain points mentioned in the survey but I see the proposal as a
means to liberate contributor time. The tooling needed to drive a
project like guix is in my opinion not part of the core promises of
guix. Investing in such tooling by contributors already busy with a lot
of other stuff will normally result in subpar results and frustration on
both the developer and user side. The guix community as a whole should
draw clear boundaries of what should be developed by the guix community
and what is outside of the scope of the project. I am generally in favor
of reducing the scope to streghten the core and only widen it when there
is clearly a need and resources available.
The arguments regarding the account creation on codberg.org are in my
opinion a little polemic. To access the email lists on savannah you
provide an email address and a password, to create an account on
codeberg you provide exactly the same information. It boils down to your
individual trust in the organization providing the service.
Best,
Reza
> I’m anticipating on the acceptance (hopefully) of the Guix Consensus
> Document (GCD) process:
>
> https://issues.guix.gnu.org/74736
>
> (Speaking of which, if you’re member of a team as per ‘etc/teams.scm’
> and haven’t replied yet as part of the deliberation period, now is the
> time to do it!)
>
> I believe this GCD can only be in “submitted” state if and after the GCD
> process is accepted, which would be on February 5th. That doesn’t
> prevent us from having preliminary discussions, including in Brussels
> for those of us attending the Guix Days.
>
> Anyway, the proposal is about migrating repositories, issues, and
> patches to Codeberg. You’ll find the rationale, plan, and open issues
> in the attached draft. I already found two “sponsors” for the proposal
> (meaning they agree with the general direction and are willing to
> participate in discussions) but if anyone else would like to sponsor it,
> I’m happy to add them.
>
> Feedback welcome!
>
> Ludo’.
>
> title: Migrating repositories, issues, and patches to Codeberg
> id: 002
> status: draft
> discussion: https://issues.guix.gnu.org/<number assigned by issue tracker>
> authors: Ludovic Courtès
> sponsors: Tobias Geerinckx-Rice, Ricardo Wurmus
> date-submitted: <date when you send the first draft>
> date: <date when the discussion period starts>
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
> ---
>
> # Summary
>
> 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. All these lead
> to an experience that contributors often find frustrating and hinders
> quality assurance efforts. We propose to address these limitations by
> migrating repositories, issue tracking, and patch tracking to Codeberg,
> a “modern” forge hosted by a non-profit.
>
> # Motivation
>
> To keep track of bug reports and patches, Guix historically chose tools
> that were *simple* in their design:
>
> - bug reports and patches can be sent by plain email, without having
> to create an account or even subscribe to a mailing list;
> - discussion and patch review happen naturally by email, without
> requiring special tools;
> - the Debbugs instance at https://bugs.gnu.org keeps track of bug
> reports and patches by assigning them an identifier and creating a
> mailing list specifically for each bug or patch.
>
> However, to overcome several limitations, the project developed
> processes and tools, which can be characterized as *incidental
> complexity*:
>
> - because the Debbugs web interface is crude by today’s standards and
> hard to search and navigate, the project developed
> [mumi](https://git.savannah.gnu.org/cgit/guix/mumi.git/), the web
> interface running at https://issues.guix.gnu.org;
> - to navigate bugs and patches more conveniently than what an email
> client supports, contributors were
> [encouraged](https://guix.gnu.org/manual/devel/en/html_node/Debbugs-User-Interfaces.html)
> to use interfaces like `debbugs.el` or `b4`;
> - sending patch series by email does not play well with Debbugs’
> automatic identifier assignment, so [contributors were told to send
> their “cover letter”, wait for an identifier to be assigned, and
> then send the
> rest](https://guix.gnu.org/manual/devel/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches-1);
> - to help sending and applying patch series, mumi was extended to
> provide a command line interface;
> - to build patch series submitted by email, the [QA
> service](https://qa.guix.gnu.org) has to rely on a [Patchwork
> instance](https://patches.guix-patches.cbaines.net/project/guix-patches/list/)
> that is subscribed to the `guix-patches` mailing list, coupled with
> its own [parsing of incoming
> email](https://git.savannah.gnu.org/gitweb/?p=guix/data-service.git;a=blob;f=guix-data-service/branch-updated-emails.scm;h=aeb1570dfda725864a77780d0541f26c090b0e55;hb=c886685e9284da4bbed9377f70dd70da9e7ca29f);
> - the project added a commit hook to create add unique `Change-Id`
> headers in commit messages in an attempt to correlate commits in the
> repository with messages send to `guix-patches`; none of the
> existing tools takes advantage of it though, and it is up to
> contributors to manually close entries in the bug/patch tracker once
> they have been fixed/applied.
>
> Developing and maintaining this software and infrastructure is
> time-consuming. Worse, it leaves contributors largely dissatisfied for
> a variety of reasons:
>
> - the process is unfamiliar to most newcomers;
> - the tools and infrastructure in Guix have become a maze;
> - apart from the happy few using `debbugs.el` in Emacs, navigating
> open issues and patches is hard; filtering incoming messages is
> equally hard, even for those with 10+ years of experience with
> advanced email tools (Gnus, mu4e, notmuch, b4, etc.);
> - because the various parts of the development process (repository,
> issue tracking, QA automation, `etc/teams.scm`) are largely
> disconnected, even long-time contributors can hardly follow issues
> relevant to them; issues may remain open after they’ve been fixed,
> new activity on an issue may go unnoticed, cross-references among
> issues are not visible in any of the interfaces, etc.
>
> All this contributes to a [poor
> experience](https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-3/)
> for those who choose to contribute despite the barrier to entry,
> probably discourages many to even start contributing, and adds to the
> load of committers and infrastructure maintainers.
>
> # Detailed Design
>
> This section explains the chosen solution among the available options,
> the scope of the proposed migration, a migration path, and an outlook on
> automation.
>
> ## Choice of a Forge
>
> We set out to choose a “modern forge” that supports a pull-request style
> workflow and provides good integration between the repository, the issue
> tracker, and the merge request tracker. The software behind the forge
> has to be free software that is *plausibly* self-hosted on Guix
> System—this probably rules out GitLab Community Edition and makes
> [Forgejo](https://forgejo.org/) the main contender.
>
> [Sourcehut](https://sourcehut.org/), the other interesting option, does
> not offer the same convenience when it comes to dealing with patches and
> runs the risk of reproducing onboarding and integration issues
> surrounding an email-based workflow and “read-only” web interface that
> Guix is already experiencing.
>
> Forgejo has several features to support collaboration among a large
> number of people and on a large code base, including
> [teams](https://docs.codeberg.org/collaborating/create-organization/#teams)
> and [issue and pull request
> templates](https://forgejo.org/docs/latest/user/issue-pull-request-templates/)
> Support for
> [federation](https://forgejo.org/2023-01-10-answering-forgejo-federation-questions/)
> is also under development and is a promising way to avoid
> centralization.
>
> Instead of self-hosting, this GCD suggests using the Forgejo instance on
> codeberg.org, run by the [Codeberg e.V.](https://codeberg.org/about)
> non-profit, registered in Germany. The non-profit has a good track
> record of running codeberg.org with minimal downtime, is [committed to
> supporting free software
> development](https://codeberg.org/Codeberg/org/src/branch/main/en/bylaws.md#preamble),
> [transparent](https://codeberg.org/Codeberg/org), and has governance set
> up to achieve its mission.
>
> The Guix-Science umbrella project [has been using Codeberg for several
> months
> now](https://hpc.guix.info/blog/2025/01/join-the-guix-science-community/),
> which has allowed us to gain confidence in its suitability for a project
> like Guix.
>
> ## Rights and Privileges
>
> Migration should preserve rights and privileges regarding access to the
> repositories. To that end, we propose the following rules:
>
> - Committers to several of the repositories listed above and [Savannah
> “group admins”](https://savannah.gnu.org/projects/guix) can request
> membership in the [“Owners”
> team](https://docs.codeberg.org/collaborating/create-organization/#teams)
> of the [Guix *organization*](https://codeberg.org/guix). As of this
> writing, only three people are members.
> - Anyone listed the `.guix-authorizations` file of Guix can request
> membership of the https://codeberg.org/guix/guix once it is created.
> - Committers to one of the other repositories can request membership
> of that repository.
>
> In the future, we should extend the [“Commit
> Rights”](https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html)
> section of the manual to clarify the distinction between being a member
> of the organization and being a member of a specific repository, in a
> specific team.
>
> ## Repository Migration Path
>
> The Guix project at Savannah contains the following repositories:
>
> - [Guix itself](https://git.savannah.gnu.org/git/guix.git);
> - [the bootstrappable.org web
> site](https://git.savannah.gnu.org/git/guix/bootstrappable.git);
> - [the DHCP client in
> Guile](https://git.savannah.gnu.org/git/guix/dhcp.git) (forgotten
> 2015 Google Summer of Code project);
> - [Guile bindings to
> GNUnet](https://git.savannah.gnu.org/git/guix/gnunet.git) (forgotten
> 2015 Google Summer of Code project);
> - [Guix artwork and web
> site](https://git.savannah.gnu.org/git/guix/guix-artwork.git);
> - [Cuirass](https://git.savannah.gnu.org/git/guix/guix-cuirass.git);
> - [“maintenance”
> repository](https://git.savannah.gnu.org/git/guix/maintenance.git)
> (includes Guix System infrastructure configuration, talks, and other
> documents);
> - [scripts for videos presenting
> Guix](https://git.savannah.gnu.org/git/guix/videos.git);
> - [Guix Data
> Service](https://git.savannah.gnu.org/git/guix/data-service.git);
> - [Emacs-Guix](https://git.savannah.gnu.org/git/guix/emacs-guix.git);
> - [Guix Build
> Coordinator](https://git.savannah.gnu.org/git/guix/build-coordinator.git);
> - [nar-herder](https://git.savannah.gnu.org/git/guix/nar-herder.git);
> - [QA
> Frontpage](https://git.savannah.gnu.org/git/guix/qa-frontpage.git);
> - [mumi](https://git.savannah.gnu.org/cgit/guix/mumi.git);
> - [Guix Consensus
> Documents](https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git).
>
> Within **30 days** following acceptance of this GCD, committers would
> migrate all these repositories.
>
> 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. A commit would reflect that by
> updating:
>
> 1. the `url` field in `.guix-channel`;
> 2. the `%default-channel-url` variable in `(guix channels)`;
> 3. any other reference to the URL that may appear in the repository.
>
> Following this commit, an entry in `etc/news.scm` would explain the
> migration. See [this entry in
> Guix-Science](https://codeberg.org/guix-science/guix-science/commit/fd1b2dacd8d37c9d1939f9dc5a5b74256171ccbd)
> for an example.
>
> The Savannah `guix.git` repository would become a mirror of the one at
> Codeberg, with a script periodically updating it, as a way to ease
> migration to the new repository for users.
>
> ## Issue Tracker Migration Path
>
> Importing all the issues and patches from Debbugs/mumi into Codeberg
> would be impractical: it would require the development of specific
> tools, would be a lossy process due to the fundamental mismatch between
> plain text email threads and Forgejo issues and pull requests, and would
> bring little in return.
>
> Our proposal is the following:
>
> - https://issues.guix.gnu.org will remain up and running for at least
> **two years** following acceptance of this GCD. Note that once
> issues.guix.gnu.org is down, issues will remain visible at
> https://bugs.gnu.org and email archives will remain visible at
> https://mail.gnu.org.
> - Within **30 days** after acceptance of this GCD, mailing list
> administrators will set up the `bug-guix` and `guix-patches` mailing
> lists in “Emergency Moderation” mode in the Mailman
> interface—meaning that messages will not get through anymore. It
> will still be possible to interact on individual issues via
> `NNN@debbugs.gnu.org`.
> - The switchover will be advertised before it takes place with a post
> to `info-guix@gnu.org`, to `guix-devel@gnu.org`, as well as through
> a blog post.
> - The “Contributing” section of the manual will be updated accordingly
> at that time.
>
> Care will be taken to advertise the various interfaces to
> Codeberg/Forgejo that exist in addition to its web interface, such as
> [forgejo-cli](https://codeberg.org/Cyborus/forgejo-cli/) and
> [fj.el](https://codeberg.org/martianh/fj.el/).
>
> ## Teams
>
> All the teams currently defined in `etc/teams.scm` will be reified as
> [teams](https://docs.codeberg.org/collaborating/create-organization/#teams)
> in the [Guix organization](https://codeberg.org/guix).
>
> All these teams would have read-only access to the repositories, with
> the exception of a new *Committers* team, with read-write access to the
> repository, which would contain all the people who already have [commit
> rights on
> Savannah](https://savannah.gnu.org/project/memberlist.php?group=guix)
> (“on-duty members”).
>
> Team scopes in `etc/teams.scm` will be converted to a `CODEOWNERS` file
> similar to [that found in
> Guix-Science](https://codeberg.org/guix-science/guix-science/src/branch/master/CODEOWNERS).
> That way, pull requests will automatically have them suggested as
> reviewers for changes in their scope.
>
> ## Continuous Integration
>
> Forgejo supports
> [*webhooks*](https://forgejo.org/docs/latest/user/webhooks/), `POST`
> requests that are sent to the server of one’s choice upon events such as
> pull request creation. Cuirass (running at ci.guix.gnu.org) already
> [supports](https://hpc.guix.info/blog/2025/01/join-the-guix-science-community/)
> them and automatically creates a *jobset* when a pull request is made.
> The [QA frontpage](https://qa.guix.gnu.org) and its [Data
> Service](https://data.qa.guix.gnu.org) does not support Forgejo webhooks
> yet but can be extended to do so without too much effort, possibly
> sharing or reusing the Forgejo interface code from Cuirass.
>
> In the Guix repository, we will set up webhooks to trigger the creation
> of a new jobset at ci.guix.gnu.org (Cuirass) as soon as migration is
> complete. While this has been successfully used for several months for
> [Guix-Science](https://codeberg.org/guix-science), scalability will be
> the major concern here; additional developments may be needed to
> consolidate this support. Eventually the QA frontpage will also support
> those webhooks.
>
> We will arrange so that the build status of a pull request is clearly
> visible right from that pull request.
>
> Eventually, the QA service or a [Forgejo
> *action*](https://forgejo.org/docs/latest/user/actions/) may
> automatically provide feedback from `guix lint` as a reply to pull
> requests.
>
> ## Workflow
>
> Once continuous integration (CI) is fully operational, pull requests may
> be merged if and only if they successfully built. “World-rebuild” pull
> requests would still follow the [existing branching
> process](https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html).
>
> To help scale better, we will look for ways to empower team members who
> are not members of the “Committers” team such that they can trigger a
> merge even though they do not have commit access. This probably
> involves a bot (TODO: think through it).
>
> Since Guix requires signed commits by people listed in
> `.guix-authorizations`, we will *not* be able to click the “Merge”
> button nor to enable auto-merge on build success. This is a security
> feature that we want but it limits scalability as actual merges lays on
> the shoulders of committers. To reduce the load on committers, we could
> use a scheme as follows:
>
> - contributors create pull requests against a `staging` branch (TODO:
> check PR templates to force `staging` by default);
> - the `staging` branch is *not* signed and team members can somehow
> enact (TODO: figure how) merging into that branch;
> - committers periodically rebase and marge that branch into `master`
> after a cursory look, with the understanding that it has been
> reviewed and merged by authorized people.
>
> That way, pushes to `master` will be limited to changes that have
> already been validated and built.
>
> XXX: Does it really belong in this document? Should we just keep that
> for later?
>
> - Committers can write to `master` (branch protection rule)
> - Python members can write to `python-team` and `staging`
>
> ## Translation
>
> We may eventually consider migrating translation work from [Fedora’s
> Weblate](https://translate.fedoraproject.org/projects/guix/) to
> [Codeberg’s](https://docs.codeberg.org/codeberg-translate/), as a way to
> make it more discoverable and better integrated.
>
> # Cost of Reverting
>
> While the project *could* migrate back from Codeberg to bugs.gnu.org
> (Debbugs), migrating issues and pull requests from Codeberg to Debbugs
> would be practically infeasible. It is unlikely that anyone would want
> this.
>
> A more interesting question is: what would it take to migrate to a
> different Forgejo instance or to a different forge?
>
> Migrating to a different Forgejo instance would be rather simple since
> Forgejo is able to *import* entire repositories with their settings
> (including teams) and issues and pull requests from other instances.
> Users would have to create accounts on the new forge instance though.
> However, if federation support matures in Forgejo, one may be able to
> operate on a repository from distinct but *federated* instances. That
> would make any move much easier.
>
> Forgejo appears to support
> [“mirroring”](https://forgejo.org/docs/latest/user/repo-mirror/) to
> GitLab instances, for instance, which could help migrating to a GitLab
> instance. Migrating to a sourcehut instance would probably be more
> difficult because of the feature mismatch.
>
> Note that Forgejo offers a [rich HTTP
> interface](https://forgejo.org/docs/latest/user/api-usage/) that
> essentially allows users to get the raw data behind issues, pull
> requests, and more, meaning that it is theoretically always possible to
> grab the data.
>
> # Drawbacks and Open Issues
>
> Leaving it up to an external organization to manage critical
> infrastructure of our project comes with risks.
>
> Codeberg e.V., the non-profit that runs Codeberg, could always go
> bankrupt, suffer from governance issues, or run into problems that any
> non-profits face and which could lead to service discontinuation. This
> could be mitigated by weaving close ties with Codeberg e.V., for
> instance by financially supporting it or by setting a joint team to
> monitor resource consumption induced by Guix and discuss any issues
> encountered by either parties proactively.
>
> The self-hosting option has its appeal for a project with the size and
> values of Guix—it is not uncommon for similar projects to do that, an
> example being the [Lix project](https://git.lix.systems/); there even
> exists a [preliminary Forgejo service for
> Guix](https://git.boiledscript.com/hako/Rosenthal/src/commit/7a6a28e872b3168f9b6513ccf797e247cd8a366d/rosenthal/services/web.scm#L32).
> However the author thinks that, as it stands, Guix system administrators
> have more than enough on their plate and are perhaps not up to the task
> of providing the availability guarantees we expect from such a service.
>
> As of this writing, Forgejo integration in Cuirass is functional but
> partial (useful configuration options and hardening mechanisms are
> missing) and missing from QA-Frontpage. This will have to be addressed
> to fully take advantage of the new pull-request workflow.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-31 15:10 ` Suhail Singh
@ 2025-01-31 16:37 ` Attila Lendvai
2025-01-31 18:09 ` Suhail Singh
2025-02-03 21:47 ` Ludovic Courtès
1 sibling, 1 reply; 76+ messages in thread
From: Attila Lendvai @ 2025-01-31 16:37 UTC (permalink / raw)
To: Suhail Singh; +Cc: Ludovic Courtès, Guix Devel
> However, said move also has the potential to reduce the throughput of
> reviews. It's not clear that the number of Guix contributors who
do you think there's a substantial number of reviews done by people who don't have the commit bit? and that their review is a substantial help for the patch throughput?
i don't really have data on this, but my (moderately informed) impression is that it's not really a relevant amount.
and as for the efficiency of the new workflow: i think it strictly depends on how easy it is to script the new infrastructure. and if the new infra has more structured/formal ways to store/access the data than debbugs and mailing lists, then i'm pretty sure it can only make scripting easier. then scripts and emacs based tools could serve the power users, while the web UI could serve the occasional contributors.
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“I sincerely believe that banking establishments are more dangerous than standing armies, and that the principle of spending money to be paid by posterity, under the name of funding, is but swindling futurity on a large scale.”
— Thomas Jefferson (1743–1826)
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-31 16:37 ` Attila Lendvai
@ 2025-01-31 18:09 ` Suhail Singh
2025-01-31 18:43 ` Attila Lendvai
0 siblings, 1 reply; 76+ messages in thread
From: Suhail Singh @ 2025-01-31 18:09 UTC (permalink / raw)
To: Attila Lendvai; +Cc: Suhail Singh, Ludovic Courtès, Guix Devel
Attila Lendvai <attila@lendvai.name> writes:
> do you think there's a substantial number of reviews done by people
> who don't have the commit bit? and that their review is a substantial
> help for the patch throughput?
My point is precisely that I do not know definitively what is the case.
And as such, it needs _some_ consideration in the proposal.
> i don't really have data on this, but my (moderately informed)
> impression is that it's not really a relevant amount.
Perhaps so. I don't have an informed view, merely an anecdotal one.
I.e., I simply know that it's a possibility (given that I have done some
non-trivial, and I hope helpful, reviews without commit access, and a
thing that facilitated that was the ease of responding to patch emails).
Evidence and reasoning considering this factor, or explaining why this
factor is a non-issue would be a valuable addition to the proposal.
> and as for the efficiency of the new workflow: i think it strictly depends on
> how easy it is to script the new infrastructure. and if the new infra has more
> structured/formal ways to store/access the data than debbugs and mailing lists,
> then i'm pretty sure it can only make scripting easier. then scripts and emacs
> based tools could serve the power users, while the web UI could serve the
> occasional contributors.
Could you share some examples of the types of "scripting" you mean
above? Specifically, if there are examples of scripting that you
believe would allow for an Emacs-based review workflow, please share.
--
Suhail
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-31 18:09 ` Suhail Singh
@ 2025-01-31 18:43 ` Attila Lendvai
2025-01-31 19:46 ` Suhail Singh
0 siblings, 1 reply; 76+ messages in thread
From: Attila Lendvai @ 2025-01-31 18:43 UTC (permalink / raw)
To: Suhail Singh; +Cc: Ludovic Courtès, Guix Devel
> > and as for the efficiency of the new workflow: i think it strictly depends on
> > how easy it is to script the new infrastructure. and if the new infra has more
> > structured/formal ways to store/access the data than debbugs and mailing lists,
> > then i'm pretty sure it can only make scripting easier. then scripts and emacs
> > based tools could serve the power users, while the web UI could serve the
> > occasional contributors.
>
>
> Could you share some examples of the types of "scripting" you mean
> above? Specifically, if there are examples of scripting that you
> believe would allow for an Emacs-based review workflow, please share.
i didn't think of anything specific, but here are a few things that pop to my mind:
- list view of PR search result in eamcs
- shortcut to checkout, or create a git workspace with a PR applied (optionally on top of a selected git head)
- writing comments on a PR or issue in emacs
- opening a PR from a given git state
- a script that closes an issue when a commit contains the magic words
IOW, the usual stuff just not from the browser, but from the shell or from emacs.
what i wanted to point out is that it's not a lot of effort to automate on the client side -- either using guile scripts, or with some code in emacs --, *if* the infra has a sane API. and i assume that that is the case with codeberg in 2025.
it shouldn't take a lot of effort to write some thin emacs code that displays the codeberg data in an emacs buffer.
making it work offline and sync later is probably substantially more work, but it should still not be an insurmountable task.
and nothing of that would be guix specific! these are probably already being worked on somewhere (i.e. division of labor):
https://codeberg.org/forgejo-contrib/delightful-forgejo#clients
(A curated list of delightful Forgejo-related projects and resources.)
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Foolishness is rarely a matter of lack of intelligence or even lack of information.”
— John McCarthy (1927–2011), father of Lisp
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-31 13:27 ` Ekaitz Zarraga
@ 2025-01-31 19:37 ` Cayetano Santos
0 siblings, 0 replies; 76+ messages in thread
From: Cayetano Santos @ 2025-01-31 19:37 UTC (permalink / raw)
To: Ekaitz Zarraga; +Cc: Giovanni Biscuolo, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
>ven. 31 janv. 2025 at 14:27, Ekaitz Zarraga <ekaitz@elenq.tech> wrote:
> On 2025-01-31 13:25, Giovanni Biscuolo wrote:
>> I don't think so: who would open issues on behalf of other users sending
>> emails to that mailing lists?
>
> We could make a bot that gets email bugs from bug-guix and files them to codeberg.
> Codeberg has an API that supports issue creation.
> That shouldn't be the blocker for this GCD.
This is the whole point about this GCD: delegating on a maintained
framework, leveraging efforts from developers, and the promise of new
tooling, as we consider current one as insufficient.
Which brings the question about the new tooling (see previous mumi
related exchange).
--
Cayetano Santos
GnuPG Key: https://meta.sr.ht/~csantosb.pgp
FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-31 18:43 ` Attila Lendvai
@ 2025-01-31 19:46 ` Suhail Singh
0 siblings, 0 replies; 76+ messages in thread
From: Suhail Singh @ 2025-01-31 19:46 UTC (permalink / raw)
To: Attila Lendvai; +Cc: Suhail Singh, Ludovic Courtès, Guix Devel
Attila Lendvai <attila@lendvai.name> writes:
> - writing comments on a PR or issue in emacs
I have yet to see a way (that works with existing forges) that matches
the ease of replying to an email, but I look forward to being proven
wrong and pleasantly surprised.
> what i wanted to point out is that it's not a lot of effort to
> automate on the client side -- either using guile scripts, or with
> some code in emacs --, *if* the infra has a sane API. and i assume
> that that is the case with codeberg in 2025.
Perhaps. But unless someone commits to doing the work, I think the
decision should be made with the acknowledgement that it's possible that
the above doesn't happen for the foreseeable future. And it's possible
that that's okay, but then that's a stance I would like the proposal to
clarify (as opposed to leaving it unstated).
While, personally, I would miss being unable to simply respond to patch
emails in order to review, I acknowledge that the things I care about
may be an outlier in the community. As such, I am not advocating (yet)
against a move, I am simply advocating for acknowledging the possible
ramifications when it comes to the review process.
> it shouldn't take a lot of effort to write some thin emacs code that
> displays the codeberg data in an emacs buffer.
>
> making it work offline and sync later is probably substantially more
> work, but it should still not be an insurmountable task.
>
> and nothing of that would be guix specific! these are probably already
> being worked on somewhere (i.e. division of labor):
>
> https://codeberg.org/forgejo-contrib/delightful-forgejo#clients
> (A curated list of delightful Forgejo-related projects and resources.)
I think some of the above (perhaps phrased somewhat differently) would
be relevant addition to the proposal (and should be contained therein).
--
Suhail
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-31 15:12 ` reza
@ 2025-01-31 20:43 ` Tomas Volf
2025-02-01 11:37 ` 45mg
0 siblings, 1 reply; 76+ messages in thread
From: Tomas Volf @ 2025-01-31 20:43 UTC (permalink / raw)
To: reza; +Cc: Guix Devel
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
reza <reza@housseini.me> writes:
> To access the email lists on savannah you%d
> provide an email address and a password, to create an account on%d
> codeberg you provide exactly the same information.
For participating in the email lists (both bug reports and patch
submissions), you only need to send an email. You do not need to create
an account on savannah nor subscribe.
For subscribing, yes, you need to provide an email (obviously), but you
do not need to agree to any legal document (like Codeberg's Terms of
Use). So I think your assessment that they are exactly the same is not
correct.
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (13 preceding siblings ...)
[not found] ` <87frkzhvb8.fsf@housseini.me>
@ 2025-02-01 9:44 ` Lars-Dominik Braun
2025-02-01 18:28 ` Leo Famulari
2025-02-01 12:54 ` Carlo Zancanaro
` (2 subsequent siblings)
17 siblings, 1 reply; 76+ messages in thread
From: Lars-Dominik Braun @ 2025-02-01 9:44 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel
Hi,
> ## Repository Migration Path
do we want to take this opportunity to start off fresh without migrating
the main repository’s history? It looks like we have accumulated more
than 500MB of commit data so far and everyone who runs `guix pull` the
first time has to download all of that and authenticate a pretty large
number of commits. (Plus, ~/.cache/guix keeps on growing and growing.)
Lars
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-31 20:43 ` Tomas Volf
@ 2025-02-01 11:37 ` 45mg
2025-02-01 12:37 ` Tomas Volf
0 siblings, 1 reply; 76+ messages in thread
From: 45mg @ 2025-02-01 11:37 UTC (permalink / raw)
To: Tomas Volf, reza; +Cc: Guix Devel
Tomas Volf <~@wolfsden.cz> writes:
> reza <reza@housseini.me> writes:
>
>> To access the email lists on savannah you%d
>> provide an email address and a password, to create an account on%d
>> codeberg you provide exactly the same information.
>
> For participating in the email lists (both bug reports and patch
> submissions), you only need to send an email. You do not need to create
> an account on savannah nor subscribe.
>
> For subscribing, yes, you need to provide an email (obviously), but you
> do not need to agree to any legal document (like Codeberg's Terms of
> Use). So I think your assessment that they are exactly the same is not
> correct.
For those of us without the werewithal to self-host our email on our own
hardware (which includes me, and I would assume the majority of us,
despite the overall power-user bent of this community), we have to
create an account with an email provider, and agree to their Terms of
Service. Even people who operate their own mail server are probably
running it on a VPS or something, and I'm pretty sure there are going to
be ToS involved there as well. So in effect, most people using email are
at the mercy of an external service provider, the same way we would be
at Codeberg's mercy. And I am of the opinion that Codeberg is far more
benevolent than most large email providers these days.
That said, I do somewhat agree with the points you made earlier about
Codeberg's specific ToS. I doubt Codeberg is going to go evil anytime
soon, but some of those clauses do seem a bit scary. Then again, we
already have our infrastructure (repos, mailing lists) run by the FSF
(Savannah is an FSF project), so we're very much at /their/ mercy right
now; and I've heard more negative opinions of them than I've ever heard
about Codeberg.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-01 11:37 ` 45mg
@ 2025-02-01 12:37 ` Tomas Volf
2025-02-01 13:19 ` 45mg
0 siblings, 1 reply; 76+ messages in thread
From: Tomas Volf @ 2025-02-01 12:37 UTC (permalink / raw)
To: 45mg; +Cc: reza, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 2211 bytes --]
I mostly agree with your wider points, however couple of nitpicks below.
45mg <45mg.writes@gmail.com> writes:
> [..]
>
> For those of us without the werewithal to self-host our email on our own
> hardware (which includes me, and I would assume the majority of us,
> despite the overall power-user bent of this community), we have to
> create an account with an email provider, and agree to their Terms of
> Service. Even people who operate their own mail server are probably
> running it on a VPS or something, and I'm pretty sure there are going to
> be ToS involved there as well.
Depends, I host my email at VPSFree.cz, which is (roughly speaking) a
non-profit, where I do not pay a subscription, but a membership fee.
And I get full voting rights, per the applicable Czech laws for this
type of non-profit. So if I would not like something in our Charter, I
could put forward a motion for the next annual meeting, and get it voted
upon (but sure, the vote might not pass).
I do not have that option on GitHub, Hetzner, or, for that matter,
Codeberg.
> That said, I do somewhat agree with the points you made earlier about
> Codeberg's specific ToS. I doubt Codeberg is going to go evil anytime
> soon, but some of those clauses do seem a bit scary. Then again, we
> already have our infrastructure (repos, mailing lists) run by the FSF
> (Savannah is an FSF project), so we're very much at /their/ mercy right
> now; and I've heard more negative opinions of them than I've ever heard
> about Codeberg.
The difference I see here is that for Savannah only Guix as a project
needs to be aware of the legalese, however for Codeberg every
contributor (even non-committers) has to be (due to need to create an
account).
I also do not expect Codeberg to go evil (at least soon ^_^), but I
would still like to have point-by-point reaction to the concerns I have
raised about their current ToS (they call it Terms of Use (ToU)). I
believe it is a necessary debate if the Codeberg is the center piece of
this proposal.
Have a nice day,
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (14 preceding siblings ...)
2025-02-01 9:44 ` Lars-Dominik Braun
@ 2025-02-01 12:54 ` Carlo Zancanaro
2025-02-03 21:51 ` Ludovic Courtès
2025-02-02 14:12 ` paul
2025-02-05 10:36 ` Efraim Flashner
17 siblings, 1 reply; 76+ messages in thread
From: Carlo Zancanaro @ 2025-02-01 12:54 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel
On Tue, Jan 28 2025, Ludovic Courtès wrote:
> # Drawbacks and Open Issues
I think there is one thing to think about here. A while ago I listened
to a talk about the Linux kernel workflow[1]. At around 29:50 the
speaker discusses the benefit of a mailing list workflow in helping
people to learn the norms and culture of the project.
While Codeberg does give you the ability to "watch" repositories[2], my
impression is that this way of interacting with a repository is less
common when using a forge. I don't think I have ever used this feature
outside of repositories that I created myself.
Moving to using Codeberg for issues and pull requests may mean that the
most "natural" ways of people interacting with the project are more
isolated. For contributors, this has advantages (e.g. less chance of
being overwhelmed by emails), and disadvantages (e.g. less likely to
feel a part of the "Guix" whole).
[1]: https://www.youtube.com/watch?v=L8OOzaqS37s
[2]: https://docs.codeberg.org/getting-started/email-settings/#watching-repositories
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-01 12:37 ` Tomas Volf
@ 2025-02-01 13:19 ` 45mg
2025-02-03 16:19 ` Christopher Howard
0 siblings, 1 reply; 76+ messages in thread
From: 45mg @ 2025-02-01 13:19 UTC (permalink / raw)
To: Tomas Volf, 45mg; +Cc: reza, Guix Devel
Tomas Volf <~@wolfsden.cz> writes:
> I mostly agree with your wider points, however couple of nitpicks below.
Here's some nitpicks on your nitpicks :)
> 45mg <45mg.writes@gmail.com> writes:
>
>> [..]
>>
>> For those of us without the werewithal to self-host our email on our own
>> hardware (which includes me, and I would assume the majority of us,
>> despite the overall power-user bent of this community), we have to
>> create an account with an email provider, and agree to their Terms of
>> Service. Even people who operate their own mail server are probably
>> running it on a VPS or something, and I'm pretty sure there are going to
>> be ToS involved there as well.
>
> Depends, I host my email at VPSFree.cz, which is (roughly speaking) a
> non-profit, where I do not pay a subscription, but a membership fee.
> And I get full voting rights, per the applicable Czech laws for this
> type of non-profit. So if I would not like something in our Charter, I
> could put forward a motion for the next annual meeting, and get it voted
> upon (but sure, the vote might not pass).
>
> I do not have that option on GitHub, Hetzner, or, for that matter,
> Codeberg.
That sounds like a very nice setup. I'm a bit jealous :) But I doubt
such arrangements are available and/or affordable to people around the
world (I certainly don't know of any in my region). Which was my larger
point.
>> That said, I do somewhat agree with the points you made earlier about
>> Codeberg's specific ToS. I doubt Codeberg is going to go evil anytime
>> soon, but some of those clauses do seem a bit scary. Then again, we
>> already have our infrastructure (repos, mailing lists) run by the FSF
>> (Savannah is an FSF project), so we're very much at /their/ mercy right
>> now; and I've heard more negative opinions of them than I've ever heard
>> about Codeberg.
>
> The difference I see here is that for Savannah only Guix as a project
> needs to be aware of the legalese, however for Codeberg every
> contributor (even non-committers) has to be (due to need to create an
> account).
Worth noting that Savannah does have hosting requirements:
https://savannah.gnu.org/register/requirements.php
Nothing to the extent of Codeberg's ToS, but there is a strict
requirement to follow the FSDG, upto and including banning all
references to nonfree software, which was something that came up as a
point of contention during the survey. And as long as Guix uses Savannah
it has to enforce that requirement, or any further requirements imposed
the FSF, even against the wishes of the community if it comes to that.
My point here is - the fact that users are not directly exposed to the
policies (or conduct!) of the service provider does not mean they are
unaffected by them.
Also, I'm assuming that even participating in this discussion requires
us to follow Guix's Code of Conduct, which could be enforced against us
were we to violate it. And without intending to state any particular
position and/or start yet another inflammatory CoC flame war, I just
want to point out that not everyone is going to be fully comfortable
with the terms there either. But it's not hard to imagine why the
project needs them. And similarly it's not hard to imagine why Codeberg
would word its ToS to give them as much leverage as possible; from their
perspective, they're better safe than sorry. At some point, it comes
down to how much you trust the organization to act in your (and
everyone's) best interests. Personally, I trust the Guix project, and I
trust Codeberg; I can't really say the same for the FSF. (Tried to avoid
bringing that up, but here we are...)
> I also do not expect Codeberg to go evil (at least soon ^_^), but I
> would still like to have point-by-point reaction to the concerns I have
> raised about their current ToS (they call it Terms of Use (ToU)). I
> believe it is a necessary debate if the Codeberg is the center piece of
> this proposal.
Agreed.
> Have a nice day,
> Tomas
>
> --
> There are only two hard things in Computer Science:
> cache invalidation, naming things and off-by-one errors.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-01 9:44 ` Lars-Dominik Braun
@ 2025-02-01 18:28 ` Leo Famulari
2025-02-02 10:13 ` Lars-Dominik Braun
0 siblings, 1 reply; 76+ messages in thread
From: Leo Famulari @ 2025-02-01 18:28 UTC (permalink / raw)
To: Lars-Dominik Braun; +Cc: Ludovic Courtès, Guix Devel
On Sat, Feb 01, 2025 at 10:44:40AM +0100, Lars-Dominik Braun wrote:
> > ## Repository Migration Path
>
> do we want to take this opportunity to start off fresh without migrating
> the main repository’s history? It looks like we have accumulated more
> than 500MB of commit data so far and everyone who runs `guix pull` the
> first time has to download all of that and authenticate a pretty large
> number of commits. (Plus, ~/.cache/guix keeps on growing and growing.)
I'm not sure this is worth it, but maybe we can do better! If we were to
prune the repo in this way, it would break `guix time-machine`, which is
a nice selling point of Guix and really valuable.
If we were to do that, it would require updating the code-signing
authentication introductory commit. I figure that must be possible
although I don't know the details.
We could start using shallow clones, and only fetching Git history when
required. For a recent commit, this is 25 MB over the wire and 185 MB on
disk.
Now, shallow cloning has, at least in the past, been computationally
*very* expensive for Git server implementations, to the point where it
was considered abusive when done by projects that use Git repos like we
do. It was *vastly* more efficient to use Git "normally", by doing a
full clone and then updating it incrementally with `git fetch`. Maybe
this has improved in recent years; I haven't followed the state of the
art in this area.
Anyways, there's probably some room for improvement in this area, but I
think we should consider it out of scope for this proposal.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-01 18:28 ` Leo Famulari
@ 2025-02-02 10:13 ` Lars-Dominik Braun
2025-02-02 22:41 ` Leo Famulari
0 siblings, 1 reply; 76+ messages in thread
From: Lars-Dominik Braun @ 2025-02-02 10:13 UTC (permalink / raw)
To: Leo Famulari; +Cc: Ludovic Courtès, Guix Devel
Hi,
> I'm not sure this is worth it, but maybe we can do better! If we were to
> prune the repo in this way, it would break `guix time-machine`, which is
> a nice selling point of Guix and really valuable.
I doubt this would cause much breakage. As long as we keep the old
repository in place existing channels.scm files would continue to
work. Sure, you can’t easily jump back into the old repository via
`guix time-machine --commit=XXX` any more, but I’ve always considered
channels.scm files the “gold standard” in terms of reproducibility.
> Anyways, there's probably some room for improvement in this area, but I
> think we should consider it out of scope for this proposal.
Agreed, a proper solution that does not require git is ouf of scope for
this GCD.
Lars
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-29 11:24 ` 45mg
@ 2025-02-02 11:13 ` Ricardo Wurmus
0 siblings, 0 replies; 76+ messages in thread
From: Ricardo Wurmus @ 2025-02-02 11:13 UTC (permalink / raw)
To: 45mg; +Cc: Ludovic Courtès, Guix Devel
45mg <45mg.writes@gmail.com> writes:
> I strongly feel that the Guix project itself needs to maintain a
> permanent (read-only) archive of all its mailing lists, and ensure that
> it is searchable and downloadable.
The bug-guix and guix-patches mailing lists are special in that they are
only used as the entry point for the bug tracker. The suboptimal list
web interface is not how people are meant to interact with the archive.
The submissions to this mailing list are processed by Debbugs; past
submissions will remain visible in Debbugs, both via the SOAP interface
(used by debbugs.el) and the web interface.
> I'm actually fine with sunsetting issues.guix.gnu.org; while it was a
> significant improvement over the list archives, it still needed a lot
> more love. Moreover, it was fundamentally trying to turn threaded email
> discussions into flat lists of messages, with mixed results.
Minor correction: it did not try that; it merely meant to provide a more
usable, focused, and integrated alternative to https://bugs.gnu.org or
https://debbugs.gnu.org, neither of which shows threads.
> There's one more potential consequence of this GCD that I want to bring
> up - namely, the eventual stagnation of the discussion mailing lists
> (guix-devel and help-guix).
These mailing lists will continue to exist. This is about the patch
submission / review / merge workflow.
> I'm not bringing this up because I want to preserve the mailing lists at
> all costs; rather, I'm suggesting that we switch away from them as
> well. [...]
Let's please not discuss this within the context of this GCD. If we
cannot focus our attention on the already big subject of this GCD, we
will only get lost in the minutia of tangentially related issues without
getting any closer to action.
--
Ricardo
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (15 preceding siblings ...)
2025-02-01 12:54 ` Carlo Zancanaro
@ 2025-02-02 14:12 ` paul
2025-02-02 15:02 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2025-02-02 15:19 ` Suhail Singh
2025-02-05 10:36 ` Efraim Flashner
17 siblings, 2 replies; 76+ messages in thread
From: paul @ 2025-02-02 14:12 UTC (permalink / raw)
To: guix-devel, Ludovic Courtès, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
Hello Guix,
I've nothing substantial to add besides the fact that this proposal resonates a lot with the way I mean the free in free software. It is the way to go if Guix is really to be something as useful and as nice as Debian.
Thank you all for your work,
giacomo
[-- Attachment #2: Type: text/html, Size: 346 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-02 14:12 ` paul
@ 2025-02-02 15:02 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2025-02-02 15:50 ` Suhail Singh
2025-02-02 22:14 ` Leo Famulari
2025-02-02 15:19 ` Suhail Singh
1 sibling, 2 replies; 76+ messages in thread
From: Felix Lechner via Development of GNU Guix and the GNU System distribution. @ 2025-02-02 15:02 UTC (permalink / raw)
To: paul; +Cc: guix-devel, Ludovic Courtès
Hi,
On Sun, Feb 02 2025, paul wrote:
> It is the way to go if Guix is really to be something as useful and as
> nice as Debian.
That's a beautiful summary of this thread: Let's ignore all the issues
Guix has and switch to a new hosting platform, then everything will be
better!
Kind regards
Felix
P.S. Why not bury the backlog of open bugs while we are at it?
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-02 14:12 ` paul
2025-02-02 15:02 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
@ 2025-02-02 15:19 ` Suhail Singh
1 sibling, 0 replies; 76+ messages in thread
From: Suhail Singh @ 2025-02-02 15:19 UTC (permalink / raw)
To: paul; +Cc: guix-devel, Ludovic Courtès
paul <goodoldpaul@autistici.org> writes:
> It is the way to go if Guix is really to be something as useful and as
> nice as Debian.
Out of curiosity, do you believe that the Linux kernel isn't useful or
not nice?
--
Suhail
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-02 15:02 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
@ 2025-02-02 15:50 ` Suhail Singh
2025-02-02 22:37 ` Leo Famulari
2025-02-02 22:14 ` Leo Famulari
1 sibling, 1 reply; 76+ messages in thread
From: Suhail Singh @ 2025-02-02 15:50 UTC (permalink / raw)
To: Felix Lechner via Development of GNU Guix and the GNU System distribution.
Cc: paul, Felix Lechner, Ludovic Courtès
Felix Lechner via "Development of GNU Guix and the GNU System
distribution." <guix-devel@gnu.org> writes:
> summary of this thread: Let's ignore all the issues Guix has and
> switch to a new hosting platform, then everything will be better!
A part of me fears that that is indeed what's happening. Another part
is hopeful that some of the constructive criticism that has been raised
regarding the proposal will be addressed in an upcoming version.
Specifically, switching hosting platforms isn't a panacea. It is a
decision that comes with tradeoffs, some of which differ from the status
quo. This by itself is neither good nor bad. However, I don't believe
that the current proposal has considered _all_ material factors (though
it has considered some). Some questions that I am hopeful a future
revision will address:
- How would the review workflow look like, and a summary of how it will
differ from the current replying-to-emails process?
- What's the mitigation strategy to address the possibility that this
may result in loss of reviewers? If no such mitigation strategy is
intended and this is an accepted cost, then a comment clarifying that
position is, IMO, warranted.
- Does the move to codeberg _necessarily_ have to come with the
suspension of accepting email-based patch submissions? Alternatively,
could the benefits purported by the move to codeberg not be achieved
in _any_ other way?
These are important considerations that, IMO, the proposal ought to
clarify.
--
Suhail
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-02 15:02 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2025-02-02 15:50 ` Suhail Singh
@ 2025-02-02 22:14 ` Leo Famulari
2025-02-02 23:44 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
1 sibling, 1 reply; 76+ messages in thread
From: Leo Famulari @ 2025-02-02 22:14 UTC (permalink / raw)
To: Felix Lechner; +Cc: paul, guix-devel, Ludovic Courtès
On Sun, Feb 02, 2025 at 07:02:14AM -0800, Felix Lechner via Development of GNU Guix and the GNU System distribution. wrote:
> That's a beautiful summary of this thread: Let's ignore all the issues
> Guix has and switch to a new hosting platform, then everything will be
> better!
>
> Kind regards
> Felix
>
> P.S. Why not bury the backlog of open bugs while we are at it?
Everyone here recognizes that this proposal suggests a Big Change for
Guix, and also that the backlog of tickets is problematic.
But please try to participate in the conversation productively, without
resorting to sarcasm and dismissive condescension.
If you think the proposed change won't help Guix, it's fine to say so.
But again, try to do it in a more friendly and collegial way.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-02 15:50 ` Suhail Singh
@ 2025-02-02 22:37 ` Leo Famulari
2025-02-03 1:38 ` Suhail Singh
0 siblings, 1 reply; 76+ messages in thread
From: Leo Famulari @ 2025-02-02 22:37 UTC (permalink / raw)
To: Suhail Singh
Cc: Felix Lechner via Development of GNU Guix and the GNU System distribution.,
paul, Felix Lechner, Ludovic Courtès
On Sun, Feb 02, 2025 at 10:50:00AM -0500, Suhail Singh wrote:
> - How would the review workflow look like, and a summary of how it will
> differ from the current replying-to-emails process?
Good question, personally I don't know. I have used Gitlab and Github,
so I figure it would be something like that.
> - What's the mitigation strategy to address the possibility that this
> may result in loss of reviewers? If no such mitigation strategy is
> intended and this is an accepted cost, then a comment clarifying that
> position is, IMO, warranted.
I think we can be sure that we will lose some people if we make this
change. But I would hope that we gain more. Of course the supporters of
the proposal feel that way.
The status quo seems bad, with respect to adequate code review, so many
of us are not interested in preserving it. In my opinion, the recent
Guix survey published on the blog supports the sense that code review is
not working fast enough right now.
> - Does the move to codeberg _necessarily_ have to come with the
> suspension of accepting email-based patch submissions? Alternatively,
> could the benefits purported by the move to codeberg not be achieved
> in _any_ other way?
Also, I don't know if there is a way to email patches to Codeberg.
The second part of your question, is it important to exhaustively
consider every possible option? It's somewhat extraordinary to ask for
that. Does the question assume that Codeberg would be a bad change, so
we should try anything else first?
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-02 10:13 ` Lars-Dominik Braun
@ 2025-02-02 22:41 ` Leo Famulari
2025-02-03 17:24 ` Lars-Dominik Braun
0 siblings, 1 reply; 76+ messages in thread
From: Leo Famulari @ 2025-02-02 22:41 UTC (permalink / raw)
To: Lars-Dominik Braun; +Cc: Ludovic Courtès, Guix Devel
On Sun, Feb 02, 2025 at 11:13:53AM +0100, Lars-Dominik Braun wrote:
> I doubt this would cause much breakage. As long as we keep the old
> repository in place existing channels.scm files would continue to
> work. Sure, you can’t easily jump back into the old repository via
> `guix time-machine --commit=XXX` any more, but I’ve always considered
> channels.scm files the “gold standard” in terms of reproducibility.
Interesting! So, there would be like a 'guix-history' channel that one
could use with time-machine?
I still think it's really nice to have a single repo for understanding
the codebase and its context, and if shallow cloning has gotten more
efficient, that's a nicer option. But it sounds like there is a lot to
explore here. And I think we should be bold going forward!
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-02 22:14 ` Leo Famulari
@ 2025-02-02 23:44 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2025-02-03 1:39 ` Leo Famulari
0 siblings, 1 reply; 76+ messages in thread
From: Felix Lechner via Development of GNU Guix and the GNU System distribution. @ 2025-02-02 23:44 UTC (permalink / raw)
To: Leo Famulari; +Cc: paul, guix-devel, Ludovic Courtès
Hi Leo,
On Sun, Feb 02 2025, Leo Famulari wrote:
> please try to participate in the conversation productively
Okay, sorry about the sarcasm, although sometimes I think that's exactly
what a community needs. I meant to be a mirror.
In my view, Guix is unable to solve its problems, and people continually
look elsewhere for causes.
Sometimes it's a lack of "patch reviewers." At other times, Guix has to
leave GNU or the FSF because they are evil. Now Codeberg is being
offered to make everything better.
paul, please have no hard feelings toward me. You represent the
majority. I'm the odd one out (and will perhaps be disciplined for it).
I am not even a Guix contributor. I only used your comment when it came
in and would have spoken up soon anyway.
There is no other way to close bugs than to actually work on them.
I know because I co-maintained Lintian in Debian for five years. I
closed hundreds of bugs. In Debbugs.
Since paul brought up Debian, they also struggle with the attractive
workflow offered by code forges, although I haven't kept up-to-date.
For many years now, Debian has had a self-hosted Gitlab instance called
Salsa. I used it extensively and did not like it, for reason one below,
but acceptance in Debian is growing. Salsa was a hard-fought compromise
because:
1. Issues on code forges are hard to audit years later. Usually, I
can't even locate what I'm looking for.
2. Forges like Codeberg can disappear like Freenode or sell
themselves to Microshaft like Gitflub.
[I hope funny alterations of protected brand names are still welcome.]
In order to solve its problems, Guix needs to:
A. Expand Git access to several hundred people.
B. Stratify authorizations, perhaps based on an honor system,
according to people's area of expertise. It needs focus on
solving user problems and be more granular than teams instead of
merely aligning with upstream tools or packages.
C. Develop a quality standard for packages higher than "it builds."
Many packaging errors show only at runtime, especially in Guix.
D. Make user concerns a top priority. (Hi, Gottfried!)
In short, I don't think Guix can be like Debian without having the same
kind of people power, some sort of specialization, improved quality
control, and an unwavering focus on usability.
Codeberg does none of that, except maybe help with CI like Chris wrote.
I offer this email hoping that it will alleviate Leo's (and I'm sure
other people's) feeling of offense. My brief, cynical message was
acceptable for the discussion (or so I thought) but this longer message
clearly does not belong into the Codeberg thread. Sorry, Ludo', for
hijacking.
Please change the subject when responding.
Kind regards
Felix
P.S. I contributed my Codeberg mirror to the Guix group on Codeberg and
do not oppose Ludo's suggestion to move the repository.
P.P.S. I would take the opportunity, as first suggested by Lily, and
rename the master branch to the deadpan 'history'.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-02 22:37 ` Leo Famulari
@ 2025-02-03 1:38 ` Suhail Singh
2025-02-03 1:45 ` Leo Famulari
0 siblings, 1 reply; 76+ messages in thread
From: Suhail Singh @ 2025-02-03 1:38 UTC (permalink / raw)
To: Leo Famulari
Cc: Suhail Singh,
Felix Lechner via Development of GNU Guix and the GNU System distribution.,
paul, Felix Lechner, Ludovic Courtès
Leo Famulari <leo@famulari.name> writes:
> The status quo seems bad, with respect to adequate code review, so
> many of us are not interested in preserving it.
The status quo isn't great. However, it's not clear (to me and some
others) that this move will be better. It'll lead to improvements in
some areas, but there are also drawbacks. Not all the drawbacks seem to
have been considered in the GCD.
> In my opinion, the recent Guix survey published on the blog supports
> the sense that code review is not working fast enough right now.
Agreed. However, where there is disagreement is that the move to
Codeberg would help with this issue. It could, but it's not clear based
on the GCD that it would. The GCD focuses on the potential benefits,
without providing sufficient reasoning to conclude that the potential
ill-effects wouldn't outweigh the benefits. Notably, the proposal
provides very little detail on how the review workflow would differ from
the status quo (and the implications therein).
>> - Does the move to Codeberg _necessarily_ have to come with the
>> suspension of accepting email-based patch submissions? Alternatively,
>> could the benefits purported by the move to Codeberg not be achieved
>> in _any_ other way?
>
> Also, I don't know if there is a way to email patches to Codeberg.
>
> The second part of your question, is it important to exhaustively
> consider every possible option? It's somewhat extraordinary to ask for
> that.
No, it isn't important to exhaustively consider _every_ possible
alternative to the move to Codeberg, but surely some alternatives that
still maintain the benefits of the status quo ought to be considered (if
only to conclude them as being infeasible).
> Does the question assume that Codeberg would be a bad change, so we
> should try anything else first?
No. The question simply recognizes that the current proposal seems to
be "all in" and that there is insufficient evidence provided to conclude
that the move to Codeberg would necessarily be a good change.
If it works as expected, great. If it doesn't, it doesn't seem likely
we'd be switching back to the status quo - we may switch to yet-another
process, perhaps. I.e., once we make the move, it's an effective point
of no return. For such moves, it's worth doing some thinking and
analysis _prior_ to the change. I believe that this is what the GCD
intended to achieve. I am merely pointing out some blind-spots in the
presented analysis.
--
Suhail
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-02 23:44 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
@ 2025-02-03 1:39 ` Leo Famulari
2025-02-04 10:11 ` Ludovic Courtès
0 siblings, 1 reply; 76+ messages in thread
From: Leo Famulari @ 2025-02-03 1:39 UTC (permalink / raw)
To: Felix Lechner; +Cc: paul, guix-devel, Ludovic Courtès
On Sun, Feb 02, 2025 at 03:44:28PM -0800, Felix Lechner wrote:
> Okay, sorry about the sarcasm, although sometimes I think that's exactly
> what a community needs. I meant to be a mirror.
Fair enough, although none of us old-timers think it's going to be a
simple and easy fix for everything! Personally I think that sarcasm can
be detrimental in a text-based environment, where there is too much
diversity among participants for it to land properly.
I think the your follow-up email is really useful and constructive, and
I'm grateful that you took the time to write it.
> There is no other way to close bugs than to actually work on them.
If the problem is ultimately the backlog of bugs / patch tickets, then
yes, there's no substitute for working on them.
But I perceive the problem as going beyond that. We have a torrent of
bug reports and contributions, which is fantastic. That's a good problem
to have for a free software project.
But how can we "actually work on them" if the number of people able and
willing to do so is too small? It's not that easy, right? We get lots of
bug reports, but not as many patches to fix them.
Having been involved with Guix for many years, during several of which I
performed a large proportion of the code review, I realized the hard way
that it's always necessary to resolve issues properly. We'll never
reduce the backlog and actually improve Guix (rather than just close
tickets) if we commit buggy, unmaintainable, or unidiomatic code that
breaks conventions and models.
I'm sure you know that, I don't mean to be condescending. But my point
is that I believe that we have to help contributors grow in their
ability to make efficient contributions that pay off in the long run, so
that they can commit code without oversight, and in turn mentor more
committers.
And that has to happen fast enough that the chain isn't broken when they
inevitable leave the project for one of the reasons that we all
eventually leave.
I believe that the best way to do that is to cast a wide net, always
bringing in more people and making it easier to get started, and to take
the next step, and the step after that, and I hope that using a
non-email workflow will help with that.
I don't think the impact of web-based workflows like Github on overall
participation in computer programming should be discounted (although
maybe economic conditions can account for it instead). There are soooo
many programmers these days, way more than population growth can account
for.
To put my cards on the table... I'd miss living in Mutt very much. But
I think this change would be the right thing for Guix and any other
project like it.
> 1. Issues on code forges are hard to audit years later. Usually, I
> can't even locate what I'm looking for.
That would be bad. We'd need a solution to preserve the record in
perpetuity in an accessible way.
> 2. Forges like Codeberg can disappear like Freenode or sell
> themselves to Microshaft like Gitflub.
Yeah, it's a risk, but there's a risk of losing our platforms no matter
what we use, whether to perfidy, exhaustion, or whatever.
> In order to solve its problems, Guix needs to:
>
> A. Expand Git access to several hundred people.
Yes, in conjunction with:
> B. Stratify authorizations, perhaps based on an honor system,
> according to people's area of expertise.
I don't think the Guix maintainers would suddenly expand commit access
without some kind of finer-grained authorization system.
> It needs focus on solving user problems and be more granular
> than teams instead of merely aligning with upstream tools or
> packages.
Can you clarify this suggestion? I'm not sure what you have in mind that
is more granular than teams but not as granular as Debian's "package
maintainers". I do think we need a way to let team members commit,
perhaps to a team branch, as suggested in the GCD.
> C. Develop a quality standard for packages higher than "it builds."
> Many packaging errors show only at runtime, especially in Guix.
Absolutely. Again, I think we need a lot more people who create high
quality work but, to repeat myself, first we need to find / grow them.
> My brief, cynical message was acceptable for the discussion (or so I
> thought) but this longer message clearly does not belong into the
> Codeberg thread. Sorry, Ludo', for hijacking.
I think that it does belong, since the Codeberg proposal is about making
it more attractive and easier to contribute to Guix, and the
second-order goal of that is to grow able and trustworthy contributors,
with the ultimate goal of improving the long-term health of the project.
If Codeberg is the wrong thing, then okay, but I think we share a goal
and it's fine to talk about that here.
PS, a few numbers:
I tried to compare two periods of roughly equal length, that
post-date the "early days" of Guix. With Guix 0.8, there was a
standalone functional package manager, an environment / shell creator,
grafts, and an OS. Basically the same offering as today, but of course
much smaller.
Growth of active committers:
------
$ git shortlog -ncs v0.8..v0.9.0 | wc -l # ~23 months
20
$ git shortlog -ncs v1.4.0..HEAD | wc -l # ~25 months
51
------
Growth of contributors in the same time period:
------
$ git shortlog -ns v0.8..v0.9.0 | wc -l
47
$ git shortlog -ns v1.4.0..HEAD | wc -l
570
------
So, we are not growing our base of committers in proportion to
contributors, and I think we've lost contributors as a result.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-03 1:38 ` Suhail Singh
@ 2025-02-03 1:45 ` Leo Famulari
0 siblings, 0 replies; 76+ messages in thread
From: Leo Famulari @ 2025-02-03 1:45 UTC (permalink / raw)
To: Suhail Singh
Cc: Felix Lechner via Development of GNU Guix and the GNU System distribution.,
paul, Felix Lechner, Ludovic Courtès
On Sun, Feb 02, 2025 at 08:38:14PM -0500, Suhail Singh wrote:
> If it works as expected, great. If it doesn't, it doesn't seem likely
> we'd be switching back to the status quo - we may switch to yet-another
> process, perhaps. I.e., once we make the move, it's an effective point
> of no return. For such moves, it's worth doing some thinking and
> analysis _prior_ to the change. I believe that this is what the GCD
> intended to achieve. I am merely pointing out some blind-spots in the
> presented analysis.
Right, that makes sense.
I think this GCD will take some time to "shake out". For one thing, we
haven't even formally adopted the GCD process yet! So I'm sure there is
still a lot of discussion and clarifications to perform before a
decision can be reached.
I guess my perspective is that we have 2 basic choices: email, or a web
site. I've mainly been thinking about Codeberg generically as a "web
site" option, and not the specifics of Codeberg itself. Thanks for
helping me see that.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-30 9:02 ` Ekaitz Zarraga
@ 2025-02-03 14:47 ` Cayetano Santos
0 siblings, 0 replies; 76+ messages in thread
From: Cayetano Santos @ 2025-02-03 14:47 UTC (permalink / raw)
To: ekaitz; +Cc: guix-devel, rekado
[-- Attachment #1: Type: text/plain, Size: 259 bytes --]
Just for the record, and as for Sourcehut maintainers, "sr.ht is mostly
hosted in the Netherlands, with a backup site in the US"
--
Cayetano Santos
GnuPG Key: https://meta.sr.ht/~csantosb.pgp
FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-01 13:19 ` 45mg
@ 2025-02-03 16:19 ` Christopher Howard
2025-02-03 20:07 ` Ricardo Wurmus
0 siblings, 1 reply; 76+ messages in thread
From: Christopher Howard @ 2025-02-03 16:19 UTC (permalink / raw)
To: 45mg; +Cc: Tomas Volf, reza, Guix Devel
There are so many replies on this thread, I don't have time to work through them all. So I just wanted to throw out my concerns: I do host some little projects on Codeberg (none worth listing), but neverthess:
- I prefer not to have to use a Web browser interface at all to checks news or issues, or apply or submit packages. I am trying to, as much as possible, remove the monolithic, bloated Web browser entirely from my life.
- I am happy that debbugs interface and the mailing lists allow me to do the above entirely through an Emacs interface.
- If we were using some kind of Web forge, I'd want an https API that allows me to do everything through Emacs. If the API was good maybe it would not be too difficult to develop the Emacs library for that — not sure.
- If I had to use a Web browser to access some functionality, it should work through EWW and not require any JavaScript.
--
Christopher Howard
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-02 22:41 ` Leo Famulari
@ 2025-02-03 17:24 ` Lars-Dominik Braun
0 siblings, 0 replies; 76+ messages in thread
From: Lars-Dominik Braun @ 2025-02-03 17:24 UTC (permalink / raw)
To: Leo Famulari; +Cc: Ludovic Courtès, Guix Devel
Hi,
> Interesting! So, there would be like a 'guix-history' channel that one
> could use with time-machine?
either that or just keep the current repo at the current location and
start fresh at a new location.
Lars
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 21:41 ` Tomas Volf
2025-01-30 7:35 ` Andreas Enge
2025-01-30 21:28 ` Suhail Singh
@ 2025-02-03 17:50 ` Ludovic Courtès
2 siblings, 0 replies; 76+ messages in thread
From: Ludovic Courtès @ 2025-02-03 17:50 UTC (permalink / raw)
To: Guix Devel
Hi Tomas,
Tomas Volf <~@wolfsden.cz> skribis:
> From more ideological point of view, I think it is a strict downgrade
> regarding the entry barrier. The very first thing new contributor needs
> to do before contributing to GNU Guix is to read Terms of Service
> document of a third party and agree to it.
>
> I took the time to read it, and there are few points I have an issue
> with:
I agree that it’s a downside of forges that one has to (1) create an
account and (2) agree to the terms of services of said forge. This will
eventually be mitigated by federation but we’re not there yet.
Self-hosting has a cost that I think we’re not ready to pay, but I’m
happy to reconsider if we see an influx of volunteers to take care of
it.
Some general comments:
I admit I did not read the Codeberg ToS yet, so thanks for doing it.
I think the us-vs-they framing in your message is inappropriate though:
we’re talking about a non-profit of like-minded people that we can
actually talk to (we had a chat with them over the weekend at FOSDEM).
So I think we should ask for clarifications, raise any concerns that we
have, and see how to address them.
Thanks for your feedback!
Ludo’.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-03 16:19 ` Christopher Howard
@ 2025-02-03 20:07 ` Ricardo Wurmus
2025-02-03 21:18 ` Tomas Volf
0 siblings, 1 reply; 76+ messages in thread
From: Ricardo Wurmus @ 2025-02-03 20:07 UTC (permalink / raw)
To: Christopher Howard; +Cc: 45mg, Tomas Volf, reza, Guix Devel
Hi Christopher,
Codeberg.org / Forgejo does have an API, and there are Emacs interfaces.
They are mentioned in the GCD.
--
Ricardo
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 23:32 ` Tomas Volf
2025-01-29 3:05 ` Ian Eure
@ 2025-02-03 21:00 ` Ludovic Courtès
1 sibling, 0 replies; 76+ messages in thread
From: Ludovic Courtès @ 2025-02-03 21:00 UTC (permalink / raw)
To: Guix Devel
Tomas Volf <~@wolfsden.cz> skribis:
>> The software behind the forge has to be free software that is
>> *plausibly* self-hosted on Guix System—this probably rules out GitLab
>> Community Edition
>
> I am curious about this. GitLab Community Edition is under MIT (so
> ticks the free software checkbox). While I am not an expert, I *think*
> it is mix of golang and ruby code, so that seems feasible to self-host
> on top of Guix system?
There are several issues with GitLab: first, it is developed by a
for-profit under an “open core” model—not exactly in line with the way
many of us in the project envision user freedom.
Secondly, it’s a beast, a very big piece of software, and something
that’s also not trivial to administrate (IT department at work runs an
instance, but there’s quite a few people to keep it afloat).
Last, even if we put client-side JavaScript aside, it’s unlikely we
could package it all in Guix.
> And GitLab would have the advantage that (Magit) Forge works with it.
We briefly discussed it with the Codeberg/Forgejo people and they noted
that most of the Gitea/Forgejo interface is actually the same as that of
GitHub, so it may be that GitHub clients could do some/most operations
on a Forgejo instance. Worth investigating.
Overall, I’m not too concerned about our ability to figure this out;
it’s work, yes, but little compared to developing and running mumi,
running Patchwork, etc.
>> The Savannah `guix.git` repository would become a mirror of the one at
>> Codeberg, with a script periodically updating it, as a way to ease
>> migration to the new repository for users.
>
> Will all the repositories listed above be mirrored? Or just the
> guix.git?
It’s up for discussion. Personally, I’d just keep guix.git on Savannah,
clearly marked as a mirror; I think keeping all of them in both places
could be confusing.
>> ## Issue Tracker Migration Path
>>
>> Importing all the issues and patches from Debbugs/mumi into Codeberg
>> would be impractical: it would require the development of specific
>> tools, would be a lossy process due to the fundamental mismatch between
>> plain text email threads and Forgejo issues and pull requests, and would
>> bring little in return.
>
> I understand the impracticality, but just want to make sure I understand
> the implications. Will this mean that I will have to go over all my
> patches and resend them to Codeberg one by one, or is it expected the
> patches already sent will still be processed (just new ones will not be
> accepted)?
What I’m proposing (but again, up for discussion) is to discuss patches
already on issues.guix via email just like we currently do.
>> Care will be taken to advertise the various interfaces to
>> Codeberg/Forgejo that exist in addition to its web interface, such as
>> [forgejo-cli](https://codeberg.org/Cyborus/forgejo-cli/) and
>> [fj.el](https://codeberg.org/martianh/fj.el/).
>
> I took a look at the fj.el and I did not figure out how to for example
> create a pull request. So I assume people will need to create their own
> tooling, probably around the forgejo-cli.
I would just extend fj.el in this case. The HTTP API basically covers
everything one can do via the web interface, and it’s all pretty well
documented:
https://forgejo.org/docs/latest/user/api-usage/
https://codeberg.org/api/swagger#/
If the needs arise, we could even have a Guile client in the style of
(guix swh), (guix import pypi), etc.
>> ## Workflow
>>
>> [..]
>>
>> Since Guix requires signed commits by people listed in
>> `.guix-authorizations`, we will *not* be able to click the “Merge”
>> button nor to enable auto-merge on build success.
>
> Out of curiosity, is it possible to disable the merge button? I am
> pretty sure it is just a matter of time until someone presses it by
> accident.
One can configure Forgejo to refused unsigned commits (this is what we
did for <https://codeberg.org/guix-science/guix-science>, which is
signed). In that case, Forgejo just won’t merge because it cannot sign
commits (well, I think the instance could be configured to sign commits,
but Codeberg’s is not).
>> XXX: Does it really belong in this document? Should we just keep that
>> for later?
>
> In my opinion this deserves separate document later. That would help to
> keep the debate focused on a single topic.
OK.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-29 9:19 ` Cayetano Santos
@ 2025-02-03 21:03 ` Ludovic Courtès
2025-02-04 13:13 ` Maxim Cournoyer
2025-02-04 17:02 ` Suhail Singh
0 siblings, 2 replies; 76+ messages in thread
From: Ludovic Courtès @ 2025-02-03 21:03 UTC (permalink / raw)
To: Cayetano Santos; +Cc: guix-devel
Hello,
Cayetano Santos <csantosb@inventati.org> skribis:
> Given the current work in progress status of tooling at Codeberg side,
> would it be feasible to consider a period of time during which the two
> strategies overlap ? Kind of a testing cohabitation period.
This is more or less what some proposed at the Guix Days: starting with
a “sandbox” where interested committers and some contributors (we’d need
to figure out to not make it wide open, probably) could test the
workflow and tools at Codeberg to get a clearer picture and make an
informed decision.
Ludo’.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-29 17:34 ` Noé Lopez via Development of GNU Guix and the GNU System distribution.
@ 2025-02-03 21:16 ` Ludovic Courtès
0 siblings, 0 replies; 76+ messages in thread
From: Ludovic Courtès @ 2025-02-03 21:16 UTC (permalink / raw)
To: Noé Lopez; +Cc: guix-devel
Hi Noé,
Noé Lopez <noe@noé.eu> skribis:
>> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
>
> GCD#0001 says GFDL 1.3 or later, but has « only » in the license
> identifier. So this should be GFDL-1.3-no-invariants-or-later. Or maybe
> not, I don’t know the legal implications of saying two different things
> in the same document. I already sent a mail to Simon to make an
> erratum.
Yes, that’s a mistake in the template that I just copied over, I guess
(we very clearly said “or any later version” when discussing it).
Thanks for the heads-up and for your other comments!
Ludo’.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-03 20:07 ` Ricardo Wurmus
@ 2025-02-03 21:18 ` Tomas Volf
0 siblings, 0 replies; 76+ messages in thread
From: Tomas Volf @ 2025-02-03 21:18 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: Christopher Howard, 45mg, reza, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
Ricardo Wurmus <rekado@elephly.net> writes:
> Hi Christopher,
>
> Codeberg.org / Forgejo does have an API, and there are Emacs interfaces.
> They are mentioned in the GCD.
There does not seems to be an API for the Terms of Use. At least I did
not manage to find it.
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-29 21:27 ` Liliana Marie Prikler
@ 2025-02-03 21:20 ` Ludovic Courtès
0 siblings, 0 replies; 76+ messages in thread
From: Ludovic Courtès @ 2025-02-03 21:20 UTC (permalink / raw)
To: Liliana Marie Prikler; +Cc: Guix Devel
Hi,
Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
> Am Dienstag, dem 28.01.2025 um 15:33 +0100 schrieb Ludovic Courtès:
>> To keep track of bug reports and patches, Guix historically chose
>> tools that were *simple* in their design:
>>
>> - bug reports and patches can be sent by plain email, without
>> having to create an account or even subscribe to a mailing list;
>> - discussion and patch review happen naturally by email, without
>> requiring special tools;
> I think we should still have simple tools at our disposal, even if they
> end up talking to Forgejo in the end.
I really meant simple in their design; clients talking to Forgejo are
great, but one could argue that the design of Forejo is not simple in
the same way using plain email is.
> Perhaps instead of
>> - Within **30 days** after acceptance of this GCD, mailing list
>> administrators will set up the `bug-guix` and `guix-patches`
>> mailing
>> lists in “Emergency Moderation” mode in the Mailman
>> interface—meaning that messages will not get through anymore. It
>> will still be possible to interact on individual issues via
>> `NNN@debbugs.gnu.org`.
> we can make it so that emails to these addresses get forwarded to
> Forgejo's bug tracker?
I think it would be confusing if discussions started via Debbugs by
email transparently continued on Forgejo. (I think it would also be
difficult to do technically, esp. since we Guix people don’t
administrate Savannah/Debbugs.)
Thanks for this and your other thoughtful comments!
Ludo’.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-30 13:13 ` Simon Tournier
@ 2025-02-03 21:32 ` Ludovic Courtès
0 siblings, 0 replies; 76+ messages in thread
From: Ludovic Courtès @ 2025-02-03 21:32 UTC (permalink / raw)
To: Simon Tournier; +Cc: Guix Devel
Hi Simon,
Simon Tournier <zimon.toutoune@gmail.com> skribis:
> First, since we bounded the various periods, could you be clear about
> them? Because, you already found two “sponsors” and the GCD has not
> been sent to info-guix, if I read correctly.
Like I wrote, I’m anticipating on the GCD process being accepted at all.
If it’s accepted on Feb. 5th, then I’ll follow it to the letter.
This means we could enter “Discussion Period” on Feb. 5th or so and thus
deliberation would end between March 19th and April 19th.
> I would add two roadblocks (at least for me):
>
> 1. Not being able to process offline.
>
> 2. Not being able to comment patches directly from the editor of my own
> choice.
I think this was now answered: Magit-Forge, fj.el, forgejo-cli. Not all
of this is fully ready, but I’m sure we’ll find enough motivation to
give a hand to their developers.
[...]
> All in all, I do not have yet a definitive opinion on the GCD and I
> think we need to include (at least) a paragraph about this “dilemma“ /
> trade-off / balance. WDYT?
I alluded to it in the ‘Motivation’ section, explaining that we started
from tools with a simple design and ended up with a lot of incidental
complexity.
But yes, we could add something about it under ‘Choice of a Forge’.
> 1: https://codeberg.org/martianh/fj.el/pulls/79
Neat! Way to go!
Ludo’.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-30 16:56 ` Christopher Baines
@ 2025-02-03 21:38 ` Ludovic Courtès
0 siblings, 0 replies; 76+ messages in thread
From: Ludovic Courtès @ 2025-02-03 21:38 UTC (permalink / raw)
To: Christopher Baines; +Cc: Guix Devel
Hi,
Christopher Baines <mail@cbaines.net> skribis:
>> ## Workflow
>>
>> Once continuous integration (CI) is fully operational, pull requests may
>> be merged if and only if they successfully built. “World-rebuild” pull
>> requests would still follow the [existing branching
>> process](https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html).
>
> Given this proposal isn't to get "continuous integration" to be fully
> operational, I don't think this paragraph is really relevant.
I agree that the proposal is not about CI per se, but I felt the need to
show a direction, something that becomes possible thanks to the tools:
no push without a green light from CI.
This is the obvious thing to do for most developers these days. We have
a huge package collection, so that’s even more relevant to us.
But yes, apart from this statement, it’s probably wise to drop the rest
of the “Workflow” section because it’s too vague.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-31 15:10 ` Suhail Singh
2025-01-31 16:37 ` Attila Lendvai
@ 2025-02-03 21:47 ` Ludovic Courtès
2025-02-03 23:25 ` Suhail Singh
1 sibling, 1 reply; 76+ messages in thread
From: Ludovic Courtès @ 2025-02-03 21:47 UTC (permalink / raw)
To: Suhail Singh; +Cc: Guix Devel
Hi,
Suhail Singh <suhailsingh247@gmail.com> skribis:
> The move to codeberg has the potential to alleviate the rate limiting
> step (the throughput of committing patches). This has been discussed.
> However, said move also has the potential to reduce the throughput of
> reviews. It's not clear that the number of Guix contributors who
> contribute by participating in the review process won't find the web
> interface less convenient. And that this effect won't be greater than
> the positive effect of attracting more reviewers. Finally, it's
> possible that the reduction in throughput is so great that it offsets
> any gains in commit throughput.
These are all valid points and we cannot have definite answers.
The reason I’m optimistic about the review throughput is informed by my
experience with Guix-Science over the last few months. Just like
Ricardo wrote, I found it way easier to see where my attention as a
reviewer was needed than with our email workflow. It’s also possible to
subscribe/unsubscribe from individual issues/pull requests, which helps
a lot.
To clarify where I’m talking from: I too am the kind of person who’d
rather not leave Emacs, especially for a JS-based clicky interface, I
have a big reponsibility in our current setup, and I’ve often been
skeptical about the “email is hard” argument.
In spite of this, I do find that the Codeberg workflow works better for
me as a reviewer, even though I’m currently mixing ‘fj.el’ and the
dreaded web interface.
Ludo’.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-01 12:54 ` Carlo Zancanaro
@ 2025-02-03 21:51 ` Ludovic Courtès
0 siblings, 0 replies; 76+ messages in thread
From: Ludovic Courtès @ 2025-02-03 21:51 UTC (permalink / raw)
To: Carlo Zancanaro; +Cc: Guix Devel
Hey Carlo,
Carlo Zancanaro <carlo@zancanaro.id.au> skribis:
> Moving to using Codeberg for issues and pull requests may mean that the
> most "natural" ways of people interacting with the project are more
> isolated. For contributors, this has advantages (e.g. less chance of
> being overwhelmed by emails), and disadvantages (e.g. less likely to
> feel a part of the "Guix" whole).
I agree; forges are very good at channeling communication, which is what
we need for patches, but the flip side is that this seems to lead to
silos.
Guix-devel and help-guix will still be there though and I hope they can
still serve as an agora where everyone meets.
Ludo’.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-03 21:47 ` Ludovic Courtès
@ 2025-02-03 23:25 ` Suhail Singh
0 siblings, 0 replies; 76+ messages in thread
From: Suhail Singh @ 2025-02-03 23:25 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Suhail Singh, Guix Devel
Thank you for taking the time to respond.
Ludovic Courtès <ludo@gnu.org> writes:
> even though I’m currently mixing ‘fj.el’ and the dreaded web
> interface.
Out of curiosity, could you please briefly mention what you're using
each for as of now? With the understanding that it's not meant as a
recommendation, but to those of us not familiar with fj.el this may
serve as a relevant data point.
--
Suhail
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-03 1:39 ` Leo Famulari
@ 2025-02-04 10:11 ` Ludovic Courtès
0 siblings, 0 replies; 76+ messages in thread
From: Ludovic Courtès @ 2025-02-04 10:11 UTC (permalink / raw)
To: Leo Famulari; +Cc: Felix Lechner, paul, guix-devel
Hi Leo,
Leo Famulari <leo@famulari.name> skribis:
> Growth of active committers:
> ------
> $ git shortlog -ncs v0.8..v0.9.0 | wc -l # ~23 months
> 20
> $ git shortlog -ncs v1.4.0..HEAD | wc -l # ~25 months
> 51
> ------
>
> Growth of contributors in the same time period:
> ------
> $ git shortlog -ns v0.8..v0.9.0 | wc -l
> 47
> $ git shortlog -ns v1.4.0..HEAD | wc -l
> 570
> ------
>
> So, we are not growing our base of committers in proportion to
> contributors, and I think we've lost contributors as a result.
I believe we want to keep the number of committers relatively small, for
security reasons.
For Nixpkgs, we get:
--8<---------------cut here---------------start------------->8---
$ git shortlog -ns --since=two-years|wc -l
5675
$ git shortlog -ns --since=last-year|wc -l
4048
--8<---------------cut here---------------end--------------->8---
Using ‘-ncs’ won’t give us the real number of committers to Nixpkgs
(since everyone who makes a pull request is a committer from Git’s
perspective). So I asked fellow NixOS hackers on Mastodon and there’s
at the moment 255 committers to Nixpkgs (ratio of 1 to 16).
The way to get there is by automating things so that committers have
little more to do than press a button to merge changes.
My understanding is that Nixpkgs now allows merges by package
maintainers, who are usually not committers, by sending commands to a
merge bot:
https://github.com/NixOS/nixpkgs-merge-bot
https://github.com/NixOS/rfcs/pull/172/files#diff-d44ac0cd941ca5ce5e56388cd1a97171b299feed94aae4a405b3cc56b26d8b0c
This is the kind of workflow we need to improve scalability IMO.
Ludo’.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-29 11:10 ` Ricardo Wurmus
2025-01-30 10:42 ` Divya Ranjan
@ 2025-02-04 12:54 ` Maxim Cournoyer
2025-02-04 18:07 ` Vagrant Cascadian
1 sibling, 1 reply; 76+ messages in thread
From: Maxim Cournoyer @ 2025-02-04 12:54 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: Divya Ranjan, Ludovic Courtès, Guix Devel
Hi Ricardo,
Ricardo Wurmus <rekado@elephly.net> writes:
[...]
> I'm no stranger to debbugs and had previously built mumi (which powers
> issues.guix.gnu.org); we never managed to reach the same level of
> convenience. People send patches without X-Debbugs-Cc-ing the
> associated team and so patches wait for a review for months.
Just to clarify, this shouldn't happen as long as the submission is made
via 'git send-email', which has a hook CC'ing team members based on the
scope via X-Debbugs-CC.
--
Thanks,
Maxim
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-03 21:03 ` Ludovic Courtès
@ 2025-02-04 13:13 ` Maxim Cournoyer
2025-02-04 17:02 ` Suhail Singh
1 sibling, 0 replies; 76+ messages in thread
From: Maxim Cournoyer @ 2025-02-04 13:13 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Cayetano Santos, guix-devel
Hi Ludovic,
Ludovic Courtès <ludo@gnu.org> writes:
> Hello,
>
> Cayetano Santos <csantosb@inventati.org> skribis:
>
>> Given the current work in progress status of tooling at Codeberg side,
>> would it be feasible to consider a period of time during which the two
>> strategies overlap ? Kind of a testing cohabitation period.
>
> This is more or less what some proposed at the Guix Days: starting with
> a “sandbox” where interested committers and some contributors (we’d need
> to figure out to not make it wide open, probably) could test the
> workflow and tools at Codeberg to get a clearer picture and make an
> informed decision.
That sounds wise to me. We might just discover that the two can happily
cohabit.
--
Thanks,
Maxim
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-03 21:03 ` Ludovic Courtès
2025-02-04 13:13 ` Maxim Cournoyer
@ 2025-02-04 17:02 ` Suhail Singh
1 sibling, 0 replies; 76+ messages in thread
From: Suhail Singh @ 2025-02-04 17:02 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Cayetano Santos, guix-devel
Ludovic Courtès <ludo@gnu.org> writes:
> This is more or less what some proposed at the Guix Days: starting with
> a “sandbox” where interested committers and some contributors (we’d need
> to figure out to not make it wide open, probably) could test the
> workflow and tools at Codeberg to get a clearer picture and make an
> informed decision.
I hope that that happens. And further that the findings from such a
test be added to a subsequent version of the proposal. I.e., it's
difficult not to make a speculative decision (as opposed to an informed
one) without having the facts of such an investigation.
--
Suhail
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-04 12:54 ` Maxim Cournoyer
@ 2025-02-04 18:07 ` Vagrant Cascadian
2025-02-06 4:31 ` Maxim Cournoyer
0 siblings, 1 reply; 76+ messages in thread
From: Vagrant Cascadian @ 2025-02-04 18:07 UTC (permalink / raw)
To: Maxim Cournoyer, Ricardo Wurmus
Cc: Divya Ranjan, Ludovic Courtès, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]
On 2025-02-04, Maxim Cournoyer wrote:
> Ricardo Wurmus <rekado@elephly.net> writes:
>> I'm no stranger to debbugs and had previously built mumi (which powers
>> issues.guix.gnu.org); we never managed to reach the same level of
>> convenience. People send patches without X-Debbugs-Cc-ing the
>> associated team and so patches wait for a review for months.
>
> Just to clarify, this shouldn't happen as long as the submission is made
> via 'git send-email', which has a hook CC'ing team members based on the
> scope via X-Debbugs-CC.
Although, in my experience, if a long series touches many files, it
"helpfully" sends only the patches that affect the team rather than the
whole series, which then means I have to actually manually go dig out
the rest of the patches somehow in order to actually apply them... the
logic of it is not wrong, per se, but in practice it delays my ability
to give any meaningful review...
I think a merge-request style workflow will help with papercuts like
that, at least for me...
When working with salsa.debian.org (a gitlab instance) there is a way to
fetch all the merge requests for a given git repository, so it just
becomes part of my normal workflow and to some extent works offline. If
codeberg had a similar feature, that would be great!
I liked the guix-patches repository
(https://git.guix-patches.cbaines.net/git/guix-patches) for this sort of
workflow, but it was often missing patches, or worse, missing the most
current proposed patches without any obvious way to know. At least a
handful of times in my experience, people merged old patchsets possibly
because the new ones never landed. Probably partly due to the nature of
a rube-goldbergian contraption of extracting the patches from debbugs
and then massaging them into a git repository. If any service in the
chain was down, the whole thing was degraded or non-operational.
I much prefer approaches where you have to do as few transformations as
possible as part of the default workflow!
live well,
vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
` (16 preceding siblings ...)
2025-02-02 14:12 ` paul
@ 2025-02-05 10:36 ` Efraim Flashner
2025-02-05 10:56 ` Cayetano Santos
17 siblings, 1 reply; 76+ messages in thread
From: Efraim Flashner @ 2025-02-05 10:36 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel
[-- Attachment #1: Type: text/plain, Size: 6821 bytes --]
I've been thinking through how I feel about this for about a week now.
On one hand I've found a workflow that works for me for applying patches
to trees. Finding the patches is harder; I almost exclusively rely on
them being sent to me directly as part of the etc/teams script. When I
do go in search of patches I generally check qa.guix.gnu.org to see
what's building correctly, and I'll check my local maildir of patches.
My local maildir isn't great, all I have is unread is open, read is
closed. I have a snippet I use in mutt to flag bugs that are closed and
then I can mark them all read. This only works if an email was sent to
close the bug, not if it was closed using debbugs.el. I have about 29k
emails in my guix-patches directory and about 110k in the archive
directory for guix-patches. So to summarize, if a patch is sent to me
directly I have a workflow that I've worked out, but otherwise I almost
never look at the other patches, and even then I'm not always sure if
the patch is already applied or not.
I've never really had to use a webui (or Rich HTML Experience™) for
shared development previously, so the change is (don't say scary!) not
one that I'm looking forward to excitedly. At least it's not Gitlab,
which I've regularly had poor experiences with since either because of
using icecat or because my browser/GPU was too slow.
I packaged codeberg-cli (https://codeberg.org/Aviac/codeberg-cli) and
forgejo-cli (https://codeberg.org/Cyborus/forgejo-cli/) and generated a
token for codeberg-cli to try and test it out.
(ins)efraim@3900XT /tmp$ git clone https://codeberg.org/martianh/fj.el
Cloning into 'fj.el'...
(ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg --help
Codeberg CLI app
Usage: berg [OPTIONS] <COMMAND>
Commands:
api API subcommands
auth Authentication subcommands
config Config subcommands
user User subcommands
issue Issue subcommands
pull Pull request subcommands
label Label subcommands
repo Repository subcommands
milestone Milestone subcommands
notification Notification subcommands
completion Print completion script
help Print this message or the help of the given subcommand(s)
(ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg pull --help
Pull request subcommands
Usage: berg pull <COMMAND>
Commands:
list List pull requests
create Create a pull request
edit Edit pull request
view View details of a selected pull request
comment Add comment to selected pull request
help Print this message or the help of the given subcommand(s)
Options:
-h, --help Print help
(ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg pull view
? Select the desired pull request
> #79:main
#73:Minor fixes to 'fj-render-body'
#27:test PR: dev into main
#26:test PR dev into main
(ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg pull view
> Select the desired pull request #27:test PR: dev into main
┌─────────────────────┬─────────────────────┐
│ Pull Request ┆ │
│ #222527 ┆ │
╞═════════════════════╪═════════════════════╡
│ Title ┆ test PR: dev into │
│ ┆ main │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ Created ┆ 10.07.2024 (209 │
│ ┆ days ago) │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ Labels ┆ │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ Description ┆ │
└─────────────────────┴─────────────────────┘
(ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg pull comment
> Select the desired pull request #27:test PR: dev into main
? Open editor to write a comment [(e) to open vim, (enter) to submit]
┌───────────────────────────────────┐
│ Operation was interrupted by the │
│ user │
└───────────────────────────────────┘
(ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg notifications
error: unrecognized subcommand 'notifications'
tip: a similar subcommand exists: 'notification'
Usage: berg [OPTIONS] <COMMAND>
For more information, try '--help'.
(ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg notification --help
Notification subcommands
Usage: berg notification <COMMAND>
Commands:
list
view
help Print this message or the help of the given subcommand(s)
Options:
-h, --help Print help
(ins)efraim@3900XT /tmp/fj.el$ /gnu/store/061f8vbqkdmgb7k8qifyzsx4bfxsxacr-codeberg-cli-0.4.7/bin/berg notification list
┌──────────────────────────┐
│ Notification Threads │
│ (empty) │
╞══════════════════════════╡
└──────────────────────────┘
It looks like it's possible to interact with the majority of what I'd
want from the CLI anyway. As far as checking the webui, I have to check
qa.guix.gnu.org and other similar sites anyway to see about patch status
and available substitutes, and the codeberg site loads fast enough for
me. And it looks like I can create, read and comment on issues in a
repo using `berg issue` command so that actually sounds better than what
I have now.
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-05 10:36 ` Efraim Flashner
@ 2025-02-05 10:56 ` Cayetano Santos
2025-02-05 11:18 ` Efraim Flashner
0 siblings, 1 reply; 76+ messages in thread
From: Cayetano Santos @ 2025-02-05 10:56 UTC (permalink / raw)
To: Efraim Flashner; +Cc: Ludovic Courtès, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 557 bytes --]
>mer. 05 févr. 2025 at 12:36, Efraim Flashner <efraim@flashner.co.il> wrote:
> I packaged codeberg-cli (https://codeberg.org/Aviac/codeberg-cli) and
> forgejo-cli (https://codeberg.org/Cyborus/forgejo-cli/) and generated a
> token for codeberg-cli to try and test it out.
This is great, thanks ! Any plans to share the packages ? It would be
great for the community to test alternative tools before moving forward
in this thread.
--
Cayetano Santos
.
gpg: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682
key: meta.sr.ht/~csantosb.pgp
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-05 10:56 ` Cayetano Santos
@ 2025-02-05 11:18 ` Efraim Flashner
2025-02-05 14:27 ` Cayetano Santos
0 siblings, 1 reply; 76+ messages in thread
From: Efraim Flashner @ 2025-02-05 11:18 UTC (permalink / raw)
To: Cayetano Santos; +Cc: Ludovic Courtès, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
On Wed, Feb 05, 2025 at 11:56:40AM +0100, Cayetano Santos wrote:
>
> >mer. 05 févr. 2025 at 12:36, Efraim Flashner <efraim@flashner.co.il> wrote:
>
> > I packaged codeberg-cli (https://codeberg.org/Aviac/codeberg-cli) and
> > forgejo-cli (https://codeberg.org/Cyborus/forgejo-cli/) and generated a
> > token for codeberg-cli to try and test it out.
>
> This is great, thanks ! Any plans to share the packages ? It would be
> great for the community to test alternative tools before moving forward
> in this thread.
I've pushed them both to master (the packages, not the token).
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-05 11:18 ` Efraim Flashner
@ 2025-02-05 14:27 ` Cayetano Santos
0 siblings, 0 replies; 76+ messages in thread
From: Cayetano Santos @ 2025-02-05 14:27 UTC (permalink / raw)
To: efraim; +Cc: csantosb, guix-devel, ludo
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
Thanks !
I’ve been playing with them for a while: the experience is, well, to be
greatly improved, at a similar level to emacs fj.el.
I invite interested people to give them a try, in particular, when one
is reluctant to web forges.
guix pull && guix install codeberg-cli forgejo-cli
berg -V
fj version
--
Cayetano Santos
.
gpg: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682
key: meta.sr.ht/~csantosb.pgp
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [GCD] Migrating repositories, issues, and patches to Codeberg
2025-02-04 18:07 ` Vagrant Cascadian
@ 2025-02-06 4:31 ` Maxim Cournoyer
0 siblings, 0 replies; 76+ messages in thread
From: Maxim Cournoyer @ 2025-02-06 4:31 UTC (permalink / raw)
To: Vagrant Cascadian
Cc: Ricardo Wurmus, Divya Ranjan, Ludovic Courtès, Guix Devel
Hi Vagrant,
Vagrant Cascadian <vagrant@debian.org> writes:
> On 2025-02-04, Maxim Cournoyer wrote:
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>> I'm no stranger to debbugs and had previously built mumi (which powers
>>> issues.guix.gnu.org); we never managed to reach the same level of
>>> convenience. People send patches without X-Debbugs-Cc-ing the
>>> associated team and so patches wait for a review for months.
>>
>> Just to clarify, this shouldn't happen as long as the submission is made
>> via 'git send-email', which has a hook CC'ing team members based on the
>> scope via X-Debbugs-CC.
>
> Although, in my experience, if a long series touches many files, it
> "helpfully" sends only the patches that affect the team rather than the
> whole series, which then means I have to actually manually go dig out
> the rest of the patches somehow in order to actually apply them... the
> logic of it is not wrong, per se, but in practice it delays my ability
> to give any meaningful review...
Using Debbugs at least it's easy to recover the context by clicking on
the bug ID; if I'm in the doc team I may just look at the doc/guix.texi
change and not the full change.
That said, I think adding a X-Guix-Teams custom mail header containing
the names of the teams that are in scope for the change could be useful
sometimes. (to have it in the subject line would be even nicer but I
don't think 'git send-email' has any straightforward support for that
via hooks at the moment).
[...]
>
> I liked the guix-patches repository
> (https://git.guix-patches.cbaines.net/git/guix-patches) for this sort of
> workflow, but it was often missing patches, or worse, missing the most
> current proposed patches without any obvious way to know.
While the above tracker may be useful, I think in general it's probably
easier (perhaps safer, based on what you wrote), to simply apply the
latest revisions of a guix-patches thread using 'mumi current #number &&
mumi am'. It's smart enough to pull the latest revision.
Alternatively, you can use 'b4 shazam <message-id>', but retrieving the
message id has to be done via the raw message source or from the mumi
web interface (there's now a copy-message-id button making this a bit
easier). b4 shazam is also smart and will pick the latest revision
posted.
--
Thanks,
Maxim
^ permalink raw reply [flat|nested] 76+ messages in thread
end of thread, other threads:[~2025-02-06 4:32 UTC | newest]
Thread overview: 76+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-28 14:33 [GCD] Migrating repositories, issues, and patches to Codeberg Ludovic Courtès
2025-01-28 18:09 ` Leo Famulari
2025-01-28 21:08 ` Tomas Volf
2025-01-28 21:41 ` Tomas Volf
2025-01-30 7:35 ` Andreas Enge
2025-01-31 12:25 ` Giovanni Biscuolo
2025-01-31 13:27 ` Ekaitz Zarraga
2025-01-31 19:37 ` Cayetano Santos
2025-01-30 21:28 ` Suhail Singh
2025-02-03 17:50 ` Ludovic Courtès
2025-01-28 23:32 ` Tomas Volf
2025-01-29 3:05 ` Ian Eure
2025-02-03 21:00 ` Ludovic Courtès
2025-01-29 9:19 ` Cayetano Santos
2025-02-03 21:03 ` Ludovic Courtès
2025-02-04 13:13 ` Maxim Cournoyer
2025-02-04 17:02 ` Suhail Singh
2025-01-29 9:55 ` Steve George
2025-01-29 10:08 ` Divya Ranjan
2025-01-29 11:10 ` Ricardo Wurmus
2025-01-30 10:42 ` Divya Ranjan
2025-02-04 12:54 ` Maxim Cournoyer
2025-02-04 18:07 ` Vagrant Cascadian
2025-02-06 4:31 ` Maxim Cournoyer
2025-01-29 11:24 ` 45mg
2025-02-02 11:13 ` Ricardo Wurmus
2025-01-29 17:34 ` Noé Lopez via Development of GNU Guix and the GNU System distribution.
2025-02-03 21:16 ` Ludovic Courtès
2025-01-29 21:27 ` Liliana Marie Prikler
2025-02-03 21:20 ` Ludovic Courtès
2025-01-30 5:22 ` Thanos Apollo
2025-01-30 6:48 ` Ricardo Wurmus
2025-01-30 9:02 ` Ekaitz Zarraga
2025-02-03 14:47 ` Cayetano Santos
2025-01-30 13:13 ` Simon Tournier
2025-02-03 21:32 ` Ludovic Courtès
2025-01-30 16:56 ` Christopher Baines
2025-02-03 21:38 ` Ludovic Courtès
2025-01-30 21:48 ` Suhail Singh
2025-01-31 15:10 ` Suhail Singh
2025-01-31 16:37 ` Attila Lendvai
2025-01-31 18:09 ` Suhail Singh
2025-01-31 18:43 ` Attila Lendvai
2025-01-31 19:46 ` Suhail Singh
2025-02-03 21:47 ` Ludovic Courtès
2025-02-03 23:25 ` Suhail Singh
[not found] ` <87frkzhvb8.fsf@housseini.me>
2025-01-31 15:12 ` reza
2025-01-31 20:43 ` Tomas Volf
2025-02-01 11:37 ` 45mg
2025-02-01 12:37 ` Tomas Volf
2025-02-01 13:19 ` 45mg
2025-02-03 16:19 ` Christopher Howard
2025-02-03 20:07 ` Ricardo Wurmus
2025-02-03 21:18 ` Tomas Volf
2025-02-01 9:44 ` Lars-Dominik Braun
2025-02-01 18:28 ` Leo Famulari
2025-02-02 10:13 ` Lars-Dominik Braun
2025-02-02 22:41 ` Leo Famulari
2025-02-03 17:24 ` Lars-Dominik Braun
2025-02-01 12:54 ` Carlo Zancanaro
2025-02-03 21:51 ` Ludovic Courtès
2025-02-02 14:12 ` paul
2025-02-02 15:02 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2025-02-02 15:50 ` Suhail Singh
2025-02-02 22:37 ` Leo Famulari
2025-02-03 1:38 ` Suhail Singh
2025-02-03 1:45 ` Leo Famulari
2025-02-02 22:14 ` Leo Famulari
2025-02-02 23:44 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2025-02-03 1:39 ` Leo Famulari
2025-02-04 10:11 ` Ludovic Courtès
2025-02-02 15:19 ` Suhail Singh
2025-02-05 10:36 ` Efraim Flashner
2025-02-05 10:56 ` Cayetano Santos
2025-02-05 11:18 ` Efraim Flashner
2025-02-05 14:27 ` Cayetano Santos
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).