GNU bug report logs -
#76503
[GCD] Migrating repositories, issues, and patches to Codeberg
Previous Next
To reply to this bug, email your comments to 76503 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-devel <at> gnu.org, guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 23 Feb 2025 15:21:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ludovic Courtès <ludo <at> gnu.org>:
New bug report received and forwarded. Copy sent to
guix-devel <at> gnu.org, guix-patches <at> gnu.org.
(Sun, 23 Feb 2025 15:21:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Guix!
This is the formal submission of “Migrating repositories, issues, and
patches to Codeberg” (GCD 002), a preliminary draft of which I posted
before the Guix Days⁰.
In accordance with the GCD Process, discussion will end on April 23rd at
the latest.
I would like to remind everyone that you can try out Codeberg either by
contributing to one of the Guix-Science repositories¹, or by reviewing
or making a pull request for a trivial packaging change (and nothing
more!) in my Guix clone at Codeberg:
https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00313.html
Please do try it especially if you feel reluctant or wonder what the
workflow would be like.
Ludo’.
⁰ https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00218.html
¹ https://codeberg.org/guix-science
[002-codeberg.md (text/plain, inline)]
title: Migrating repositories, issues, and patches to Codeberg
id: 002
status: submitted
discussion: https://issues.guix.gnu.org/<number assigned by issue tracker>
authors: Ludovic Courtès
sponsors: Tobias Geerinckx-Rice, Ricardo Wurmus
date-submitted: 2025-02-23
date: 2025-02-23
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later
---
# 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. Such a system is necessarily
more *complex* at first glance than the email-based tools we have but
(1) the increase in complexity is reasonable once we consider the
incidental complexity of the existing services, as mentioned above, and
(2) we think the added usage benefits outweigh this increase in
complexity.
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 to https://codeberg.org/guix.
For Guix itself, we would decide on a **flag day** 14 days after
acceptance of this GCD at the earliest, and 30 days at the latest. On
that day, the official URL of the Guix repository would become
https://codeberg.org/guix/guix.git. A commit would reflect that by
updating:
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,
in particular in the manual.
To ease this migration and possibly future migration, we may add a new
`git.guix.gnu.org` DNS entry with HTTP redirects to
`git.savannah.gnu.org` (before migration) and `codeberg.org` (after
migration); a [patch](https://issues.guix.gnu.org/76296) implementing
this has been submitted. The `%default-channel-url` variable would
refer to `https://git.guix.gnu.org/guix.git`.
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 for **at least one
year** after the switch, as a way to ease migration to the new
repository for users. Other repositories would be deleted from Savannah
once migrated, to avoid confusion.
## 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 <at> debbugs.gnu.org`.
- The switchover will be advertised before it takes place with a post
to `info-guix <at> gnu.org`, to `guix-devel <at> gnu.org`, as well as through
a blog post.
- The “Contributing” section of the manual will be updated accordingly
at that time.
## User Interfaces
For many contributors, a strength of the email-based workflow is that it
works out of the browser, possibly offline; we want to preserve that
comfort as much as possible.
Everything that can be done through Forgejo’s web interface can be done
*via* its [HTTP
interface](https://forgejo.org/docs/latest/user/api-usage/). This has
given rise to several Emacs and command-line interfaces that existing
contributors may find convenient.
[forgejo-cli](https://codeberg.org/Cyborus/forgejo-cli/) and
[codeberg-cli](https://codeberg.org/Aviac/codeberg-cli) provide rather
comprehensive command-line interfaces, as [reported by
Efraim](https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00057.html).
[fj.el](https://codeberg.org/martianh/fj.el/) is an Emacs interface
similar to `mastodon.el` that lets you view and comment on issues and
pull requests, list repositories, view notifications, and so on. It
does not support off-line access. It can be set up with something like:
```lisp
(with-eval-after-load 'fj
(setq fj-host "https://codeberg.org")
(setq fj-user "civodul")
(setq fj-token
(funcall (plist-get
(car
(auth-source-search :host "codeberg.org/api/v1"
:user fj-user
:type 'netrc))
:secret))))
```
… and a line like this one to `~/.authinfo.gpg`:
```
machine codeberg.org/api/v1 login civodul password TOKEN
```
… where `TOKEN` is the [token obtained from
Codeberg](https://docs.codeberg.org/advanced/access-token/).
[Magit-Forge](https://github.com/magit/forge/) is another Emacs
interface to forges, with Magit integration and support for working
off-line. However, Forgejo support is currently next to nonexistent:
only `forge-browse` is supported (allowing users to open a browser on a
forge page).
Besides these interfaces, there is a couple of tricks that can simplify
the life of contributors and reviewers, out of the browser.
As a contributor, you can create pull requests without first creating a
fork and then a merge request thanks to the [AGit
workflow](https://forgejo.org/docs/latest/user/agit-support/). This
works by passing `git push` the relevant *options*, as in this example:
```
git push origin HEAD:refs/for/main \
-o topic="update-hello" \
-o title="gnu: hello: Update to 42." \
-o description='This updates the `hello` package."
```
As a reviewer, it is possible to pull references of pending pull
requests by adding something like this to `.git/config`:
```
[remote "pulls"]
url = git <at> codeberg.org:org/guix-science/guix-science.git
fetch = +refs/pull/*/head:refs/remotes/pulls/pr/*
```
Running `git fetch pulls` then retrieves references to branches
corresponding to all the pull requests.
## 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).
Note that 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.
If and when the project migrates, we will incrementally adjust our
workflow to ensure it scales better.
## 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.
First, everyone will have to create an account and accept [Codeberg’s
Terms of
Use](https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md)
before they can contribute, which can be seen as a step back compared to
the email-based workflow.
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, by setting a joint team to
monitor resource consumption induced by Guix and discuss any issues
encountered by either parties proactively, or by [joining
it](https://join.codeberg.org/) as an active member with voting rights.
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.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 23 Feb 2025 22:03:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo’,
I think this is an excellent proposal. I've contributed over the years to Guix by sending email patches to debbugs, but I usually forgot each time exactly the best practices and usually someone (often you) has had to amend them slightly before merging. (And then I've got stuck contributing things like the `python-ical2orgpy', which required writing definitions for its python package dependencies, and figuring out how to properly send the patch series.) And finding things in email is often more cognitively difficult to keep all the pieces and steps involved in doing it properly. Since I've used to forge-based workflows from contributing to other projects, I think this would significantly reduce barriers for managing to actually getting round to contribute upstream. (I've got my own channel I use for things and a whole Org TODO list of things I want to submit upstream.)
I would also think a forge could make review and merge workflows smoother.
I'm very excited about this possibility. Thanks again for this proposal!
best,
—Benjamin
--
'(Dr Benjamin Slade (he/him)
(website . <https://lambda-y.net>)
`(pgp_fp: ,(B20E 444C FA80 B5F8 15FA 4AD8 6FBF CD68 3B05 2B84))
"sent by [mu4e] 1.12.8 in [Emacs] 30.0.93 with [org-msg] on [GNU Guix] ([Linux])")
[mu4e] <https://www.djcbsoftware.nl/code/mu/mu4e.html>
[Emacs] <https://www.gnu.org/software/emacs/>
[org-msg] <https://github.com/jeremy-compostella/org-msg>
[GNU Guix] <https://guix.gnu.org/>
[Linux] <https://opensource.com/resources/linux>
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 25 Feb 2025 10:51:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
I am also in favour of this proposal. The email-based workflow was not
easy for me.
It requires significant configuration with Emacs or Vim, so that
convinience is unavailable folks who use text editors like VSCode,
Helix, Kakoune or Micro.
Forge-based workflow removes that cognitive load, and the focus stays
on the project itself.
I am fairly positive that if this proposal is accepted by a majority of
this community, it would improve the contributor's experience.
Regards,
Ashvith
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 25 Feb 2025 14:04:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
First off, full disclosure: Along with Ricardo, I wrote most of mumi and
the underlying guile libraries. So, I am simultaneously saddened and
relieved that we are deprecating mumi and moving to Codeberg—saddened
because mumi was many years of work, and relieved because I do not have
to bear any responsibility for the future! So, very mixed feelings. :-)
And, while I strongly prefer the email workflow, I concede that moving
to a pull request workflow will lower the barrier to entry simply
because it is more familiar thanks to GitHub's dominant mindshare. So,
unless there is significant support for mumi and the email workflow, I
will stand aside and go with the flow of the community. That said, my
arguments against Codeberg follow.
GitHub invented the fork+pull-request workflow. Despite git's
under-the-hood hardlinking magic, the pull request workflow is very
expensive in terms of disk space. Every fork takes up disk space, and we
need one fork per contributor. That's an enormous amount of disk space.
Now, I would think git's object storage model makes it easy to
deduplicate storage. But apparently, it's not that simple. GitHub does
complex software engineering behind the scenes to make it all seem easy.
See [1] for details. Cash-strapped and labour-starved community projects
like Codeberg/Forgejo don't (yet?) have the means to replicate such
cloud-scale software engineering. In fact, I am not speculating here;
Codeberg openly mentions this in [2]. Codeberg is already strapped for
storage and is introducing storage quotas[3] to make up for it.
The storage issue is particularly pertinent considering how big of a
project we are and how big our git repo is. At this moment, our git repo
is close to 1 GiB in size. Incidentally, that's already bigger than the
750 MiB Codeberg storage quota. Codeberg is willing to allocate more
storage on a per-project basis, but you have to request for it. Now, we
have a little more than 1K contributors. That means, we are already up
to 1 TiB in storage. That's enormous, especially considering that all
data on Codeberg combined adds up to only 12 TiB[3]. And, for
comparison, all our substitutes stored up from the founding of Guix only
add up to about 25 TiB[4]. Now, imagine we had a 10-fold increase in
contributors—a prospect that's pretty easy considering drive-by
contributors—we would be up to 10 TiB in storage for our git repo.
That's ginormous! We would be putting a lot of stress on a tiny
community organization.
Then, there's the bandwidth issue as well. Our git repo is not merely a
development repo. Every Guix user clones[5] it and pulls from it
regularly. As the Guix userbase grows, this will be an increasingly
heavy toll on Codeberg's bandwidth. [2] already alludes to occasional
slowness when the load is high. Even if we move to Codeberg, we should
maintain a mirror of the git repo on our own machines that is actually
capable of serving a large userbase.
I was present with Ludo and others when we visited the Codeberg stall at
FOSDEM, and enquired about the possibility of hosting Guix on Codeberg.
The person at the stall was hesitant about our large repo, and our many
users. In fact, in order to save on disk space, they suggested that we
encourage our contributors to delete their forks once done. :-D Needless
to say, that's never going to happen!
As well-intentioned as Codeberg is, a single non-profit hoping to host
all the git repos in the world in perpetuity and free of charge is a
very tough proposition. Technical solutions like federation that may
mitigate this are unlikely to materialize, especially in the short term.
More likely, Codeberg may go the way of Matrix, where federation is
possible in theory, but matrix.org is the only server in practice.
It would be nice if we were just a normal software project that could
fit well into a traditional forge. But, we are not. We are a
"distribution", and "distributing" is part of our core competency.
Critical parts of our distribution infrastructure should be directly
under our own control. We are a large enough and specialized enough
organization that this is necessary.
[1]: https://github.blog/open-source/git/counting-objects/
[2]: https://blog.codeberg.org/the-hardest-scaling-issue.html
[3]:
https://blog.codeberg.org/more-power-for-you-what-a-storage-quota-will-bring.html
[4]: number from Chris Baines
[5]: Quick digression: Users must actually download about 1 GiB of data
on their first guix pull. That's frustrating to new users, and
effectively excludes users from parts of the world where a good Internet
connection cannot be taken for granted.
Cheers,
Arun
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 25 Feb 2025 14:36:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Arun,
> GitHub invented the fork+pull-request workflow. Despite git's
> under-the-hood hardlinking magic, the pull request workflow is very
> expensive in terms of disk space.
With the AGit workflow we can open pull requests without a prior fork.
I've done this before on the Guix Science channel:
https://codeberg.org/guix-science/guix-science/pulls/71
There is a little "AGit" tag linking to
https://forgejo.org/docs/latest/user/agit-support/
The downside of using the AGit workflow is that it requires using an
unwieldy command, but personally I find it less cumbersome than the
common pull request workflow with an extra fork, clone of the fork (or
registering of an "upstream" remote), push to the fork, then pull
request from fork to upstream.
Your points about storage limits are important, though. We may have to
disable on-platform forks to nudge contributors to the AGit workflow.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 25 Feb 2025 15:04:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> The storage issue is particularly pertinent considering how big of a
> project we are and how big our git repo is.
Agit workflow is something to consider. Still, I wonder how Github
educated people, reluctant to email exchange, will react to a
git push origin HEAD:refs/for/<target-branch>/<session>
based workflow, and if this really lowers the barrier to entry[1].
> Then, there's the bandwidth issue as well.
Would it be a valid option to keep N mirrors, all in sync, aside from
the main repo ? Upon pulling, you randomly hit one of them. Is there a
reason to avoid this approach (even now) ?
> As well-intentioned as Codeberg is ...
Fully agree.
C.
[1] https://git-repo.info/en/2020/03/agit-flow-and-git-repo/
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 25 Feb 2025 15:38:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 76503 <at> debbugs.gnu.org (full text, mbox):
> On Feb 25, 2025, at 10:04 AM, Cayetano Santos via Guix-patches via <guix-patches <at> gnu.org> wrote:
> Still, I wonder how Github
> educated people, reluctant to email exchange, will react to a
>
> git push origin HEAD:refs/for/<target-branch>/<session>
>
> based workflow, and if this really lowers the barrier to entry[1].
The linked page refers to a tool called “git-repo”, which smooths out the more technical bits to commands like “git pr”. From appearances it seems like using this tool is lower-investment for users than configuring (or changing!) their email client to interact with mailing lists and the mail-in patch workflow properly. It also helps that this (optional?) special tool is more “orthogonal” to other workflows, rather than involving something as central as emails.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 25 Feb 2025 19:07:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On Tue, Feb 25, 2025 at 02:03:02PM +0000, Arun Isaac wrote:
> And, while I strongly prefer the email workflow, I concede that moving
> to a pull request workflow will lower the barrier to entry simply
> because it is more familiar thanks to GitHub's dominant mindshare. So,
> unless there is significant support for mumi and the email workflow, I
> will stand aside and go with the flow of the community. That said, my
> arguments against Codeberg follow.
I think we have similar feelings here. I'll miss living inside of Mutt
but I think we are losing a lot by not using a web-based platform.
> Now, we have a little more than 1K contributors. That means, we are
> already up to 1 TiB in storage. That's enormous, especially
> considering that all data on Codeberg combined adds up to only 12
> TiB[3].
I disagree that 1 TiB, or even 10 TiB, is enormous. It's certainly
large, but it's "entry-level" for a web service with 1000 users in 2025.
And a 10 TiB hard drive only costs ~$200. I know that's is a lot for
some people and places, but it's nothing for something like this. The
blog post you linked to even says "But storage is cheap!" And it really
is the cheapest thing in computing these days.
If Codeberg is really only hosting 12 TiB, then I suggest that either 1)
they can't handle Guix or 2) they are ready to scale up. And Guix should
think about helping them with scaling capital if necessary.
> I was present with Ludo and others when we visited the Codeberg stall at
> FOSDEM, and enquired about the possibility of hosting Guix on Codeberg.
> The person at the stall was hesitant about our large repo, and our many
> users. In fact, in order to save on disk space, they suggested that we
> encourage our contributors to delete their forks once done. :-D Needless
> to say, that's never going to happen!
Interesting, that's not the impression I got from other emails from
people who were there. We need to clear this up with Codeberg now if we
want to make this change. It sounds like we would be their first
medium-sized user (I don't consider Guix to be large). Like I said, we
should be ready to offer help with fundraising.
> As well-intentioned as Codeberg is, a single non-profit hoping to host
> all the git repos in the world in perpetuity and free of charge is a
> very tough proposition.
Well, we already are in that position: we depend on the FSF completely
for our Git hosting.
https://projects.propublica.org/nonprofits/organizations/42888848
> Critical parts of our distribution infrastructure should be directly
> under our own control. We are a large enough and specialized enough
> organization that this is necessary.
I think it would be great if we could do this, but I haven't seen any
evidence that we can. In my years with Guix, we have always struggled to
operate our infrastructure. Also, I'll point out that it is an opinion,
not a fact, that we "should" do this. Very few free software projects
host their own Git servers. But like I said, the prospect does appeal to
me. But I don't volunteer to do it :)
> [5]: Quick digression: Users must actually download about 1 GiB of data
> on their first guix pull. That's frustrating to new users, and
> effectively excludes users from parts of the world where a good Internet
> connection cannot be taken for granted.
Like I've said several times in this discussion so far, we should look
into the state of the art of shallow cloning. It might be efficient
enough on the server-side these days to be the smart move. I agree that
downloading 1 GB in this context is bad.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 26 Feb 2025 00:35:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Leo,
> I disagree that 1 TiB, or even 10 TiB, is enormous. It's certainly
> large, but it's "entry-level" for a web service with 1000 users in 2025.
> And a 10 TiB hard drive only costs ~$200. I know that's is a lot for
> some people and places, but it's nothing for something like this. The
> blog post you linked to even says "But storage is cheap!" And it really
> is the cheapest thing in computing these days.
Aha, I'm not sure you read that article[1] carefully! :-) The very next
sentence immediately after "But storage is cheap!" is "It is not",
followed by "All data on Codeberg probably fits into a 12 TB drive".
That paragraph actually goes on to explain why storage is *not* cheap
and why it's more complicated than just buying a few more disks.
[1]:
https://blog.codeberg.org/more-power-for-you-what-a-storage-quota-will-bring.html
>> As well-intentioned as Codeberg is, a single non-profit hoping to host
>> all the git repos in the world in perpetuity and free of charge is a
>> very tough proposition.
>
> Well, we already are in that position: we depend on the FSF completely
> for our Git hosting.
True. I'm not saying our current situation is great. But, at least the
FSF is not planning to try and host all the world's git repos! That's
the point I'm making here.
>> [5]: Quick digression: Users must actually download about 1 GiB of data
>> on their first guix pull. That's frustrating to new users, and
>> effectively excludes users from parts of the world where a good Internet
>> connection cannot be taken for granted.
>
> Like I've said several times in this discussion so far, we should look
> into the state of the art of shallow cloning. It might be efficient
> enough on the server-side these days to be the smart move. I agree that
> downloading 1 GB in this context is bad.
Good idea. I don't know if our `guix authenticate' security model would
still work with a shallow clone. But, it's worth exploring.
Regards,
Arun
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 26 Feb 2025 00:42:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ricardo,
> With the AGit workflow we can open pull requests without a prior fork.
Interesting. I didn't know this was possible. If we can require all our
users to do this and disable forking of our repo, then that might solve
all our storage issues.
Regards,
Arun
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 26 Feb 2025 00:46:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Cayetano,
> Would it be a valid option to keep N mirrors, all in sync, aside from
> the main repo ? Upon pulling, you randomly hit one of them.
Yes, that could be one possible solution. Another solution could be to
have a single URL but load balance at the DNS level based on your IP
address provided location.
> Is there a reason to avoid this approach (even now) ?
Not that I'm aware of.
Regards,
Arun
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 26 Feb 2025 10:34:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Arun Isaac <arunisaac <at> systemreboot.net> writes:
>> Like I've said several times in this discussion so far, we should look
>> into the state of the art of shallow cloning. It might be efficient
>> enough on the server-side these days to be the smart move. I agree that
>> downloading 1 GB in this context is bad.
>
> Good idea. I don't know if our `guix authenticate' security model would
> still work with a shallow clone. But, it's worth exploring.
If shallow cloning leads to a truncated commit history that doesn't
include the current introductory commit
(9edb3f66fd807b096b48283debdcddccfea34bad), then you'd need to specify a
later commit as the introductory commit during the first run of `guix
git authenticate`. Other than that, it should still work.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 26 Feb 2025 20:51:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 76503 <at> debbugs.gnu.org (full text, mbox):
45mg <45mg.writes <at> gmail.com> skribis:
> If shallow cloning leads to a truncated commit history that doesn't
> include the current introductory commit
> (9edb3f66fd807b096b48283debdcddccfea34bad), then you'd need to specify a
> later commit as the introductory commit during the first run of `guix
> git authenticate`. Other than that, it should still work.
In practice, it always starts from the current commit. That is, if you
install 1.4.0, it assumes that the corresponding commit is authentic and
starts from there, rather than from the introductory commit. IOW, you
only need the history up to a known-good commit.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 26 Feb 2025 21:03:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Arun,
Thanks for your feedback.
First, thank you and Ricardo for mumi. I didn’t write a single line of
it but I certainly encouraged it, enjoyed it (the version you deployed
yesterday or so is super nice, BTW!), and for a long time saw it as the
key to providing a good contributor experience “to those who don’t like
email”.
I think I was/we were wrong in two ways: first it’s not just about
providing a web interface, and second there are limitations in our
workflow that we just cannot overcome, as I tried to explain in the
“Motivation” section. We tried, very hard, and for a reason: a belief
(as far as I’m concerned) that we could not only be responsible for our
infra but also, in a way, that we could show fellow free software
hackers that an alternative development model was possible.
Your message raises concerns about the storage/bandwidth requirements of
Guix and the ability of a non-profit to keep up.
I agree with Leo and the GCD mentions it as well: we need to talk with
Codeberg e.V. from the start, possibly becoming a voting member, and to
offer funding. FWIW, we’re at 600 MiB¹ out of the 750 MiB quota². The
GCD documents AGit; we could make it the recommended way to contribute,
if that helps.
Will Codeberg manage to keep up? We don’t know. It’s not the first
non-profit doing it though. Framasoft has been running a popular GitLab
instance³ with 76k projects for 53k people⁴; its budget is higher but
they’re also doing primarily things unrelated to source code hosting.
Codeberg e.V. is specialized so I’d like to believe they have a lot of
headroom. That they’re transparent and upfront about their scalability
issues is a rather good sign to me.
Assuming we agree that a move along the lines of this proposal is
desirable (let me know if you think we don’t share that premise), what
other options would you think of?
Ludo’.
¹ https://codeberg.org/guix/guix-mirror
² https://blog.codeberg.org/more-power-for-you-what-a-storage-quota-will-bring.html
³ https://framagit.org/
⁴ https://framablog.org/2024/12/28/framasoft-en-chiffres-edition-2024/
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 27 Feb 2025 01:45:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
> First, thank you and Ricardo for mumi. I didn’t write a single line of
> it but I certainly encouraged it, enjoyed it (the version you deployed
> yesterday or so is super nice, BTW!), and for a long time saw it as the
> key to providing a good contributor experience “to those who don’t like
> email”.
Thank you, I appreciate it. :-) I have more improvements (filtering
issues by team, for instance) in the pipeline, and will probably deploy
them in another week or so.
> Your message raises concerns about the storage/bandwidth requirements of
> Guix and the ability of a non-profit to keep up.
>
> I agree with Leo and the GCD mentions it as well: we need to talk with
> Codeberg e.V. from the start, possibly becoming a voting member, and to
> offer funding.
Good points, I agree.
> Codeberg e.V. is specialized so I’d like to believe they have a lot of
> headroom.
> That they’re transparent and upfront about their scalability issues is
> a rather good sign to me.
I agree. I liked the honesty of the person we met at the FOSDEM stall.
And, I like it that their blog discusses their scaling issues openly.
> Assuming we agree that a move along the lines of this proposal is
> desirable (let me know if you think we don’t share that premise), what
> other options would you think of?
I think we share the premise. I am not fundamentally opposed to the
proposal in any way. Lowering the barrier to entry and making the
project more accessible is a good thing. But…
According to the survey, only 9% want a pull request workflow, while 20%
just want timely reviews. My hunch (I have no data or proof) is that the
9% would also be perfectly happy if we just provide them timely reviews.
And, to provide timely reviews, we need to be focussing on entirely
different things—for example, the infinite growth of our package
collection and the strictness of our code reviews. If we could decompose
Guix into smaller channels, some of which have less stringent review
processes, we may get much faster reviews. To some extent, we see this
already in channels such as guix-science (less stringent review),
guix-cran (no review!), etc. Centralization of review and decision
making does not scale well. To grow, we need to devolve power. One day,
we aim to be as big as or bigger than Debian. We cannot do that without,
in some way, imitating their organizational structure. Shovelling more
coal into the fire may not be enough. It might work for a bit, but then
we'll just hit another limit and be stuck again. And, considering the
counterintuitive speed of exponential growth, we may reach that new
limit in no time. Some version of
https://en.wikipedia.org/wiki/Amdahl%27s_law applies here.
The proposal mentions better automation of our review process. But, many
of our review processes are not automatable—at least not easily so. For
example: the avoidance of marketing language in synopses and
descriptions, the listing of licenses for every single file in the
source tarball, the indentation of code[1], etc. Some rules such as the
use of double space[2] are antiquated and can be dropped with no
consequence. Our baroque Changelong format is another target of much ire
(even though I personally like it enough to use it in my own projects!).
[1]: there's human judgement involved (and for good reason) despite guix
style and other tools
[2]: Even the behaviour of Emacs sentence commands are not much of an
excuse here. I found out recently about the
sentence-end-double-space variable.
The Codeberg move aims to make it easier for contributors. But, if
anything, we already have too many contributions and are unable to keep
up with reviews! :-D Codeberg is likely to increase the number of
contributors without significantly increasing the number of reviewers. I
cannot be sure of this, nor can I provide much in the way of proof; only
time will tell.
I am sure a move to Codeberg can be seen as orthogonal to all these
concerns. And, perhaps it is. But, I'm just saying we should discuss the
limitations of this approach and be more aware of the larger
bottlenecks. What if we're throwing away the email workflow for nothing!
[half kidding] ;-)
Requiring the agit workflow and disallowing forks (preferably enforced
by technical means), thus solving the storage problem, would remove my
most important grievances with this proposal. I don't mean to block this
proposal at all. Let us proceed.
Thank you for your time and your patience.
Cheers!
Arun
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 27 Feb 2025 11:18:04 GMT)
Full text and
rfc822 format available.
Message #50 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Arun Isaac <arunisaac <at> systemreboot.net> writes:
> According to the survey, only 9% want a pull request workflow, while 20%
> just want timely reviews. My hunch (I have no data or proof) is that the
> 9% would also be perfectly happy if we just provide them timely reviews.
The thing is, moving to Codeberg isn't just about the pull-request
workflow. I don't really care about that. What I care about is having a
/forge/, and all the features that come with it.
A forge would make the collaboration process far more accessible,
because it would provide a decent default experience for every
contributor (ie. the web interface). There would be no need to set up
isync/offlineimap/whatever + Notmuch/Mu4e/GNUs/mutt/whatever just for
the bare minimum of a decent UI for plain-text email.
And then, there are the additional features provided by a forge, which
are very difficult to provide in an email-based workflow. For example,
tagging issues. We have Debbugs usertags, but the majority of
contributors will not see them, because they'd have to use the Debbugs
web interface - and I struggle to imagine anyone ever doing that
willingly. I have tried to set up debbugs.el, but I couldn't get it
working the last time I tried, and frankly I don't have the energy to
configure even more Emacs-specific tooling that I will never use
anywhere else (as if contributing isn't difficult enough for non-Emacs
users...). Perhaps this is why I've observed that usertags don't really
get used much, outside of QA reviews maybe ('reviewed-looks-good').
Now compare this with the situation on GitHub or Codeberg, where there's
a web interface that even a child could figure out, that shows the same
view to everyone. So if you tag issues, you can be sure that everyone
will see the tags. It's that simple.
Also, more reliable and integrated QA would probably make a big
difference, since QA seems to be how committers find out whether a
series is ready to apply. While qa.guix.gnu.org is very impressive for a
volunteer effort, it suffers from a lot of issues that don't really
happen in modern forges (eg. failing to detect or apply patches from a
Debbugs submission), and we don't seem to have enough bandwidth to
improve it. A forge would provide most of what it does, and it would be
directly integrated with the rest of the tooling.
> And, to provide timely reviews, we need to be focussing on entirely
> different things—for example, the infinite growth of our package
> collection and the strictness of our code reviews. If we could decompose
> Guix into smaller channels, some of which have less stringent review
> processes, we may get much faster reviews. To some extent, we see this
> already in channels such as guix-science (less stringent review),
> guix-cran (no review!), etc. Centralization of review and decision
> making does not scale well. To grow, we need to devolve power. One day,
> we aim to be as big as or bigger than Debian. We cannot do that without,
> in some way, imitating their organizational structure.
Could you share what aspects of Debian's organizational structure you'd
like us to mirror? I agree that decentralization is good in principle,
but I'm concerned about needlessly fragmenting the community. I'm not
familiar with how things work in Debian-land. If they've managed to
solve this problem, it'd be good for all of us to know about.
> The Codeberg move aims to make it easier for contributors. But, if
> anything, we already have too many contributions and are unable to keep
> up with reviews! :-D Codeberg is likely to increase the number of
> contributors without significantly increasing the number of reviewers. I
> cannot be sure of this, nor can I provide much in the way of proof; only
> time will tell.
As I mentioned above, I think features like tagging, reliable detection
of merge conflicts, and a decent and consistent interface would remove a
lot of the friction involved in contribution/review. And since reviewers
are also contributors, a nicer and more efficient contribution process
would mean more time and energy left over for review.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 27 Feb 2025 13:38:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On Wed, Feb 26, 2025, at 20:44, Arun Isaac wrote:
> The proposal mentions better automation of our review process. But, many
> of our review processes are not automatable—at least not easily so. For
> example: the avoidance of marketing language in synopses and
> descriptions, the listing of licenses for every single file in the
> source tarball,
A minor point for those reading along: we do not list the licenses of every single file in source tarballs. We only describe the license of the package.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 27 Feb 2025 14:42:03 GMT)
Full text and
rfc822 format available.
Message #56 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-27 01:44, Arun Isaac wrote:
> Hi Ludo,
>
>> First, thank you and Ricardo for mumi. I didn’t write a single line of
>> it but I certainly encouraged it, enjoyed it (the version you deployed
>> yesterday or so is super nice, BTW!), and for a long time saw it as the
>> key to providing a good contributor experience “to those who don’t like
>> email”.
>
> Thank you, I appreciate it. :-) I have more improvements (filtering
> issues by team, for instance) in the pipeline, and will probably deploy
> them in another week or so.
TY!
Just a light comment on improvements, since I talked about that at Guix
Paris recently. One of the things is also the improvements on the
GNU/Debbugs side. On sourcehut, the server is able to recognise a patch
series / thread despite git send-email sending everything at once, since
the Message-ID contains the patch number in the series.
Is there someone working on that side? Would be weird if not, more than
5 years after Sourcehut has started.
FYI, I'm delving into both piem and emacs-git-email with 4 bugs sent
upstream (2 fixed already, 2 in the process). They are great tools, but
I've felt like many frustrated because of their lack of polish. Will
keep this up in the coming months.
--
Best regards,
Nicolas Graves
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 28 Feb 2025 22:35:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Arun,
Arun Isaac <arunisaac <at> systemreboot.net> skribis:
>> Assuming we agree that a move along the lines of this proposal is
>> desirable (let me know if you think we don’t share that premise), what
>> other options would you think of?
>
> I think we share the premise. I am not fundamentally opposed to the
> proposal in any way. Lowering the barrier to entry and making the
> project more accessible is a good thing. But…
You say “not fundamentally opposed”, but I’d like to stress that the
process is not about agreeing/disagreeing on an immutable proposal; it’s
about building it together to into account our concerns and needs.
> According to the survey, only 9% want a pull request workflow, while 20%
> just want timely reviews. My hunch (I have no data or proof) is that the
> 9% would also be perfectly happy if we just provide them timely reviews.
There are many factors contributing to the lack of timely reviews. As
someone reviewing patches every week and who also tried the PR model and
tools despite a natural aversion, I can tell that tools play a role.
Examples: I easily lose track of updated patch versions and comments
because they’re just more unread email in my inbox; contributors
sometimes lose track of what they sent, so they open a new issue, and I
find myself digging for the original submission and review; people
comment on each other’s issues but there’s no way to know unless you
read every single message. And the list goes on.
Annoyances like this make reviewing tedious and discouraging.
These specific issues go away on Codeberg and similar platforms. Will
that be enough to achieve timely reviews? No, but I’m sure it can help.
(BTW, you should give Codeberg a try, as I mentioned in the cover
letter. It would ensure we’re all on the same page.)
[...]
> The proposal mentions better automation of our review process. But, many
> of our review processes are not automatable—at least not easily so.
I agree. And it’s also true that the important bit, qa.guix, does not
require Codeberg to exist. A “modern forge” just makes it easier to
automate things and to integrate them with the contribution workflow.
[...]
> Requiring the agit workflow and disallowing forks (preferably enforced
> by technical means), thus solving the storage problem, would remove my
> most important grievances with this proposal.
I don’t think there’s a “storage problem”. There’s a storage risk, and
it’s one of several—there are other ways Codeberg could fail, some are
spelled out in the GCD.
In my view, what we need to do during the discussion period is to find
ways to mitigate and deal with those risks in the months and years to
come. We already discussed the storage risk before; what more do you
think should be done?
How would you amend the proposal to better address this and other
concerns your raised?
Thank you,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sat, 01 Mar 2025 00:06:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
> You say “not fundamentally opposed”, but I’d like to stress that the
> process is not about agreeing/disagreeing on an immutable proposal; it’s
> about building it together to into account our concerns and needs.
Indeed, my bad. Sorry.
The only amendment I would strongly recommend is to require the agit
workflow in order to mitigate the storage problem/risk. This may require
changes to Forgejo. I say this without ever having used the agit
workflow. So others who know better should say so if this is a bad idea.
> (BTW, you should give Codeberg a try, as I mentioned in the cover
> letter. It would ensure we’re all on the same page.)
I do want to. But I didn't because I didn't want to overload your
personal repo with too many pull requests. Perhaps we can have a pilot
period (say 30 days) when both mumi/debbugs patches and codeberg pull
requests would be accepted methods to contribute. This may help put
people's minds at ease about the transition, and give them some time to
adapt their contribution/review worklows.
Finally, I understand that the move to Codeberg is a tough decision, and
I wish to express my appreciation for the leadership you are providing
the project.
Thank you,
Arun
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sat, 01 Mar 2025 00:13:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi 45mg,
> And then, there are the additional features provided by a forge, which
> are very difficult to provide in an email-based workflow. For example,
> tagging issues.
The mumi CLI can now tag issues[1], but I take your point that it is
never going to be as easy as a web interface.
[1]: https://yhetil.org/guix/87v7t15zl0.fsf <at> systemreboot.net/
> Also, more reliable and integrated QA would probably make a big
> difference, since QA seems to be how committers find out whether a
> series is ready to apply. While qa.guix.gnu.org is very impressive for a
> volunteer effort, it suffers from a lot of issues that don't really
> happen in modern forges (eg. failing to detect or apply patches from a
> Debbugs submission), and we don't seem to have enough bandwidth to
> improve it. A forge would provide most of what it does, and it would be
> directly integrated with the rest of the tooling.
I believe we will still be using most of our QA system with Codeberg.
Codeberg will simply trigger our QA system in some way. The Codeberg CI
will likely not have sufficient compute power to do what our QA system
does.
Also, I don't think the problem with the QA system is that it cannot
detect our patches. For some reason, it stopped working at some point.
Chris Baines should know the details. I am not very familiar with it.
> Could you share what aspects of Debian's organizational structure you'd
> like us to mirror? I agree that decentralization is good in principle,
> but I'm concerned about needlessly fragmenting the community. I'm not
> familiar with how things work in Debian-land. If they've managed to
> solve this problem, it'd be good for all of us to know about.
I am not too clear about Debian's organizational structure either. I was
hoping channels can do for us what Debian's teams do for Debian.
Regards,
Arun
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sat, 01 Mar 2025 19:18:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
thanks for the updated GCD. I'm in favor of it.
Anyhow, some remarks:
1) Regarding the AGit workflow discussed: This looks interesting
(haven't tried yet). I suggest adding a section to the GCD that this
will be documented within 30 days following acceptance of this GCD (or
even earlier). Beside this, I'm curious whether this would be possible
without "contributor" permissions – so everybody can submit patches this
way.
2) Regarding the issue tracker: I support not migrating issues. Anyhow,
i have two concerns, which OTHO can eventually be targeted in another
GCD or two:
* We might want to migrate the patches, so they don't get lost. It would
be interesting whether we could automatically extract the latest patch
set and create a pull-request for it, including any cover letter
(amended with a link to the original issue). WDYT?
* Some "basic" issues are open since long and still need to be addressed
- or be closed. If we start using the Codeberg tracker, chances are high
issues.guix.gnu.org (and debbugs) will go out of sight and these issues
will get lost. Again this can be decided later on. Maybe many old issues
could be closed anyway.
3) Regarding workflow and tagging of issues/patches: It might be worth
giving some guidance how to tag issues in case. E.g. tagging as "won't
fix", "invalid". etc. Again, this can be discussed after migration as
this is unrelated to the actual migration. OTOH, if there already is
some practice on this, you could add it to the GCD already.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goebel <at> crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 02 Mar 2025 17:10:03 GMT)
Full text and
rfc822 format available.
Message #71 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> writes:
> [..]
>
> First, everyone will have to create an account and accept [Codeberg’s
> Terms of
> Use](https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md)
> before they can contribute, which can be seen as a step back compared to
> the email-based workflow.
I went through the Terms of Use and picked few points I considers
problematic and/or note worthy.
§ 2 (1) 3. looks pretty annoying for occasional contributors.
§ 2 (1) 4. forces us to rewrite repository history in case of
compromise, instead of just reverting the malicious commits. I do not
know what the Guix's current policy is for such a case, but it is worth
to keep in mind that we would no longer have a say in the matter.
§ 2 (4) is annoying for people not familiar with German law (which
includes me). Savannah is in the US, where the rules (possibly aside
the copyright laws) are bit less strict (at least that is my
impression).
§ 2 (5), especially the "its reputation" part, can easily lead to
loosing Codeberg account, and therefore ability to contribute to Guix,
over, for example, Mastodon toot complaining that Codeberg it down
again. After all, that could very well be considered "Action intended
to damage the [Codeberg's] reputation".
§ 3 (4) is pretty WTF. They could at least send an email. I plan to
keep working from the Emacs, so I am pretty sure I will not check the
dashboard for announcement messages regarding ToU changes every three
months.
§ 4 (4) is the typical "we can nuke your account at any time for any
reason". Nice.
And the "You must make sure that we have a way to contact you by keeping
the email address of your account up-to-date." is just a final middle
finger, because while I *have* to keep mail address up to date, they
cannot be bothered to use it to send me information that ToU did change.
I am not sure I agree to these (definitely not to all of them), so I
would probably be precluded from further contributions (since I would
need an account on Codeberg, which I cannot get without agreeing to the
ToU).
Also, there is a pretty nasty failure state when they do change the ToU,
and none of the committers would agree to the change. At that point
they (per the ToU) have to close their accounts and the whole repository
would be just stuck in the void with no way to migrate it away. I agree
this is pretty unlikely though.
All of this would be solved by self hosting, but I definitely understand
your reasons for wanting to avoid that.
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 02 Mar 2025 17:19:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> writes:
> 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.
I have opened the https://codeberg.org in a browser with the LibreJS
extension installed, and two scripts are blocked due to "External script
with no known license":
https://codeberg.org/assets/js/webcomponents.js
https://codeberg.org/assets/js/index.js
They indeed do not seem to contain any kind of license notice.
Since Forgejo is Free software, I assume it is just a matter of some
mark missing somewhere. I am not sure on who this is to fix, whether
Codeberg (Forgejo?) or LibreJS, but I think it would be preferable if
site hosting our repository was not blocked by GNU LibreJS.
Have a nice day,
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 02 Mar 2025 18:08:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello Guix!
I have a question after reading most of this discussion:
Git has a 'request-pull' sub-command:
git request-pull [-p] <start> <URL> [<end>]
On the plus side, most probably, repo duplication on Codeberg would be
avoided by contributors who use the 'request-pull' sub-command
exclusively. No need for those contributors to deal with a web
interface. Most importantly, no mandatory account creation!
However, the pull request can be public while under review only if the
it is published somehow... probably in some kind of passive mailing
list.
The contributor must have his own git repository exposed at <URL>,
accessible to the official Guix committer(s), which means it won't be
convenient or feasible for everybody.
There are potential issues with the transparency of the review process,
but even if this is considered a problem, then I guess '-p' switch could
probably be made mandatory to alleviate any concerns.
There's also the question of how this would feed into your QA process, I
suppose the QA process would have to be completely unreliant on Codeberg
for 'git request-pull' to work with QA.
All in all, it couldn't replace forgejo completely without leaving aside
some contributors. However, leaving open the options to create or not
create a website account on Codeberg would be a * big * thing in that it
tackles what I personally see as the most serious objection to the GCD,
correctly identified by the initial description message, thanks for that
by the way.
Hence my question, I guess the answer is probably "no" but let's make
sure:
Might 'git request-pull' be made an option for Guix contributors in
parallel with the forgejo web process, if the GCD goes through?
Runciter
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 02 Mar 2025 18:11:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 76503 <at> debbugs.gnu.org (full text, mbox):
<#secure method=pgpmime mode=sign>
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hello Guix!
>
> This is the formal submission of “Migrating repositories, issues, and
> patches to Codeberg” (GCD 002), a preliminary draft of which I posted
> before the Guix Days⁰.
>
> In accordance with the GCD Process, discussion will end on April 23rd at
> the latest.
>
> I would like to remind everyone that you can try out Codeberg either by
> contributing to one of the Guix-Science repositories¹, or by reviewing
> or making a pull request for a trivial packaging change (and nothing
> more!) in my Guix clone at Codeberg:
>
> https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00313.html
>
> Please do try it especially if you feel reluctant or wonder what the
> workflow would be like.
>
> Ludo’.
>
> ⁰ https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00218.html
> ¹ https://codeberg.org/guix-science
>
> title: Migrating repositories, issues, and patches to Codeberg
> id: 002
> status: submitted
> discussion: https://issues.guix.gnu.org/<number assigned by issue tracker>
> authors: Ludovic Courtès
> sponsors: Tobias Geerinckx-Rice, Ricardo Wurmus
> date-submitted: 2025-02-23
> date: 2025-02-23
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later
> ---
>
> # 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`
Possible typo in "create add"? :)
> 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.
This seems reasonably simple to do, if this GCD does not pass, I will
take a stab at that.
>
> 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;
If the AGit flow will be mandatory, new process will also be unfamiliar.
Just saying.
> - 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. Such a system is necessarily
> more *complex* at first glance than the email-based tools we have but
> (1) the increase in complexity is reasonable once we consider the
> incidental complexity of the existing services, as mentioned above, and
> (2) we think the added usage benefits outweigh this increase in
> complexity.
>
> 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/).
How do pull request templates work together with AGit flow that (as far
as I understand it) is being considered to be mandatory?
> 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
Maybe "listed below" instead?
> “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 to https://codeberg.org/guix.
>
> For Guix itself, we would decide on a **flag day** 14 days after
> acceptance of this GCD at the earliest, and 30 days at the latest. On
> that day, the official URL of the Guix repository would become
> https://codeberg.org/guix/guix.git. A commit would reflect that by
> updating:
>
> 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,
> in particular in the manual.
>
> To ease this migration and possibly future migration, we may add a new
> `git.guix.gnu.org` DNS entry with HTTP redirects to
> `git.savannah.gnu.org` (before migration) and `codeberg.org` (after
> migration); a [patch](https://issues.guix.gnu.org/76296) implementing
> this has been submitted. The `%default-channel-url` variable would
> refer to `https://git.guix.gnu.org/guix.git`.
The https://git.guix.gnu.org/guix.git seems like a good idea regardless
of whether this GCD is accepted or not. It would allow us to switch the
hosting on moments notice in case the underlying infrastructure goes
down.
>
> 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 for **at least one
> year** after the switch, as a way to ease migration to the new
> repository for users. Other repositories would be deleted from Savannah
> once migrated, to avoid confusion.
>
> ## 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.
This contradicts GCD 001 no? The 001 requires the GCD to be sent as
patch to guix-patches <at> gnu.org. How will this be handled? Once 002 is
accepted, will we rush out 004 replacing the 001? Will there be enough
time for that? Once you close the guix-patches, you cannot propose a
*new* GCD per the current rules (and you cannot change the rules without
a GCD), so at least the initial posting *must* happen within those 30
days.
On separate note, there are other projects (well, I know just of
Shepherd, are there others?) than Guix using bug-guix and guix-patches,
so maybe this GCD should go a bit into how that will be handled.
> It
> will still be possible to interact on individual issues via
> `NNN <at> debbugs.gnu.org`.
> - The switchover will be advertised before it takes place with a post
> to `info-guix <at> gnu.org`, to `guix-devel <at> gnu.org`, as well as through
> a blog post.
> - The “Contributing” section of the manual will be updated accordingly
> at that time.
>
> ## User Interfaces
>
> For many contributors, a strength of the email-based workflow is that it
> works out of the browser, possibly offline; we want to preserve that
> comfort as much as possible.
>
> Everything that can be done through Forgejo’s web interface can be done
> *via* its [HTTP
> interface](https://forgejo.org/docs/latest/user/api-usage/).
This is not true. There is no API for getting the Terms of Use.
Changes in those are announced only as a banner on the website (as far
as I can tell).
> This has
> given rise to several Emacs and command-line interfaces that existing
> contributors may find convenient.
>
> [forgejo-cli](https://codeberg.org/Cyborus/forgejo-cli/) and
> [codeberg-cli](https://codeberg.org/Aviac/codeberg-cli) provide rather
> comprehensive command-line interfaces, as [reported by
> Efraim](https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00057.html).
>
> [fj.el](https://codeberg.org/martianh/fj.el/) is an Emacs interface
> similar to `mastodon.el` that lets you view and comment on issues and
> pull requests, list repositories, view notifications, and so on.
One thing it does not support (based on the README) is the ability to do
an actual code review, which is a bummer.
> It
> does not support off-line access. It can be set up with something like:
>
> ```lisp
> (with-eval-after-load 'fj
> (setq fj-host "https://codeberg.org")
> (setq fj-user "civodul")
> (setq fj-token
> (funcall (plist-get
> (car
> (auth-source-search :host "codeberg.org/api/v1"
> :user fj-user
> :type 'netrc))
> :secret))))
> ```
>
> … and a line like this one to `~/.authinfo.gpg`:
>
> ```
> machine codeberg.org/api/v1 login civodul password TOKEN
> ```
>
> … where `TOKEN` is the [token obtained from
> Codeberg](https://docs.codeberg.org/advanced/access-token/).
>
> [Magit-Forge](https://github.com/magit/forge/) is another Emacs
> interface to forges, with Magit integration and support for working
> off-line. However, Forgejo support is currently next to nonexistent:
> only `forge-browse` is supported (allowing users to open a browser on a
> forge page).
>
> Besides these interfaces, there is a couple of tricks that can simplify
> the life of contributors and reviewers, out of the browser.
>
> As a contributor, you can create pull requests without first creating a
> fork and then a merge request thanks to the [AGit
> workflow](https://forgejo.org/docs/latest/user/agit-support/). This
> works by passing `git push` the relevant *options*, as in this example:
>
> ```
> git push origin HEAD:refs/for/main \
> -o topic="update-hello" \
> -o title="gnu: hello: Update to 42." \
> -o description='This updates the `hello` package."
> ```
Does this still require a Codeberg account? Can anyone update other
people's pull requests, the way I can currently sent n+1 version of a
patch started by someone else?
>
> As a reviewer, it is possible to pull references of pending pull
> requests by adding something like this to `.git/config`:
>
> ```
> [remote "pulls"]
> url = git <at> codeberg.org:org/guix-science/guix-science.git
> fetch = +refs/pull/*/head:refs/remotes/pulls/pr/*
> ```
>
> Running `git fetch pulls` then retrieves references to branches
> corresponding to all the pull requests.
>
> ## 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).
>
> Note that 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.
From the debate I gathered that the merge button can be completely
disabled on the Website, I would suggest to put in here that we will do
that (to prevent mistakes).
>
> If and when the project migrates, we will incrementally adjust our
> workflow to ensure it scales better.
>
> ## 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.
>
> First, everyone will have to create an account and accept [Codeberg’s
> Terms of
> Use](https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md)
> before they can contribute, which can be seen as a step back compared to
> the email-based workflow.
Something to note here is that "contribute" is used in very wide sense.
It contains even just reporting a bug. We will likely lose *some* bug
reports because people will not be willing to jump through the hoops.
Would it be possible to have a bot that would still allow at least to
report bugs via email?
>
> 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, by setting a joint team to
> monitor resource consumption induced by Guix and discuss any issues
> encountered by either parties proactively, or by [joining
> it](https://join.codeberg.org/) as an active member with voting rights.
>
> 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.
>
Have a nice day,
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 02 Mar 2025 18:37:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On Sun, Mar 02, 2025 at 07:10:26PM +0100, Tomas Volf wrote:
> > 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;
>
> If the AGit flow will be mandatory, new process will also be unfamiliar.
> Just saying.
Yeah, I don't think we should require non-standard Git tooling.
Especially if the reason is a "storage problem" that doesn't seem to
exist with any other Git hosting service, and maybe doesn't for Codeberg
either. I think we have gotten ahead of ourselves talking about the
hypothetical "storage problem".
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 02 Mar 2025 18:57:03 GMT)
Full text and
rfc822 format available.
Message #86 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello.
On Sun, 02 Mar 2025 18:18:09 +0100
Tomas Volf <~@wolfsden.cz> wrote:
> I have opened the https://codeberg.org in a browser with the LibreJS
> extension installed, and two scripts are blocked due to "External script
> with no known license":
>
> https://codeberg.org/assets/js/webcomponents.js
> https://codeberg.org/assets/js/index.js
>
> They indeed do not seem to contain any kind of license notice.
>
> Since Forgejo is Free software, I assume it is just a matter of some
> mark missing somewhere. I am not sure on who this is to fix, whether
> Codeberg (Forgejo?) or LibreJS, but I think it would be preferable if
> site hosting our repository was not blocked by GNU LibreJS.
Codeberg developers expressed willingness to resolve this issue, but it
looks like they cannot decide on the approach. See this issue for
details: https://codeberg.org/Codeberg/Community/issues/64
The issue is also tracked upstream:
* in Gitea: https://github.com/go-gitea/gitea/issues/13393
* in Forgejo: https://codeberg.org/forgejo/forgejo/issues/1654
Meanwhile, another effort is to have the currently deployed source code
automatically disclosed, so that users could whitelist the website
manually. See: https://codeberg.org/Codeberg/Community/issues/1416
FSF associate members may also find this forum discussion relevant:
https://forum.members.fsf.org/t/what-is-the-last-update-on-gnu-forge-project/5337?u=riabenko
Roman
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 02 Mar 2025 21:55:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Tomas,
Thanks for reading the proposal. I pushed a fix for the typos you
reported.
Tomas Volf <~@wolfsden.cz> skribis:
>> 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/).
>
> How do pull request templates work together with AGit flow
Good question, I don’t know, we’ll need to check.
> that (as far as I understand it) is being considered to be mandatory?
That’s not how I see it; I think suggesting it is an option (but also
from because it provides an interface that some may prefer), but making
it mandatory now doesn’t seem justified to me.
>> To ease this migration and possibly future migration, we may add a new
>> `git.guix.gnu.org` DNS entry with HTTP redirects to
>> `git.savannah.gnu.org` (before migration) and `codeberg.org` (after
>> migration); a [patch](https://issues.guix.gnu.org/76296) implementing
>> this has been submitted. The `%default-channel-url` variable would
>> refer to `https://git.guix.gnu.org/guix.git`.
>
> The https://git.guix.gnu.org/guix.git seems like a good idea regardless
> of whether this GCD is accepted or not. It would allow us to switch the
> hosting on moments notice in case the underlying infrastructure goes
> down.
Yes, I think so too.
>> - 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.
>
> This contradicts GCD 001 no? The 001 requires the GCD to be sent as
> patch to guix-patches <at> gnu.org. How will this be handled?
I think we would amend GCD 001 to change references to the email
workflow with references to the Codeberg-based workflow. We should
probably spell it out here in an extra bullet, along these lines:
- Once the guix-consensus-document.git repository has been moved to
Codeberg, authorized people will apply [the
patch](https://issues.guix.gnu.org/XXX) amending GCD 001 to refer to
the Codeberg-based workflow.
And so we’d send the patch in question beforehand so everyone can see
how the GCD is amended.
WDYT?
> On separate note, there are other projects (well, I know just of
> Shepherd, are there others?) than Guix using bug-guix and guix-patches,
> so maybe this GCD should go a bit into how that will be handled.
Maybe with by extending the bullet above:
[…] meaning that messages will not get through anymore.
Other projects that were using bug-guix and guix-patches (the
Shepherd, Cuirass, etc.) must have set up their own bug-reporting
and patch-tracking tools by then.
In practice I believe Shepherd is the only one not under the Guix
project at Savannah that will have to do something special[*]; the other
projects will be able to use the Codeberg tools.
[*] I’d like to migrate Shepherd to Codeberg as well soon, under its own
organization.
>> Everything that can be done through Forgejo’s web interface can be done
>> *via* its [HTTP
>> interface](https://forgejo.org/docs/latest/user/api-usage/).
>
> This is not true.
I was thinking about this:
https://codeberg.org/api/swagger#/
> There is no API for getting the Terms of Use. Changes in those are
> announced only as a banner on the website (as far as I can tell).
Yes; I saw what you (re)wrote on this topic and I plan to reply
separately.
>> [fj.el](https://codeberg.org/martianh/fj.el/) is an Emacs interface
>> similar to `mastodon.el` that lets you view and comment on issues and
>> pull requests, list repositories, view notifications, and so on.
>
> One thing it does not support (based on the README) is the ability to do
> an actual code review, which is a bummer.
Concretely, it does not let you comment line-by-line so far, which is
what you would do in the web interface.
Of course you can still use ‘fj.el’ to send comments about changes
(that’s what I’ve been doing with those at
<https://codeberg.org/civodul/guix/pulls>), but for more complex code
reviews, one may have to resort to the web interface to pinpoint
specific issues in the code.
I agree that it’s a bummer, but I find that the overall benefit still
outweighs this annoyance (and it’s an annoyance for some of us but not
for everyone out there).
>> git push origin HEAD:refs/for/main \
>> -o topic="update-hello" \
>> -o title="gnu: hello: Update to 42." \
>> -o description='This updates the `hello` package."
>> ```
>
> Does this still require a Codeberg account?
Yes.
> Can anyone update other people's pull requests, the way I can
> currently sent n+1 version of a patch started by someone else?
If I’m not mistaken, the person who creates the pull request decides
whether they allow others to update it. (As a reviewer and “owner”,
I’ve definitely updated other people’s pull requests.)
>> Note that 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.
>
>>From the debate I gathered that the merge button can be completely
> disabled on the Website, I would suggest to put in here that we will do
> that (to prevent mistakes).
Yes, I added a sentence to that effect and pushed it; let me know if
anything more should be done in your view.
>> First, everyone will have to create an account and accept [Codeberg’s
>> Terms of
>> Use](https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md)
>> before they can contribute, which can be seen as a step back compared to
>> the email-based workflow.
>
> Something to note here is that "contribute" is used in very wide sense.
> It contains even just reporting a bug. We will likely lose *some* bug
> reports because people will not be willing to jump through the hoops.
That is true, but the same can be said of the current workflow.
> Would it be possible to have a bot that would still allow at least to
> report bugs via email?
I imagine this is technically feasible, but the problem is that setting
up bidirectional communication (so developers can ask questions to
reporters) is probably out of reach; in that case it would lose its
interest.
In practice, if someone sends a bug to guix-devel, we won’t ignore it,
but I think it’s in the project’s interest to direct bug reports to one
channel.
Thanks for your thorough review and insightful comments!
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 02 Mar 2025 22:18:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Tomas Volf <~@wolfsden.cz> skribis:
>> (https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md)
> I went through the Terms of Use and picked few points I considers
> problematic and/or note worthy.
As mentioned in my initial reply¹, this shouldn’t be frame as us-vs-them
(let alone harsh language), but rather as:
1. Is it a blocker?
2. If not, how can we work with Codeberg e.V. on that once we’ve
switched to Codeberg.
Having now read them, I personally find the ToU reasonable.
¹ https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00030.html
> § 2 (1) 3. looks pretty annoying for occasional contributors.
That’s reasonable: it’s a non-profit, they have to make space once in a
while, but that’s okay: Git is distributed, people have a local copy.
> § 2 (1) 4. forces us to rewrite repository history in case of
> compromise,
I definitely don’t read it that way: it’s not about “compromised” code
as in “CVE in guix-daemon”, and it’s not about genuine bugs either.
> § 2 (4) is annoying for people not familiar with German law
This is quite theoretical (whereas takedown notices in the US on GitHub
and the likes are something very tangible.)
> § 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".
Again that’s a bit of a stretch, but more importantly it’s framed as if
(1) we were dealing with a hostile adversary, and (2) we were customers
not owing respect to the volunteers making it work.
Let’s be very clear: that’s not the spirit of this proposal. We’ll be
using a service set up by other volunteers and we’ll be joining forces
in some way—financially or otherwise. There’s going to be downtimes and
problems, but we’re going to deal with them together.
> § 3 (4) is pretty WTF. They could at least send an email. I plan to
> keep working from the Emacs, so I am pretty sure I will not check the
> dashboard for announcement messages regarding ToU changes every three
> months.
I agree it’s not great, but it’s typically the kind of thing to discuss
with them, once we’ve moved; perhaps sending email would be acceptable
for them.
> § 4 (4) is the typical "we can nuke your account at any time for any
> reason". Nice.
Yes, that makes sense to me.
The remaining paragraphs are harsh if not hostile (please avoid that
tone in the future) and hopefully covered by the rest of that reply.
Thanks,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 02 Mar 2025 23:16:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thank you for addressing the points one by one. Few reactions below, I
have omitted those where I have nothing more to say.
Ludovic Courtès <ludo <at> gnu.org> writes:
> Tomas Volf <~@wolfsden.cz> skribis:
>
>>> (https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md)
>
>> I went through the Terms of Use and picked few points I considers
>> problematic and/or note worthy.
>
> As mentioned in my initial reply¹, this shouldn’t be frame as us-vs-them
> (let alone harsh language), but rather as:
>
> 1. Is it a blocker?
Probably not for the project. ^_^ Though for me personally the § 3 (4)
is a blocker. I cannot in good faith agree to check the website every
three months, because I know I will not be doing that. I have already
failed at it once and I know it would happen again.
> 2. If not, how can we work with Codeberg e.V. on that once we’ve
> switched to Codeberg.
>
>
>> § 2 (1) 4. forces us to rewrite repository history in case of
>> compromise,
>
> I definitely don’t read it that way: it’s not about “compromised” code
> as in “CVE in guix-daemon”, and it’s not about genuine bugs either.
Hm I probably was not clear enough. I simply do not know what Guix
policy here is, so I just wanted to bring this up.
If some committer is compromised, and malicious commit gets pushed
upstream, what will Guix do? Revert the commit? Or rewrite the history
and remove it completely?
If latter, this point is moot and you can stop reading.
If former, I am not sure that would comply with the ToU.
>
>> § 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".
>
> Again that’s a bit of a stretch, but more importantly it’s framed as if
> (1) we were dealing with a hostile adversary, and (2) we were customers
> not owing respect to the volunteers making it work.
>
> Let’s be very clear: that’s not the spirit of this proposal. We’ll be
> using a service set up by other volunteers and we’ll be joining forces
> in some way—financially or otherwise. There’s going to be downtimes and
> problems, but we’re going to deal with them together.
I agree it might be a stretch, but at the same time I assume they had
*some* reason to put a fairly specific point like this into the ToU.
>
>> § 3 (4) is pretty WTF. They could at least send an email. I plan to
>> keep working from the Emacs, so I am pretty sure I will not check the
>> dashboard for announcement messages regarding ToU changes every three
>> months.
>
> I agree it’s not great, but it’s typically the kind of thing to discuss
> with them, once we’ve moved; perhaps sending email would be acceptable
> for them.
Let us hope.
>
> The remaining paragraphs are harsh if not hostile (please avoid that
> tone in the future) and hopefully covered by the rest of that reply.
Yes, I apologize for that. I just copy&pasted my original message
written in a bit heated state of mind. I should have adjusted the
language. Sorry.
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 02 Mar 2025 23:36:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hi Tomas,
>
> Thanks for reading the proposal. I pushed a fix for the typos you
> reported.
I am pretty sure it should have not been pushed to the main branch, but
to wip-codeberg (or something similar). My understanding of GCD-001 and
the README is that main is for approved documents only.
> [..]
>> How do pull request templates work together with AGit flow
>
> Good question, I don’t know, we’ll need to check.
>
>> that (as far as I understand it) is being considered to be mandatory?
>
> That’s not how I see it; I think suggesting it is an option (but also
> from because it provides an interface that some may prefer), but making
> it mandatory now doesn’t seem justified to me.
Agree.
> [..]
>>> - 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.
>>
>> This contradicts GCD 001 no? The 001 requires the GCD to be sent as
>> patch to guix-patches <at> gnu.org. How will this be handled?
>
> I think we would amend GCD 001 to change references to the email
> workflow with references to the Codeberg-based workflow. We should
> probably spell it out here in an extra bullet, along these lines:
>
> - Once the guix-consensus-document.git repository has been moved to
> Codeberg, authorized people will apply [the
> patch](https://issues.guix.gnu.org/XXX) amending GCD 001 to refer to
> the Codeberg-based workflow.
>
> And so we’d send the patch in question beforehand so everyone can see
> how the GCD is amended.
>
> WDYT?
Yes, that seems good process wise.
I am not really looking forward to reading the debate (given the volume)
in the linear format in the Codeberg's issue tracker (no threading, no
dormant marks, ...), and I am not happy about limiting people able to
comment on GCD proposal to holders for Codeberg account, but both are in
the spirit of this (002) proposal, so it makes sense.
(Hypothetical funny situation would be a GCD about moving *off* Codeberg
due to people having troubles creating account, on which people it is
about would not be able to comment, due to not having an account. Yes,
yes, just joking.)
>
>> On separate note, there are other projects (well, I know just of
>> Shepherd, are there others?) than Guix using bug-guix and guix-patches,
>> so maybe this GCD should go a bit into how that will be handled.
>
> Maybe with by extending the bullet above:
>
> […] meaning that messages will not get through anymore.
> Other projects that were using bug-guix and guix-patches (the
> Shepherd, Cuirass, etc.) must have set up their own bug-reporting
> and patch-tracking tools by then.
Sounds good.
> [..]
>>> [fj.el](https://codeberg.org/martianh/fj.el/) is an Emacs interface
>>> similar to `mastodon.el` that lets you view and comment on issues and
>>> pull requests, list repositories, view notifications, and so on.
>>
>> One thing it does not support (based on the README) is the ability to do
>> an actual code review, which is a bummer.
>
> Concretely, it does not let you comment line-by-line so far, which is
> what you would do in the web interface.
Does it at least let you see line-by-line comments from other people?
Sorry for constant questions, but as you might have guessed from the
other thread, I do not have Codeberg account to try it myself.
> [..]
>> Can anyone update other people's pull requests, the way I can
>> currently sent n+1 version of a patch started by someone else?
>
> If I’m not mistaken, the person who creates the pull request decides
> whether they allow others to update it. (As a reviewer and “owner”,
> I’ve definitely updated other people’s pull requests.)
Can this be enforced on repository level? So that we could mandate that
all pull requests are editable by anyone, to match how the debbugs work
currently?
>
>>> Note that 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.
>>
>>>From the debate I gathered that the merge button can be completely
>> disabled on the Website, I would suggest to put in here that we will do
>> that (to prevent mistakes).
>
> Yes, I added a sentence to that effect and pushed it; let me know if
> anything more should be done in your view.
Nothing more required, the addition looks good.
>
>>> First, everyone will have to create an account and accept [Codeberg’s
>>> Terms of
>>> Use](https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md)
>>> before they can contribute, which can be seen as a step back compared to
>>> the email-based workflow.
>>
>> Something to note here is that "contribute" is used in very wide sense.
>> It contains even just reporting a bug. We will likely lose *some* bug
>> reports because people will not be willing to jump through the hoops.
>
> That is true, but the same can be said of the current workflow.
People having a working email are a strict superset of people having
Codeberg account, by definition. ^_^
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 03 Mar 2025 07:38:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi everyone,
A few comments which I will prefix with a summary of my own perspective:
1. I am an occasional contributor to Guix, contributing mainly packages
that I make for my own needs and wish to share.
2. I am a voting member of Codeberg e.V., because I believe that
Codeberg and its Forĝejo project are a step in the right direction,
which I see as transitioning forges from platforms to services
that don't "own" projects, nor user accounts.
Overall, I am very favorable to moving to a forge because of point 1. I
don't see anything objectively wrong or bad about the current e-mail
workflow, but for an occasional (or new) contributor its hard to become
fluent with it. In contrast, forges are becoming standard even for many
non-coders.
I won't comment on topics I am ignorant about, in particular the storage
debate. Nor much on other points that I think can be solved in
collaboration with the Codeberg team, e.g. the LibreJS issues.
That leaves the problem of becoming dependent on a platform, which
implies that all contributors must create an account and accepts terms
of services, and that, at least in theory, the platform owners can do
harm to the project.
As I said above, the long-term goal should, in my opinion, be forges as
services, much like e-mail servers. Projects bring their own domain,
terms of services, etc., and pay a service provider for keeping the
servers running, retaining the option of switching service providers. We
don't have this possibility right now, but the federation approach of
Forĝejo makes it look reachable in a small-integer number of years.
For me, moving to Codeberg is a stepping stone towards this goal. It
looks like Guix would be their larges project, meaning that we would
have a lot of influence on how Codeberg and Forĝejo will evolve towards
serving projects like ours. I see that as an opportunity.
As for the current terms of services, I have personally no issues with
them. Any set of written rules leaves a potential for abuse, so I am not
a fan of overinterpreting written rules. I'd rather look at how the
rules are applied, and from that perspective, I am not aware of any
project having had issues with Codeberg.org.
Cheers,
Konrad.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 03 Mar 2025 07:55:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Konrad Hinsen <konrad.hinsen <at> fastmail.net> writes:
> Overall, I am very favorable to moving to a forge because of point 1. I
> don't see anything objectively wrong or bad about the current e-mail
> workflow, but for an occasional (or new) contributor its hard to become
> fluent with it. In contrast, forges are becoming standard even for many
> non-coders.
One more point that I forgot: moving to a forge could be even more
beneficial for increasing the number of people reviewing patches. For
submitting a patch, the current workflow is unusual but not so
complicated. For reviewing, I don't even know how to do it, in
particular how to apply and test patches from an e-mail message in a
sufficiently automated way. In contrast, on a forge, I could well
imaging participating in reviewing patches for ecosystems I am familiar
with.
Cheers,
Konrad.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 04 Mar 2025 11:24:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ludovic,
Ludovic Courtès <ludo <at> gnu.org> writes:
[...]
> 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:
I don't think maintaining the infrastructure *that would be replaced*
has been too time consuming. Sure, Mumi has had some issues and needed
some fixing, but most of what is used today:
- Savannah (git hosting)
- Debbugs (bug tracker) & Mumi
- Git configs/hooks
- Contributing documentation
rarely ever changes and has been stable, all while being generously
hosted, without limits on repository size or other criteria, on
freedom-respecting hardware and a friendly associated org (FSF/GNU),
which I assume can't be said of Codeberg (w.r.t. using free software
friendly hardware, such as using the GNU Boot bootloader). The
complexity of the flow can be partly explained by the fact that there
isn't only one flow possible, but a multitude of flows (Emacs Debbugs,
Mumi, git send-email, etc.), which is more of a strength than a defect
when it comes to the freedom of choice/flexibility for our contributors.
I see the argument that there's an HTTP API for Forgejo; that's great,
but it requires that everyone relearn another way of doing something
that already works well enough for me and others, which I'm not too
excited about. I also assume the Forgejo-related tooling, given their
young age, would not be as mature and missing features in places, and
that it would require invested time to comfortably do all that can be
done today in Gnus and Emacs Debbugs, away from the web interface, in
the environment of choice (Emacs) of perhaps a majority of the Guix
contributors.
The parts that have required the most maintenance would be, I assume, CI
(Cuirass) and QA (Guix Build Coordinator), but these components will
continue to be used in the event we migrate to Codeberg, so we wouldn't
gain much on the maintenance side, it seems.
> - 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.
I believe some of the above, such as notifying everyone involved in a
ticket's discussion when replying, has been/could be tackled in the
improved GNU Debbugs rewrite that Felix has been refining and testing
[0, 1]. I think improving Debbugs for the whole of GNU (the Emacs
project actively use it still for example) would make sense and is
something I've been meaning to do, but not high in my priority list
(since it already works well enough for the most part). Hacking a small
Perl code base doesn't appear much more daunting than the modern
Go-written, web framework library heavy mastodon I assume
Gitea/Forgejo is, so I'm not sure why we wouldn't try this first
instead. I can't help but feel like we'd be throwing the baby out with
the bathwater: in my view, the current situation is not as bad as
suggested in your outlook, though I agree further automation and
simplifications would be welcome.
[0] https://codeberg.org/lechner/mumi
[1] https://patchwise.org/
> 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.
My reading of the survey's results was that the main concern of the
community was packages' freshness and availability. Our backlog is
already larger than we can handle. Opening contributions from more
people, if that's what Codeberg would help with, wouldn't solve the real
problem of lack of eyes & hands to review and merge the contributions,
while giving us more work documenting the new workflows and their
quirks.
One serious usability quirk I can foresee is that given our current
PGP-based security design, committers would still need to push the
commits manually from their local machine so they can sign the commits
with their key, which probably defeats the streamlined and automated
niceties of the PR flow:
- The merge button in web UI would need to be disabled or documented as
prohibited (I doubt we'd even be able to disable it? or we'd need to
ensure the merge can be fast-forwarded and is already signed, which
would be a bit annoying since we'd need to not only fetch + rebase but
then visit the web interface to merge a change). It can all be
automated via the HTTP API I'm sure, but that wouldn't be much of an
improvement (if at all) over our current flow.
I suspect not being able to follow the expected way of merging things
probably further implies that:
- Issues won't be closed automatically since we can't use the merge
button.
- Both PR and issues must then be closed manually, which is what we
currently have
- The flow would be *even* more confusing than now, since it'd look
like Github but require committers to use it very differently.
Which would again need more custom tools/scripts as a workaround.
[...]
> Within **30 days** following acceptance of this GCD, committers would
> migrate all these repositories to https://codeberg.org/guix.
>
> For Guix itself, we would decide on a **flag day** 14 days after
> acceptance of this GCD at the earliest, and 30 days at the latest. On
> that day, the official URL of the Guix repository would become
> https://codeberg.org/guix/guix.git. A commit would reflect that by
> updating:
I'd like to suggest extending the 'trial' period to something much
longer, like a year or so, to make sure our parachute is properly
installed before jumping the cliff :-). Letting both systems co-exist
and compete for merit seems a good trial, and we could also extract
useful data (such as how many contributions were merged on one or the
other, etc.). It'd be a bit annoying to keep an eye at two places for
some time, but at least we wouldn't commit to something that may not
scale/match our peculiar requirements as well as we expected.
After such trial we could then vote on whether we want to fully migrate
to Codeberg, when all regular contributors would have gotten a chance to
try the new tools and find a flow that works for them, hopefully. With
this insurance in place, I'd be happy to experiment with Codeberg and
see whether it truly improves things.
Thank you for proposing this GCD!
--
Maxim
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 04 Mar 2025 15:28:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On 2025-03-04 12:22, Maxim Cournoyer wrote:
> - The flow would be*even* more confusing than now, since it'd look
> like Github but require committers to use it very differently.
This is a very interesting take.
I have a similar view when we mention A-Git-Flow or whatever that is.
We would be using a tool in a very surprising way. I don't know if
that's good, at all.
We would be pushing that complexity only to committers, not to ocasional
contributors, which may help attracting people. But, on the other hand,
we would force people who is already very busy (and very efficient with
their current workflow) to discard their way to do things and learn another.
I like the proposal, but at the same time, I feel very comfortable with
Guix due to the fact that I can collaborate with email only (I even
decided to use the same model for my projects!).
Some of the things we have are very disturbing though: savannah is
weird, patches being mixed with issues, debbugs is not very comfortable
to use... I think that would be improved with Codeberg.
I don't know if this adds anything, but there it is.
Cheers,
Ekaitz
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 04 Mar 2025 17:21:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Ekaitz Zarraga <ekaitz <at> elenq.tech> writes:
> On 2025-03-04 12:22, Maxim Cournoyer wrote:
>> - The flow would be*even* more confusing than now, since
>> it'd look
>> like Github but require committers to use it very
>> differently.
>
> This is a very interesting take.
> I have a similar view when we mention A-Git-Flow or whatever
> that is.
> We would be using a tool in a very surprising way. I don't know
> if
> that's good, at all.
>
> We would be pushing that complexity only to committers, not to
> ocasional contributors, which may help attracting people. But,
> on the
> other hand, we would force people who is already very busy (and
> very
> efficient with their current workflow) to discard their way to
> do
> things and learn another.
The Github workflow is more complicated:
- fork the repository on the forge website
- clone your fork from the forge to your local machine
- checkout a new branch
- make a commit
- push the commit from your local checkout to your fork on the
forge
- go to the forge website to open a pull request from your fork to
the upstream repository
The AGit flow:
- clone the upstream repository
- checkout a new branch
- make a commit
- push the commit as a PR to the forge.
Am I overlooking something?
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 04 Mar 2025 17:28:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
Arun Isaac <arunisaac <at> systemreboot.net> skribis:
> The only amendment I would strongly recommend is to require the agit
> workflow in order to mitigate the storage problem/risk.
The problem I see with requiring AGit is that we’d be making a decision
based on what we understand is a potential risk on Codeberg’s side.
I would rather not require use of AGit until Codeberg volunteers ask us
to do so or at least express concern in relation with Guix activity on
Codeberg. But of course, this could only happen after migration.
WDYT?
Alternatively (or in addition to the above), perhaps I can solicit
feedback from a Codeberg volunteer during this discussion period?
> I do want to. But I didn't because I didn't want to overload your
> personal repo with too many pull requests. Perhaps we can have a pilot
> period (say 30 days) when both mumi/debbugs patches and codeberg pull
> requests would be accepted methods to contribute. This may help put
> people's minds at ease about the transition, and give them some time to
> adapt their contribution/review worklows.
Yes, having a period where both methods are accepted sounds doable.
The risk is that some things would go unnoticed on one side or the
other, and during that period we’d be effectively splitting the
community between “those who prefer email” and “those who prefer
Codeberg”, but if it’s limited to 30 days max, that’s probably OK.
What do people think?
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 04 Mar 2025 17:57:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
> The problem I see with requiring AGit is that we’d be making a decision
> based on what we understand is a potential risk on Codeberg’s side.
>
> I would rather not require use of AGit until Codeberg volunteers ask us
> to do so or at least express concern in relation with Guix activity on
> Codeberg. But of course, this could only happen after migration.
>
> WDYT?
>
> Alternatively (or in addition to the above), perhaps I can solicit
> feedback from a Codeberg volunteer during this discussion period?
Talking to Codeberg sounds good. We have to do it anyway to discuss
other aspects of the migration.
Regards,
Arun
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 04 Mar 2025 18:35:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On 2025-03-04 18:19, Ricardo Wurmus wrote:
>
> The AGit flow:
>
> - clone the upstream repository
> - checkout a new branch
> - make a commit
> - push the commit as a PR to the forge.
Yes but no.
It's easy, but if we are going to make any contributor do that, we are
still going to need documentation and people will come and complain.
Isn't the email based workflow as simple as:
- clone the upstream repository
- make commits
- send email
I would say that's even simpler (it doesn't even involve branches!). But
still people seem to struggle with it.
Codeberg is born from a software that intends to be a Github clone and
was originally designed with that workflow in mind. So people would
deduce we work using the Github workflow, and probably be frustrated
when they realize we don't.
I wouldn't be surprised if this is discussed as something problematic in
the future.
I'm not saying I dislike it (I do like it), but we have to be prepared.
I don't think the email workflow was specially difficult, I think this
change has been advocated for because people wanted to use the Github
workflow instead (the main argument was "it's what people is used to").
I know Ludovic's proposal doesn't try to overcome that specific "please
do what I'm used to because I don't want to think" problem, but we have
to be aware that those who want this change to happen because of it are
not going to be happy with the result.
Having the PR would be better for them than what we had. That's also true.
Also, now I'm thinking about it, the complexity of a-git-flow is
directly pushed to any contributors, and not only people with commit
access like the website being unable to merge things. So there's that, too.
Cheers,
Ekaitz
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 04 Mar 2025 18:57:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ekaitz Zarraga <ekaitz <at> elenq.tech> writes:
> On 2025-03-04 18:19, Ricardo Wurmus wrote:
>>
>> The AGit flow:
>>
>> - clone the upstream repository
>> - checkout a new branch
>> - make a commit
>> - push the commit as a PR to the forge.
>
> Yes but no.
> It's easy, but if we are going to make any contributor do that, we are
> still going to need documentation and people will come and complain.
>
> Isn't the email based workflow as simple as:
>
> - clone the upstream repository
> - make commits
> - send email
Here’s my point of view:
- clone the upstream repository
- make commits
- format patches
- configure git send-mail
- …or find out which addresses to send the mail and who to cc with
etc/teams.scm
- send email
Which is more complicated than the AGit flow IMO. And we will need
documentation on how to contribute no matter which way we choose.
What I especially like about the AGit flow is that it just uses git,
which is a common factor. No need for an alternate patch format, or
email.
Cheers,
Noé
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 04 Mar 2025 19:41:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On 2025-03-04 19:55, Noé Lopez wrote:
>
> Here’s my point of view:
> - clone the upstream repository
> - make commits
> - format patches
> - configure git send-mail
> - …or find out which addresses to send the mail and who to cc with
> etc/teams.scm
> - send email
>
Of course, I was just making it simple on purpose. Those points you
address here have "easy" answers (my point being: as "easy" as
agit-flow, with quotes), once you configure, you don't have to type the
email addresses anymore.
The point what I wanted to make is not that it is really easier or not
(without quotes), but the fact that it doesn't matter. It's different to
what people expect, and that's going to create friction.
> Which is more complicated than the AGit flow IMO. And we will need
> documentation on how to contribute no matter which way we choose.
The heavy use of --push-option/-o is pretty weird for people that never
did that before (I never used that before and I have quite a long
experience collaborating in free software projects), the refspec usage
agit-flow needs is not widely known either.
- Was it refs/for/master or was it /for-review/ or what?
- Oh the -o description="..." takes a string but I want a multiline
thing that is getting too long.
- Oh no! the pr messed up my formatting again!
...
Well, at least the email we can write it in a proper editor very easily.
I don't know if that's the case in the -o unless we hack around...
(anyway, that's not the point here)
> What I especially like about the AGit flow is that it just uses git,
> which is a common factor. No need for an alternate patch format, or
> email.
Well, patches are a part of git as --push-option is (Codeberg PRs are
not part of Guix, though), so I don't think this makes a good argument.
But regardless, my point was that when this issue was discussed, for
example, in a thread I started a while ago about the future of Guix, the
arguments I found were that Guix was too hard on newcomers and that we
needed to use a forge like any body else, because that's what people is
used to.
I still doubt that applying the Github workflow (or any other workflow)
is going to increase the amount of meaningful contributions (Guix is
already too hard as it is, it's not like the email workflow was the
hardest part of Guix) and I'm aware the move to Codeberg doesn't only
try to fix the commit workflow but also many other things, which I agree
with.
I just wanted to emphasize that if we are not letting people use the
merge button and we are going to use agit-flow or anything like that, we
are not going to make it obviously simple.
And it's going to make the committers' (our real bottleneck) life a
little bit hard for some time until we get used to this and we become as
efficient with it as we are now.
Cheers,
Ekaitz
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 05 Mar 2025 00:40:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
Andrew Wong <wongandj <at> icloud.com> writes:
>> On Feb 25, 2025, at 10:04 AM, Cayetano Santos via Guix-patches via <guix-patches <at> gnu.org> wrote:
>> Still, I wonder how Github
>> educated people, reluctant to email exchange, will react to a
>>
>> git push origin HEAD:refs/for/<target-branch>/<session>
>>
>> based workflow, and if this really lowers the barrier to entry[1].
> The linked page refers to a tool called “git-repo”, which smooths out
> the more technical bits to commands like “git pr”. From appearances it
> seems like using this tool is lower-investment for users than
> configuring (or changing!) their email client to interact with mailing
> lists and the mail-in patch workflow properly. It also helps that this
> (optional?) special tool is more “orthogonal” to other workflows,
> rather than involving something as central as emails.
You'd still need an email client to interact with guix-devel and our
other mailing lists, or to create the request to merge a feature branch
that QA understand (until this is adapted/changed to use something
else).
--
Thanks,
Maxim
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 05 Mar 2025 01:01:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ricardo,
Ricardo Wurmus <rekado <at> elephly.net> writes:
[...]
> The Github workflow is more complicated:
>
> - fork the repository on the forge website
> - clone your fork from the forge to your local machine
> - checkout a new branch
> - make a commit
> - push the commit from your local checkout to your fork on the forge
> - go to the forge website to open a pull request from your fork to
> the upstream repository
>
> The AGit flow:
>
> - clone the upstream repository
> - checkout a new branch
> - make a commit
> - push the commit as a PR to the forge.
>
> Am I overlooking something?
At least two of the points this GCD is supposed to improve on is:
--8<---------------cut here---------------start------------->8---
- the process is unfamiliar to most newcomers;
- the tools and infrastructure in Guix have become a maze;
--8<---------------cut here---------------end--------------->8---
What would arguably be most familiar to newcomers is the Github-style PR
flow, whether we like it or not, and Gitea/Forgejo is a designed as a
clone of Github, even at its API level, so I'm pretty sure the PR flow
would be the intuitive expectation of newcomers interacting with it.
Using other flows that require typing command lines or abstracting these
via other tools is just changing a set of "weird" tools to another set
of "weird" tools, from a newcomer's perspective.
I'm not saying I don't see any positives to migrating to Codeberg, but
that if we can't use the PR flow then the points I quoted above do not
appear improved much by such a move.
--
Thanks,
Maxim
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 05 Mar 2025 08:11:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
I don't really understand this whole thread and worry about the Agit
flow. I think some information was lost along the way.
From my understanding of the GCD and other discussions, both the
classic PR github-like flow and Agit can live happily together. And the
GCD does not propose to only allow the Agit flow.
Everyone preferring (or simply only knowing) the classic fork-PR can go
this way.
Any person that would prefer not forking and working mostly from the
command-line can do so through the Agit flow.
But from the commiter/reviewer POV, this will look identical, i.e. a PR
on the repo.
Am I missing something?
The issue of not having a merge button comes from another set of
considerations (signing).
Cheers,
Alexis
On 05/03/2025 02:00, Maxim Cournoyer wrote:
> Hi Ricardo,
>
> Ricardo Wurmus <rekado <at> elephly.net> writes:
>
> [...]
>
>> The Github workflow is more complicated:
>>
>> - fork the repository on the forge website
>> - clone your fork from the forge to your local machine
>> - checkout a new branch
>> - make a commit
>> - push the commit from your local checkout to your fork on the forge
>> - go to the forge website to open a pull request from your fork to
>> the upstream repository
>>
>> The AGit flow:
>>
>> - clone the upstream repository
>> - checkout a new branch
>> - make a commit
>> - push the commit as a PR to the forge.
>>
>> Am I overlooking something?
>
> At least two of the points this GCD is supposed to improve on is:
>
> --8<---------------cut here---------------start------------->8---
> - the process is unfamiliar to most newcomers;
> - the tools and infrastructure in Guix have become a maze;
> --8<---------------cut here---------------end--------------->8---
>
> What would arguably be most familiar to newcomers is the Github-style PR
> flow, whether we like it or not, and Gitea/Forgejo is a designed as a
> clone of Github, even at its API level, so I'm pretty sure the PR flow
> would be the intuitive expectation of newcomers interacting with it.
>
> Using other flows that require typing command lines or abstracting these
> via other tools is just changing a set of "weird" tools to another set
> of "weird" tools, from a newcomer's perspective.
>
> I'm not saying I don't see any positives to migrating to Codeberg, but
> that if we can't use the PR flow then the points I quoted above do not
> appear improved much by such a move.
>
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 05 Mar 2025 09:36:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Alexis Simon <alexis.simon <at> runbox.com> writes:
> Everyone preferring (or simply only knowing) the classic fork-PR
> can
> go this way.
Correct.
> Any person that would prefer not forking and working mostly from
> the
> command-line can do so through the Agit flow.
>
> But from the commiter/reviewer POV, this will look identical,
> i.e. a
> PR on the repo.
This is correct.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 05 Mar 2025 09:40:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> Hi,
>
> Andrew Wong <wongandj <at> icloud.com> writes:
>
>>> On Feb 25, 2025, at 10:04 AM, Cayetano Santos via Guix-patches
>>> via <guix-patches <at> gnu.org> wrote:
>>> Still, I wonder how Github
>>> educated people, reluctant to email exchange, will react to a
>>>
>>> git push origin HEAD:refs/for/<target-branch>/<session>
>>>
>>> based workflow, and if this really lowers the barrier to
>>> entry[1].
>> The linked page refers to a tool called “git-repo”, which
>> smooths out
>> the more technical bits to commands like “git pr”. From
>> appearances it
>> seems like using this tool is lower-investment for users than
>> configuring (or changing!) their email client to interact with
>> mailing
>> lists and the mail-in patch workflow properly. It also helps
>> that this
>> (optional?) special tool is more “orthogonal” to other
>> workflows,
>> rather than involving something as central as emails.
>
> You'd still need an email client to interact with guix-devel and
> our
> other mailing lists, or to create the request to merge a feature
> branch
> that QA understand (until this is adapted/changed to use
> something
> else).
The difference is that you don't need to configure "git
send-email" or
configure a local msmtp to send email to guix-devel or other
mailing
lists. For patches sent to guix-patches we recommend configuring
"git
send-email" to avoid garbled patches.
I know from mentoring people that setting up "git send-email" is a
real
hurdle, whereas sending simple emails to participate in
discussions on a
mailing list is not.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 05 Mar 2025 11:15:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 04, 2025 at 08:22:59PM +0900, Maxim Cournoyer wrote:
> Hi Ludovic,
>
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
> [...]
> - The merge button in web UI would need to be disabled or documented as
> prohibited (I doubt we'd even be able to disable it? or we'd need to
> ensure the merge can be fast-forwarded and is already signed, which
> would be a bit annoying since we'd need to not only fetch + rebase but
> then visit the web interface to merge a change). It can all be
> automated via the HTTP API I'm sure, but that wouldn't be much of an
> improvement (if at all) over our current flow.
>
> I suspect not being able to follow the expected way of merging things
> probably further implies that:
>
> - Issues won't be closed automatically since we can't use the merge
> button.
> - Both PR and issues must then be closed manually, which is what we
> currently have
> - The flow would be *even* more confusing than now, since it'd look
> like Github but require committers to use it very differently.
>
> Which would again need more custom tools/scripts as a workaround.
>
> [...]
> Thank you for proposing this GCD!
>
> --
> Maxim
>
I grabbed the following from one of the projects I've found on codeberg,
from an open pull request. The formatting didn't copy over, so I've
reformatted it a bit. I assume if we have "autodetect manual merge"
turned on then we wouldn't get the warning listed next to merge.
x This pull request has changes conflicting with the target branch.
* src/actions/repo/create.rs
↓ View command line instructions
# Checkout
From your project repository, check out a new branch and test the changes.
```
git fetch -u https://codeberg.org/gekkowrld/codeberg-cli list:gekkowrld-list
git checkout gekkowrld-list
```
# Merge
Merge the changes and update on Forgejo.
Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.
```
git checkout main
git merge --no-ff gekkowrld-list
git push origin main
```
--
Efraim Flashner <efraim <at> 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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 05 Mar 2025 12:25:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-23 16:20, Ludovic Courtès wrote:
> Hello Guix!
>
> [...]
> ## 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).
>
> Note that 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.
>
> If and when the project migrates, we will incrementally adjust our
> workflow to ensure it scales better.
There is one thing I'm not sure someone raised earlier about ownership
and ease of access to data.
I hate a lot of AI usage/goals , but I think we should take advantage of
the research in this field when convenient and for a worthwhile goal
(that is : not making money by stealing people's attention). It seems we
have a tremendous amount of data (for git commits, git commit messages,
email exchanges) that could be used to train specialized AI agents that
could be very useful in CI / development contexts. A few examples on the
top of my mind:
- a commit message help complying with GNU standards
- a "rebuilder" agent, to try and rebuild a package that has failed when
the change is trivial (such as ignoring a test / try updating a
dependency). (This could be a "crew" of agents checking for
compilability, lints, build failures... with MCP protocoal and each
agent having its specific training data / RAG). (The goal is not to make
the user less responsible but instead waste less time doing what is
trivial.) Think about it : when rebuilding a package that is core to a
build-system, such as python, instead of spending the most part of a
week doing minor tweaks on hundreds packages, just let the background
job run a week until it only leaves "truly" difficult packages for teams
and maintainers. With some luck, since the tasks could be specialized,
we might already have enough data to train internally.
What's really good is that we might be able to only use guix data to
train and use this kind of helpers. Accessing this data in batch,
through the git repository, mailing lists, failed logs from build
farms..., is possible at this date.
Even if that would demand a coordinated effort anyway, I think the move
to codeberg would make this more difficult ; I also think guix's guile
and lists coherence is a strong advantage we don't take enough in
consideration (I don't think Nix would be able to have these kind of
helpers around, whereas it seems doable in Guix).
(This is not against moving to codeberg, but more about being mindful of
what we might loose on this aspect).
--
Best regards,
Nicolas Graves
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 05 Mar 2025 15:40:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Nicolas,
Nicolas Graves <ngraves <at> ngraves.fr> skribis:
> have a tremendous amount of data (for git commits, git commit messages,
> email exchanges) that could be used to train specialized AI agents that
> could be very useful in CI / development contexts. A few examples on the
> top of my mind:
> - a commit message help complying with GNU standards
> - a "rebuilder" agent, to try and rebuild a package that has failed when
> the change is trivial (such as ignoring a test / try updating a
> dependency). (This could be a "crew" of agents checking for
> compilability, lints, build failures... with MCP protocoal and each
> agent having its specific training data / RAG).
I’m skeptical to say the least, as I wrote elsewhere regarding
<https://doi.org/10.1109/SC41406.2024.00090> — but this is off-topic.
> Even if that would demand a coordinated effort anyway, I think the move
> to codeberg would make this more difficult ;
Overall, the API that Codeberg and similar services provides makes it
easier to grab data about a project, not more difficult, first and
foremost because there’s one uniform API to access everything: issues,
pull requests, CI/CD reports, repo activity, and much more.
This can be seen in “empirical software studies” such as those submitted
to the Mining Software Repositories (MSR) conference. None of what’s
done in these studies would be possible when dealing with a patchwork of
informally-connected tools like the one we have.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 05 Mar 2025 16:24:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>> Developing and maintaining this software and infrastructure is
>> time-consuming. Worse, it leaves contributors largely dissatisfied for
>> a variety of reasons:
>
> I don't think maintaining the infrastructure *that would be replaced*
> has been too time consuming.
Let’s not underestimate the development work by Ricardo, Arun, and Chris
over these tools for years (7 years for mumi), but also the everyday
sysadmin work done to keep things running.
> Sure, Mumi has had some issues and needed some fixing, but most of
> what is used today:
>
> - Savannah (git hosting)
> - Debbugs (bug tracker) & Mumi
> - Git configs/hooks
> - Contributing documentation
>
> rarely ever changes and has been stable, all while being generously
> hosted, without limits on repository size or other criteria, on
I wouldn’t say that Savannah has been stable; debbugs.gnu.org is running
an unpublished, non-version-controlled fork of the original Debbugs
running on a single machine, manually-modified every now and then (I
know because I tried to rectify this back then, and so did Felix I
believe).
I agree that maintenance of these is largely a given for Guix. But
let’s not idealize it: there is a huge technical debt in all this
infrastructure.
> freedom-respecting hardware and a friendly associated org (FSF/GNU),
> which I assume can't be said of Codeberg (w.r.t. using free software
> friendly hardware, such as using the GNU Boot bootloader).
That may be true, but I wouldn’t blame them given what it costed us to
run one server with a free BIOS¹. Codeberg/Forgejo volunteers are free
software activists though.
¹ Andreas gave a good account of this story in
<https://10years.guix.gnu.org/video/ten-years-of-failures/>.
> The parts that have required the most maintenance would be, I assume, CI
> (Cuirass) and QA (Guix Build Coordinator), but these components will
> continue to be used in the event we migrate to Codeberg, so we wouldn't
> gain much on the maintenance side, it seems.
Correct. Though, as the GCD states, it would reduce the number of
services and amount of code to maintain (Patchwork, email parsing, etc.)
> I believe some of the above, such as notifying everyone involved in a
> ticket's discussion when replying, has been/could be tackled in the
> improved GNU Debbugs rewrite that Felix has been refining and testing
> [0, 1]. I think improving Debbugs for the whole of GNU (the Emacs
> project actively use it still for example) would make sense and is
> something I've been meaning to do, but not high in my priority list
> (since it already works well enough for the most part). Hacking a small
> Perl code base doesn't appear much more daunting than the modern
> Go-written, web framework library heavy mastodon I assume
> Gitea/Forgejo is, so I'm not sure why we wouldn't try this first
> instead. I can't help but feel like we'd be throwing the baby out with
> the bathwater: in my view, the current situation is not as bad as
> suggested in your outlook, though I agree further automation and
> simplifications would be welcome.
I held this view for many years, which is part of why we have this
infrastructure; we’re not throwing the baby with the bathwater, we have
a decade of experience. I think this endeavor hasn’t been as fruitful
as we had hoped for and that it’s holding back the project now.
(For the record, Forgejo is known to be lightweight; the code base is
“human-sized” and easy to navigate IME.)
> My reading of the survey's results was that the main concern of the
> community was packages' freshness and availability. Our backlog is
> already larger than we can handle.
As others noted, better tooling is likely to improve reviewer
throughput. Of course nobody can guarantee any speedup, but there are
hints suggesting that.
I have been using the PR style (initially reluctantly) for Guix-Science,
Guix-HPC, and related repositories; I find it easier to see where my
attention is needed and what the status of patches is.
That’s also the reason I’ve been inviting people to give it a try: I
initially knew very well what I loved about the email workflow and what
I hated about the PR workflow, but only through experience did I
discover good things about the PR workflow.
> One serious usability quirk I can foresee is that given our current
> PGP-based security design,
The “Merge” button would be disabled, as noted in the GCD.
> - Issues won't be closed automatically since we can't use the merge
> button.
There’s an “autodetect manual merge” feature; it’s not as “auto” as one
might like but it’s okay.
> - Both PR and issues must then be closed manually, which is what we
> currently have
Issues are closed automatically upon “Fixes #123” messages in commits.
Please give it a spin; it’s not perfect but it’s much better than what
you suggest. :-)
> I'd like to suggest extending the 'trial' period to something much
> longer, like a year or so, to make sure our parachute is properly
> installed before jumping the cliff :-). Letting both systems co-exist
> and compete for merit seems a good trial, and we could also extract
> useful data (such as how many contributions were merged on one or the
> other, etc.). It'd be a bit annoying to keep an eye at two places for
> some time, but at least we wouldn't commit to something that may not
> scale/match our peculiar requirements as well as we expected.
As noted in my reply to Arun², I think there’s a risk of splitting the
community if this experiment were too last for several months (Arun
proposed 30-day coexistence period, with eventual migration to Codeberg).
But maybe you can propose wording to amend the GCD?
² https://issues.guix.gnu.org/76503#37
> After such trial we could then vote on whether we want to fully migrate
> to Codeberg, when all regular contributors would have gotten a chance to
> try the new tools and find a flow that works for them, hopefully. With
> this insurance in place, I'd be happy to experiment with Codeberg and
> see whether it truly improves things.
The GCD process is about collectively building a proposal; there’s no
voting. I would encourage everyone to propose changes to the proposal
to address their concerns—it’s a living document.
As for experimenting, I agree and I reiterate my invitation to send
trivial patches to <https://codeberg.org/civodul/guix> (or to
Guix-Science, Guix-Past, etc.). I think this GCD’s discussion period is
the right time to give it a try as it can better inform discussions.
Thanks for your feedback!
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 06 Mar 2025 00:48:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
Ricardo Wurmus <rekado <at> elephly.net> writes:
[...]
> The difference is that you don't need to configure "git send-email" or
> configure a local msmtp to send email to guix-devel or other mailing
> lists. For patches sent to guix-patches we recommend configuring "git
> send-email" to avoid garbled patches.
>
> I know from mentoring people that setting up "git send-email" is a
> real
> hurdle, whereas sending simple emails to participate in discussions on
> a
> mailing list is not.
I believe git has good documentation for that, but yes, someone would
need to put this blurb in their ~/.gitconfig file:
--8<---------------cut here---------------start------------->8---
[sendemail]
smtpEncryption = tls
smtpServer = some-email-server
smtpUser = your-email
smtpPass = your-password
smtpServerPort = 587
assume8bitEncoding = utf-8
--8<---------------cut here---------------end--------------->8---
Which shouldn't be much more difficult than setting up SSH keys to be
able to push to your Codeberg fork, it seems.
--
Thanks,
Maxim
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 06 Mar 2025 09:51:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 76503 <at> debbugs.gnu.org (full text, mbox):
> I believe git has good documentation for that, but yes, someone would
> need to put this blurb in their ~/.gitconfig file:
>
> --8<---------------cut here---------------start------------->8---
> [sendemail]
> smtpEncryption = tls
> smtpServer = some-email-server
> smtpUser = your-email
> smtpPass = your-password
> smtpServerPort = 587
> assume8bitEncoding = utf-8
> --8<---------------cut here---------------end--------------->8---
Also, very good instructions are available at https://git-send-email.io/
I don't see why this is particularly hard. But, for some reason, that
seems to be the general perception. Perhaps it is seen as hard simply
because it is not the mainstream way to do things, and we end up having
to expend a lot of effort to compensate for that. One more hurdle, as it
were.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 06 Mar 2025 16:37:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
Arun, thanks for this analysis. I concur on many points!
On Tue, 25 Feb 2025 at 14:03, Arun Isaac <arunisaac <at> systemreboot.net> wrote:
> In fact, in order to save on disk space, they suggested that we
> encourage our contributors to delete their forks once done. :-D Needless
> to say, that's never going to happen!
Moreover, this raises another concern: Such removal also make the
history harder to access and do not really save disk space, IIUC.
For one example, consider
<https://codeberg.org/guix-science/guix-science/pulls/63>.
As you can see, there is no “Commit“ and no “Files changed“. Why?
Because Alexis deleted the PR branch. Therefore, harder to know what
the PR was about; annoyances.
And the history seems still around. For example, we can access to the
first version [1,2] and compare with the second (force-pushed) version
[3].
Therefore, even using AGit workflow, we need to do some
back-to-the-envelope computations and estimate what is the scale of
Guix. Then ask if Codeberg has the capacity to host us.
Somehow, that’s not an unilateral decision, IMHO.
1: https://codeberg.org/guix-science/guix-science/commit/a333ccb9b729336501ae6c51f2c410b0e84ed200
2: https://codeberg.org/guix-science/guix-science/commit/8ecbff34229c0be0fc06fbd3d20122937fea1967
3: https://codeberg.org/guix-science/guix-science/compare/8ecbff34229c0be0fc06fbd3d20122937fea1967..efa112e41ec881bce47a6a287cad6bf2aaad1a96
> [5]: Quick digression: Users must actually download about 1 GiB of data
> on their first guix pull.
Hum, a bit less than 1GiB of data, no?
--8<---------------cut here---------------start------------->8---
$ git clone https://git.savannah.gnu.org/git/guix.git
Cloning into 'guix'...
remote: Counting objects: 869271, done.
remote: Compressing objects: 100% (173792/173792), done.
remote: Total 869271 (delta 695019), reused 869256 (delta 695009)
Receiving objects: 100% (869271/869271), 486.94 MiB | 441.00 KiB/s, done.
Resolving deltas: 100% (695019/695019), done.
$ du -sh guix
678M guix
--8<---------------cut here---------------end--------------->8---
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 06 Mar 2025 16:38:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi all,
On Wed, 05 Mar 2025 at 10:39, Ricardo Wurmus <rekado <at> elephly.net> wrote:
> The difference is that you don't need to configure "git send-email" or
> configure a local msmtp to send email to guix-devel or other mailing
> lists. For patches sent to guix-patches we recommend configuring "git
> send-email" to avoid garbled patches.
>
> I know from mentoring people that setting up "git send-email" is a
> real hurdle, whereas sending simple emails to participate in
> discussions on a mailing list is not.
While I agree with that about the annoyances of “git send-email”, I also
think that forcing reviewers to have a Codeberg account is a real
hurdle.
Maybe I’ll appear “elitist” but if a person is able to prepare a patch,
then configuring “git send-email” isn’t an issue, IMHO.
Somehow, my opinion on this topic is: we should not focus too much on
the Contributor’s point of view – do not take me wrong, for sure I’m all
for being friendly, welcoming and inclusive; that’s not the point.
Instead, we need to focus on Reviewer’s point of view.
Our main issue: too much contributions and not enough reviewers and not
enough mergers. Nothing new and the same with most of all Free Software
projects, to my knowledge. However, we reach a point where we need to
act because merging patches is too much friction; and sadly both sides,
Contributors and Reviewers.
Therefore, for me, what does the forge bring that helps the reviewers?
For now, the only tiny difference I see is about CI. It’s easier to
automatically build a PR than to automatically extract patches for
building them.
The first time I met* Guix community, it was on December 2018 in
Paris. Well, I also remember that Chris spoke about Continuous
Integration, patchwork and what Chris was doing at the time.
Over the time Chris did an incredible piece of work. When we see QA and
all that, that's amazing! And Ricardo’s initiative with Mumi is also
very nice and helpful – and thanks Arun for nice features!
All that to say, this GCD raises this question: Do we want to put more
effort on CI and QA? Somehow, improve and/or make various bridges
between QA, CI and guix-patches? Or do we drop that part?
Cheers,
simon
*first time I met: If I remember correctly, Ricardo you came by
night-bus and you took a chocolate cake. <3
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 06 Mar 2025 16:38:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
On Fri, 28 Feb 2025 at 23:33, Ludovic Courtès <ludo <at> gnu.org> wrote:
> Examples: I easily lose track of updated patch versions and comments
> because they’re just more unread email in my inbox;
Switch from Gnus to Notmuch. ;-)
Joke aside, I agree that’s annoying…
> because they’re just more unread email in my inbox; contributors
> sometimes lose track of what they sent, so they open a new issue, and I
> find myself digging for the original submission and review;
…and that’s too. Well, I agree it’s become a mess when the thread’s
broken and another issue is open.
However, weeks or months later, you can still easily give a look to the
submission. That’s not the case with PR: when Contributor deletes its
own branch then it’s more complicated, I guess.
One example: https://codeberg.org/guix-science/guix-science/pulls/63
As you see, there’s no Commit or Files Changes because Alexis deleted
the branch – yeah because the PR had been merged! :-) Yeah too that the
PR and history is somewhere but not easily accessible.
Just to point it can also become messy. :-)
Well, I do not have a strong experience on reviewing so I trust your
words when you say Codeberg might help here, eventually.
However, I think I have an experience about dealing with issues. Well,
for what my words are worth, most of what I’ve done are because all the
issues are emails. Somehow, coupling Emacs, Debbugs.el, Notmuch,
piem.el and Org-mode is my way to scale. For sure, I will never do
bug-triage without such tools.
Yes, Codeberg provides a nice API. Yes, it’s up to us to exploit it!
Yes, I’ve started to give a look. :-) But to my knowledge, nothing is
ready.
Therefore, I propose to postpone the discussion about the migration of
the “Issue Tracker”. Currently, it’s not part of our current
limitations, IMHO.
Somehow, I propose to delay the migration of the “Issue Tracker” and
open a GCD once we have 2-3 months of a full experience with the PR
workflow.
WDYT?
Or do I miss a radically awesome feature? :-)
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 06 Mar 2025 16:38:03 GMT)
Full text and
rfc822 format available.
Message #173 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
On Wed, 26 Feb 2025 at 22:01, Ludovic Courtès <ludo <at> gnu.org> wrote:
> I think I was/we were wrong in two ways: first it’s not just about
> providing a web interface, and second there are limitations in our
> workflow that we just cannot overcome, as I tried to explain in the
> “Motivation” section. We tried, very hard, and for a reason: a belief
> (as far as I’m concerned) that we could not only be responsible for our
> infra but also, in a way, that we could show fellow free software
> hackers that an alternative development model was possible.
Have we really tried hard? Not about the maintenance, big thanks for
all guix-sysadmin!
About developing the tools: As a project, I would not say “we tried very
hard”. Chris did, almost alone – thanks Chris for this heroic long-term
commitment effort. And about Cuirass, the last effort had been years
ago, to my knowledge.
As I wrote elsewhere, what are the concrete current features that
Codeberg offers against our limitations?
Our main limitation isn’t about contributing but about reviewing, IMHO.
Therefore how Codeberg is concretely helping? Not what are the
potentialities that Codeberg offers, but what does Codeberg bring on the
table right now compared to our current workflow?
Well, from my understanding, it’s easier to automatically build a PR
than to automatically extract patches and build them. So, Codeberg
helps right now because of CI. Do I miss another feature that helps
reviewing?
> I agree with Leo and the GCD mentions it as well: we need to talk with
> Codeberg e.V. from the start, possibly becoming a voting member, and to
> offer funding.
Hum, are we not putting the eggs before having the basket? :-)
Somehow, instead of a “Big Move”, it seems more approachable to only
move some teams, for example. Something like an incremental
“improvement”. It would help to have a concrete basis for discussing
how we can help them to have a sustainable solution for the Guix
project.
> Codeberg e.V. is specialized so I’d like to believe they have a lot of
> headroom. That they’re transparent and upfront about their scalability
> issues is a rather good sign to me.
What if tomorrow Codeberg closes for whatever the reasons? Obviously,
we will find another solution. :-)
However, what about all the history hosted there? Yes, there is a nice
API and everything is doable. :-) To my knowledge, nothing is done for
having a backup of all the history.
About Debbugs, we have one public-inbox at least. Maybe archived [1] in
Software Heritage since public-inbox is Git-based. ;-)
> Assuming we agree that a move along the lines of this proposal is
> desirable (let me know if you think we don’t share that premise), what
> other options would you think of?
I do not know if I share the premise… Well, for sure, as discussed with
a beer \o/ in Guix Days, I agree that we need to act now because the
current situation raises too much friction and that will be detrimental
for the project in the “short” term.
What I’m not sure about is the path for moving. Somehow, I find it too
much in a hurry. For instance, the GCD reads,
Within **30 days** following acceptance of this GCD, committers would
migrate all these repositories to https://codeberg.org/guix.
For Guix itself, we would decide on a **flag day** 14 days after
acceptance of this GCD at the earliest, and 30 days at the latest. On
that day, the official URL of the Guix repository would become
https://codeberg.org/guix/guix.git.
when we have not yet discussed hard numbers with Codeberg. Or when we
do not have discussed on Guix Foundation side what could be done for
supporting them.
Similarly, why do we need to move in the same time the Issue Tracker?
Somehow, I would prefer a more incremental move. Because it would help
to improve step after step. Maybe using 2 or 3 steps over the whole
2025 year.
Cheers,
simon
1: The first patch sent to guix-patches, SWH still ingesting when
writing this. :-) So maybe here…
https://archive.softwareheritage.org/swh:1:cnt;ce7a09543926f7e5717b7a3f8fa3c1f6d5fdb5f1
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 06 Mar 2025 16:38:03 GMT)
Full text and
rfc822 format available.
Message #176 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Tue, 04 Mar 2025 at 18:26, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> I do want to. But I didn't because I didn't want to overload your
>> personal repo with too many pull requests. Perhaps we can have a pilot
>> period (say 30 days) when both mumi/debbugs patches and codeberg pull
>> requests would be accepted methods to contribute. This may help put
>> people's minds at ease about the transition, and give them some time to
>> adapt their contribution/review worklows.
>
> Yes, having a period where both methods are accepted sounds doable.
>
> The risk is that some things would go unnoticed on one side or the
> other, and during that period we’d be effectively splitting the
> community between “those who prefer email” and “those who prefer
> Codeberg”, but if it’s limited to 30 days max, that’s probably OK.
Well, I think it’s doable to exploit Codeberg API [1]. Maybe an
implementation on Mumi side.
Somehow, it’s doable to have a tool that collects all PR submissions and
opens an issue on Debbugs side. This issue would contain the PR message
and the link to the PR and would have a special subject. For example,
one PR from Guix-Science [2] looks like:
PR#87 WIP: update ghdl to 5.0.1, and add ghdl-lsp.
Please review this submission at:
https://codeberg.org/guix-science/guix-science/pulls/87
This pr updates ghdl to its most up to date release, and renames
ghdl-clang to ghdl-llvm for consistency with upstream
artifacts. It also fixes the two other packages affected by this
renaming.
Then, it adds a new package, ghdl-lsp, including the language
server capabilities of ghdl (in addition to synthesis and
compiler, that we already have). Updating of python-pyvhdlmodel
and python-pytooling (see 76709) is necessary, so I set this pr
to WIP.
Then, we could list all open issues with the subject “PR#“ and query
Codeberg via the API to have the still open PRs. For the closed PR
ones, Mumi just sends a ’done’ control message to Debbugs.
That way, things would not go unnoticed. And you are raising, hey the
submissions to guix-pacthes will be unnoticed by people looking only to
Codeberg. Yes, but! 1. The aim is to move so to encourage people to go
via Codeberg. If the submission is merged faster when open on Codeberg,
then we’ll see the natural migration. ;-)
2. In that cases, etc/teams.scm will still CC teams people so it’s a
mitigation.
This way, it would avoid “The Big Move” and would allow something more
incremental. For example, I would prefer to have a spread team-basis
migration instead of some quick all-or-nothing migration.
Cheers,
simon
1: https://codeberg.org/api/swagger
PS: Obviously, I volunteer to contribute in the implementation of such
bridging tools. :-)
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 06 Mar 2025 17:41:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Sun, 02 Mar 2025 at 18:07, runciter--- via Guix-patches via <guix-patches <at> gnu.org> wrote:
> Git has a 'request-pull' sub-command:
>
> git request-pull [-p] <start> <URL> [<end>]
Do you mean send to guix-patches the output of this command?
If yes, it would still require that the emails is well-formed. Then, it
would also require to adapt current extractors in order to get the
repository.
Such submission would create a temporary branch somewhere, because the
Contributor who submitted the request-pull could delete their own branch
and/or repository and/or the repository could be down. Therefore, it
would also require to adapt current tooling in order to delete the
branch once the submission is merged (Debbugs issue closed, roughly).
In addition, it would require to adapt again when it’s the second, third
or more revision of the submission.
Last, it would not be possible – to my knowledge – to comment on a patch
basis but you could only have one unique diff of the whole series.
This latter point appears to be a blocker for an alternative.
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 06 Mar 2025 17:41:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
I agree with most of Maxim’s message. I add two points.
On Tue, 04 Mar 2025 at 20:22, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
> I see the argument that there's an HTTP API for Forgejo; that's great,
> but it requires that everyone relearn another way of doing something
> that already works well enough for me and others, which I'm not too
> excited about. I also assume the Forgejo-related tooling, given their
> young age, would not be as mature and missing features in places, and
> that it would require invested time to comfortably do all that can be
> done today in Gnus and Emacs Debbugs, away from the web interface, in
> the environment of choice (Emacs) of perhaps a majority of the Guix
> contributors.
a) Today, it’s not possible to work offline or by batch. To my
knowledge, there is no tool; at least nothing compatible with
Emacs.
b) Today, it’s not possible to comment on patches without the
web-interface, to my knowledge; least nothing compatible with
Emacs.
( Aside, through my own glasses, it would be a blocker. But I’ve myopia
and I know all people do not have the same lenses. ;-) I mean, I agree
that our workflow reach some limitations and that we need to act now
for helping the review/merge workload. Well, I’m adjusting my
glasses. :-) )
>> Within **30 days** following acceptance of this GCD, committers would
>> migrate all these repositories to https://codeberg.org/guix.
>>
>> For Guix itself, we would decide on a **flag day** 14 days after
>> acceptance of this GCD at the earliest, and 30 days at the latest. On
>> that day, the official URL of the Guix repository would become
>> https://codeberg.org/guix/guix.git. A commit would reflect that by
>> updating:
>
> I'd like to suggest extending the 'trial' period to something much
> longer, like a year or so, to make sure our parachute is properly
> installed before jumping the cliff :-).
I agree. I propose 1. To design the move of the basis of teams in order
to be a bit more incremental [1]. And 2. To help in implementing a
simple one-way bridge [2]: report the open PR inside Debbugs.
Cheers,
simon
1: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <zimon.toutoune <at> gmail.com>
Thu, 06 Mar 2025 17:36:29 +0100
id:874j066rqq.fsf <at> gmail.com
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/874j066rqq.fsf <at> gmail.com
https://yhetil.org/guix/874j066rqq.fsf <at> gmail.com
2: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <zimon.toutoune <at> gmail.com>
Thu, 06 Mar 2025 17:35:25 +0100
id:875xkm6rsi.fsf <at> gmail.com
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/875xkm6rsi.fsf <at> gmail.com
https://yhetil.org/guix/875xkm6rsi.fsf <at> gmail.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 06 Mar 2025 20:06:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Simon,
> Somehow, my opinion on this topic is: we should not focus too
> much on
> the Contributor’s point of view – do not take me wrong, for sure
> I’m all
> for being friendly, welcoming and inclusive; that’s not the
> point.
> Instead, we need to focus on Reviewer’s point of view.
I agree, you are right about this.
I must admit that while I'm in favor of this GCD I'm not familiar
with
the PR workflow *at the scale of Guix*.
We will need tools in support of a reviewer's workflow. I tend to
easily get lost, whether that's on issues.guix.gnu.org and mailing
list
discussions, or on forges with many issues. In the documentation
of API
endpoints for codeberg.org I have not seen anything that roughly
equates
to "needs my attention".
It seems that on Codeberg the primary means of keeping track of
things
is through notifications. I fear I might still end up dropping
the ball
when a PR requires my attention if it gets buried in countless
notifications -- especially if I have to keep them unread to ever
have a
chance of finding them again. Obviously, a fix here would be to
adjust
my behaviour and not let notifications pile up, but this has no
chance
of ever happening. (In completely unrelated news: I've got 17532
unread
Guix emails.)
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 06 Mar 2025 23:35:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Simon,
> For one example, consider
> <https://codeberg.org/guix-science/guix-science/pulls/63>.
>
> As you can see, there is no “Commit“ and no “Files changed“. Why?
> Because Alexis deleted the PR branch. Therefore, harder to know what
> the PR was about; annoyances.
Thanks for raising this. This is a very important point. Losing history
like this seems very bad. Ideally, we want to have an archive of every
conversation and contribution that went into the project. Emails provide
this. If Codeberg does not, we should rethink our move.
I would also be in favour of postponing this GCD so that the
guix-science channel team can gain more experience with Codeberg and the
PR workflow. Quirks and annoyances like the above can only be found with
more time. guix-science moved to Codeberg only in January, IIUC. It's a
bit too soon to move the rest of Guix. Postponing the migration will
also give us more time to develop automation around Codeberg and see how
well that works out.
>> [5]: Quick digression: Users must actually download about 1 GiB of data
>> on their first guix pull.
>
> Hum, a bit less than 1GiB of data, no?
Yes, indeed, I said "about" 1 GiB. I was providing approximate
human-readable numbers. :-)
Regards,
Arun
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 03:28:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello Guix devs,
I concur with Ekaitz’s observation:
> We would be pushing that complexity only to committers, not to
> ocasional contributors, which may help attracting people. But, on the
> other hand, we would force people who is already very busy (and very
> efficient with their current workflow) to discard their way to do
> things and learn another.
Almost all large-scale FOSS projects have fouond this time and time again, even something like Linux kernel, that occasional contributors are large in number but are not reliably persistent in continuing their contributions. Of course we should make it easier for more and more people to contribute and work with us, but we should be wary of what that might cost the existing state of contributions, the bulk of which are done by regular committers over more than a decade, and how that might be affected.
Similarly, I also agree with Maxime’s concern:
> The complexity of the flow can be partly explained by the fact that there
> isn't only one flow possible, but a multitude of flows (Emacs Debbugs,
> Mumi, git send-email, etc.), which is more of a strength than a defect
> when it comes to the freedom of choice/flexibility for our contributors.
>
> I see the argument that there's an HTTP API for Forgejo; that's great,
> but it requires that everyone relearn another way of doing something
> that already works well enough for me and others, which I'm not too
> excited about. I also assume the Forgejo-related tooling, given their
> young age, would not be as mature and missing features in places, and
> that it would require invested time to comfortably do all that can be
> done today in Gnus and Emacs Debbugs, away from the web interface, in
> the environment of choice (Emacs) of perhaps a majority of the Guix
> contributors.
We might be prone to underestimate not only the effort that we’ve already put into in continuing what exists, but also a bit too haste in judging it as dysfunctional. As has been said elsewhere by Suhail and others, the Codeberg migration is no panacea. That said, we of course need to admit that our existing workflow has a lot of cruft and problems. But as I’ve said before, both with regards to the Codeberg migration and the GNU affiliation, a more reflective and integrative approach is better than something that leaves a lot of things hanging.
Maxime is accurate in being wary of a quick migration:
> I'd like to suggest extending the 'trial' period to something much
> longer, like a year or so, to make sure our parachute is properly
> installed before jumping the cliff :-). Letting both systems co-exist
> and compete for merit seems a good trial, and we could also extract
> useful data (such as how many contributions were merged on one or the
> other, etc.). It'd be a bit annoying to keep an eye at two places for
> some time, but at least we wouldn't commit to something that may not
> scale/match our peculiar requirements as well as we expected.
>
> After such trial we could then vote on whether we want to fully migrate
> to Codeberg, when all regular contributors would have gotten a chance to
> try the new tools and find a flow that works for them, hopefully. With
> this insurance in place, I'd be happy to experiment with Codeberg and
> see whether it truly improves things.
We have a *humongous* backlog of patches, and the committers are probably more aware of this than me, of course, but I couldn’t find satisfactory proposals to resolve that in the GCD. Even if we were to move to Codeberg within the next week, what we already have will take at least a year, assuming a good chunk of the committers put a lot of work in reviewing the backlog *while* also handling the new PRs that are being issued from Codeberg. And since our whole point was to make it "easier" for new contributors, there’s a good probability that indeed initially there’ll be a surge of people trying to contribute PRs. That is *good*, but are we ready to handle it alongside the older patches?
Here is a proposal which might be considered in keeping an integrative system:
Assuming we *should* move to Codeberg, we recognize the fact that such a move primarily solves one problem *fully* without any reservations: letting a larger scale population of Guix users to have an easier pathway towards contribution. While some of us, including me, can consider it a misfortune that this is indeed the way people are conditioned, it’s beyond our scope to solve it.
That said, we also have a smaller set of people, i.e. committers, who are proficient in a workflow that has several perks to it, and arguably better than the previous one, but it is not common among newcomers.
To achieve our goal of helping newcomers, we keep a regularly updated mirror of Guix on Codeberg with issues and PR features enabled. Whoever wishes to contribute, can create an issue, or fork and make a pull-request directly on Codeberg with their desired workflow (which arguably is largely the web approach). Here we have a committer or two to handle the Codeberg repository, label issues, and organize things, but *not* for reviewing patches.
Instead, we host a backend service that regularly checks the Codeberg repository for any new issues or PRs and then communicates to us through the Codeberg’s Forgejo API [0] the content of said issues and PRs. The data received from the API then gets directed to our Debbugs or Mumi backend, which parses the information from it and opens a new Debbugs issue for it. Thus, for every issue opened on Codeberg, we have a mirrored Debbugs issue, and same for PRs where the diff can be then parsed into a valid patch.
To be noted that such mirroring is strictly one-directional initially, every issue opened previously or opened later shouldn’t get mirrored into the Codeberg repository. If we assume that only committers are the people fluent and wanting of email-based workflow, the new Debbugs issue would only be created by them, while we encourage newcomers to always report through Codeberg’s issue tracker.
Since Codeberg already allows to communicate in issues over email, i.e. you can respond to someone in a particular issue over email, this shouldn’t be too difficult to arrange.
Newcomer opens issue #xxyz -> Debbugs/Mumi mirror it and create xxyz <at> debbugs.gnu.org -> Interested committer responds to it over his desired email workflow -> It reaches the newcomer without him having to open email.
I argue the same workflow can be replicated for pull-requests as well, without the need for any "merge button". We remind ourselves that the need for a PR/GitHub/Web workflow is to cater newcomers, who have nothing to do with merge issues but everything to do with forking and contributing changes. Ergo, the only part of the PR workflow we need is it’s creation, not the entire package of fork->pull->merge->commit. The latter two are to be under the responsibility of committers, who will not have to change any part of their workflow. As described above, they’ll get the PRs rendered to them as good ol’ git patches, over mail and they can apply them, work on merge issues and get back to the newcomer contributor over email. The only additional part in the case of PRs would be the need to replicate the patches also across guix-patches mailing list.
I know this requires some setting up, but we need such time and effort in any case if we decide to migrate and not fall into the issues Ekaitz and Maxime pointed out. With the help of Codeberg people for their API, and the knowledgeable people on Debbugs such as Felix, Arun, Ricardo et.al, this might be a feasible task. I am also willing to contribute in whatever way and means possible, since I’m slowly working myself towards contributing more and more to Guix. And even though I’m not a committer, I retain the email-based workflow through Gnus and debbugs.el. So, it will help me as well.
Let me know what you think.
[0]: https://codeberg.org/api/swagger
Regards,
--
Divya Ranjan,
Philosophy, Mathematics, Libre Software.
PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 05:11:01 GMT)
Full text and
rfc822 format available.
Message #194 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Divya,
On Fri, Mar 07 2025, Divya Ranjan via Guix-patches via wrote:
> To achieve our goal of helping newcomers, [...]
I don't think this is a fair summary of the goal. The first sentence of
the GCD[1] is:
The contribution workflow in Guix has been facing several challenges:
difficult onboarding, lack of legibility, complex, unreliable, and
labor-intensive infrastructure, and lack of automation.
Of these, only "difficult onboarding" is about newcomers. Your proposal
(which I might describe as "proxy Codeberg into debbugs") involves
building new infrastructure without helping the other issues.
> Since Codeberg already allows to communicate in issues over email,
> i.e. you can respond to someone in a particular issue over email, this
> shouldn’t be too difficult to arrange.
This is not true today. While Forgejo supports replying via email,
Codeberg does not have that enabled due to bugs. They have an issue
tracking it: https://codeberg.org/Codeberg/Community/issues/1562
Even if it was true, the big disconnect here would be around commenting
on specific lines of code. An email with a comment on a patch would come
through as a top-level comment on the PR, which is not natural in that
context.
Carlo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 05:23:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Arun Isaac <arunisaac <at> systemreboot.net> writes:
> Hi Simon,
>
>> For one example, consider
>> <https://codeberg.org/guix-science/guix-science/pulls/63>.
>>
>> As you can see, there is no “Commit“ and no “Files changed“. Why?
>> Because Alexis deleted the PR branch. Therefore, harder to know what
>> the PR was about; annoyances.
>
> Thanks for raising this. This is a very important point. Losing history
> like this seems very bad. Ideally, we want to have an archive of every
> conversation and contribution that went into the project. Emails provide
> this. If Codeberg does not, we should rethink our move.
If you read through the Conversation section, you can see a message for
every time commits were added to the branch or it was force-pushed. If
you click on the commit hashes or subjects in these messages, it takes
you to a description of the commit, featuring a diff and files changed.
In this way you can see every iteration of the PR, just like we have
every patch revision in our mailing-list archives.
One thing I particularly like is that the final message (well, the one
before 'deleted branch *typst*') shows you the commit that was finally
merged. On the mailing lists, many of the issues are closed with a
message like 'applied with minor tweaks, thanks', and not all committers
will note the commit hash - so you're left grepping for the patch
subject line in `git log` if you want to know what tweaks were made.
Codeberg automatically notes the hash, and you can see the final
iteration just by clicking on it!
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 06:19:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello Carlo,
> I don't think this is a fair summary of the goal. The first sentence of
> the GCD[1] is:
>
> The contribution workflow in Guix has been facing several challenges:
> difficult onboarding, lack of legibility, complex, unreliable, and
> labor-intensive infrastructure, and lack of automation.
>
> Of these, only "difficult onboarding" is about newcomers. Your proposal
> (which I might describe as "proxy Codeberg into debbugs") involves
> building new infrastructure without helping the other issues.
You are correct, Carlo, the GCD does have multiple goals. But in my email I also elaborated how the onboarding issue is a high-priority task, reflective from the last survey and also something that can be achieved without risking too much. I believe we are at a probabilistic trade-off decision here, do we wish to achieve all the goals, including a complete change of infrastructure, workflow etc. in the proposed timeline of 15 days or so, and thus incurring a lot of problems that a team of committers would’ve to put a lot of effort into resolving? Or, do we wish to slowly achieve some of the goals, take those goals as a litmus test for the overall proposal and proceed gradually? I believe latter would be a safer bet, with less to risk immediately and opportunity to fix mistakes from feedback.
So, yes, my proposal cannot resolve all the goals, but I am trying to find a way to integrate what we have with what we might switch to. I might be at fault here, and feel free to elaborate on that, such as how can we approach the proposed quick migration to Codeberg while having a huge backlog of patches?
>> Since Codeberg already allows to communicate in issues over email,
>> i.e. you can respond to someone in a particular issue over email, this
>> shouldn’t be too difficult to arrange.
>
> This is not true today. While Forgejo supports replying via email,
> Codeberg does not have that enabled due to bugs. They have an issue
> tracking it: https://codeberg.org/Codeberg/Community/issues/1562
Thank you for this. I had tried it on a Forgejo repository, not a Codeberg one, so I believed the same could be possible here as well. From the discussions I see, if we spend enough time with them--which we need to do either ways--for the migration, they might get it working? Does not look far from possible to me.
> Even if it was true, the big disconnect here would be around commenting
> on specific lines of code. An email with a comment on a patch would come
> through as a top-level comment on the PR, which is not natural in that
> context.
Also thank you for bringing this issue, indeed this is a crucial functionality. But to be clear, this is specifically for a pull-request. The issues functionality is totally doable out of the box with Forgejo, we just need to make it work with Codeberg and polish it. With regards to the PR, one has to remember that the entire process needs to be wrapped around Forgejo’s API, not as our used to method of plain text. We’d be parsing JSON to-and-fro. For "reviewing a Pull Request" in Codeberg methodology, Forgejo provides a =/repos/{owner}/{repo}/pulls/{index}/reviews= API[0] to initiate a review. This API will take the comments from the patch in the Email, place them in the "body" string of the JSON, and the respective positions from the diff, the commit_id and so on. I agree it is non-trivial, but so is switching a workflow that has been in-place for years, also a non-trivial task. I think the API has enough things for what we need. And again, we don’t need all of them, we only require implementing those for now that bridge existing email workflow and the newcomers’ onboarding. Merging, for example, I propose to be done in the usual way of taking a patch and applying it. Eventually once we have less of a backlog, and more ease of migration, one might consider moving these core tasks to the Codeberg as well.
Either ways, we are at the crossroads and we need to decide which trade-off is worth the pain. I believe it is *not* certain that once we entirely migrate to Codeberg, the goals of "complexity" and "lack of legibility" would be immediately reaped. It creates a possibility of enjoying them, but given the assumption that the switch from existing architecture is smooth. And, once again, if we were a relatively smaller project such as the Guix-Science, this could’ve been a decision much simpler and with less at stake, but that is not the case. But I think it *is* certain that if we take an approach that doesn’t directly replace one workflow with another, but bridges the new one with the previous one, the committers will have a better way to switch. Simply because they can try to finish the backlog using the existing workflow, and the new patches can come to them with that as well. Where we go from there, can be decided upon how good the litmus test goes.
[0]: https://codeberg.org/api/swagger#/repository/repoCreatePullReview
Regards,
--
Divya Ranjan,
Philosophy, Mathematics, Libre Software.
PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 09:23:02 GMT)
Full text and
rfc822 format available.
Message #203 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Divya Ranjan <divya <at> subvertising.org> writes:
> We have a *humongous* backlog of patches, [...]
> [...] we host a backend service that regularly checks the
> Codeberg
> repository for any new issues or PRs and then communicates to us
> through the Codeberg’s Forgejo API [0] the content of said
> issues and
> PRs. The data received from the API then gets directed to our
> Debbugs
> or Mumi backend, which parses the information from it and opens
> a new
> Debbugs issue for it. Thus, for every issue opened on Codeberg,
> we
> have a mirrored Debbugs issue [...]
So at the end we'd have an even larger backlog of patches, and
spread
across two systems...? And where do we source the time and
motivation
to hack on yet another piece of software? Outside contributions
to mumi
have been *very* few in all these years; that's not for a lack of
problems we've had with the system, and for once it's not for a
lack of
review either.
As a long time contributor with commit access I have the
impression that
people new to Guix hold the assumption that the current system and
workflow works for long time contributors. I may just be wildly
incompetent, but for me it most assuredly does not work in
enabling
reviews. I mostly review patches that were sent to me directly or
that
happen to solve a problem I'm trying to solve as part of my
maintainance
work.
The haphazard GNU fork of Debbugs also lacks a number of features,
has
odd unaddressed bugs, lacks people who even understand in what
ways it
differs from the Debian version, lacks people working on improving
it
and addressing these issues. (There is literally *one* person who
keeps
the lights on.)
It does not even do simple things like delivering notifications to
*everyone* who participates in an issue discussion. This is the
reason
for the sudden eery silence that can be seen in many issues.
I honestly have my doubts that the move to Codeberg would
automatically
solve all of my workflow issues, but let's please not eulogize the
email-based workflow too much. It makes sense to me to base our
efforts
on a system that is *actively* developed by a *team* of aligned
free
software hackers.
I don't see an active future for the GNU fork of Debbugs, and I
think it
is not a good use of our time to work on a system that won't
improve
unless we burden ourselves with even more work (like taking over
hosting
and administration). I'd rather work on Guix.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 10:27:02 GMT)
Full text and
rfc822 format available.
Message #206 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
I also agree that we should either not switch, or switch with a short
period of overlap. It does not make sense to spread our limited time to
work on two systems at the same time. And it definitely does not make
sense to spend additional development work (by whom?) to create a bridge
between the two.
Am Fri, Mar 07, 2025 at 10:21:48AM +0100 schrieb Ricardo Wurmus:
> It does not even do simple things like delivering notifications to
> *everyone* who participates in an issue discussion. This is the reason
> for the sudden eery silence that can be seen in many issues.
And it is something I learnt just recently after more than ten years of
contributing to Guix! If I understood correctly, it does not even alert
the original submitter. Probably I have closed a few issues because the
submitter had not read my comments or request for more information and
I had deduced that they were no longer interested. This alone would be a
reason for me to switch to a different system. We claim that our workflow
is "email based", but in fact it is not: To be informed about issues I
have contributed to, I need to keep each and every one in a bookmark and
visit it with my web browser regularly. At least in the forges I have seen
so far, I get an (often cryptic) email message when something happens
that entices me to connect to the web.
Anyway, I usually look at QA and the issues on the web when I have time
for a little committer work. The situation in which email works is when
I get an automatic copy for a patch touching one of my teams (and this
is very useful).
The overly graphic nature of these web forges makes them somewhat
confusing. For instance, it took me a little while to understand where
the trivial little patch was for an issue on Ludovic's test instance,
until I realised I needed to click once more. issues.guix.gnu.org is
much more focussed and less cluttered.
On the other hand, as soon as there is a patch series on issues, it also
becomes more or less unreadable; after 5 versions of a 6-patch series,
it becomes difficult to find the start of the current version and all
comments in between.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 11:31:01 GMT)
Full text and
rfc822 format available.
Message #209 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Re,
On Thu, 6 Mar 2025 at 17:36, Simon Tournier <zimon.toutoune <at> gmail.com>
wrote:
> 1: The first patch sent to guix-patches, SWH still ingesting when
> writing this. :-) So maybe here…
>
>
https://archive.softwareheritage.org/swh:1:cnt;ce7a09543926f7e5717b7a3f8fa3c1f6d5fdb5f1
Modulo the typo 's/;/:/' :-) The first patch sent to guix-patches is
archived in Software Heritage, FWIW.
https://archive.softwareheritage.org/swh:1:cnt:ce7a09543926f7e5717b7a3f8fa3c1f6d5fdb5f1
Cheers,
simon
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 14:41:02 GMT)
Full text and
rfc822 format available.
Message #212 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> As for experimenting, I agree and I reiterate my invitation to send
> trivial patches to <https://codeberg.org/civodul/guix> (or to
> Guix-Science, Guix-Past, etc.). I think this GCD’s discussion period is
> the right time to give it a try as it can better inform discussions.
Based on Andreas's observations in [1]:
#+caption: <https://yhetil.org/guix/Z8rJyIIUR84pWdLS <at> jurong/>
#+begin_quote
On the other hand, as soon as there is a patch series on issues, it also
becomes more or less unreadable; after 5 versions of a 6-patch series,
it becomes difficult to find the start of the current version and all
comments in between.
#+end_quote
It seems if we are basing our experimentations on only "trivial patches"
that are sent to <https://codeberg.org/civodul/guix>, we may not be
observing the instances where a forge-style review process actually
struggles; our conclusions may be flawed.
[1]: <https://yhetil.org/guix/Z8rJyIIUR84pWdLS <at> jurong/>
--
Suhail
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 15:38:02 GMT)
Full text and
rfc822 format available.
Message #215 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Suhail Singh <suhailsingh247 <at> gmail.com> writes:
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> As for experimenting, I agree and I reiterate my invitation to
>> send
>> trivial patches to <https://codeberg.org/civodul/guix> (or to
>> Guix-Science, Guix-Past, etc.). I think this GCD’s discussion
>> period is
>> the right time to give it a try as it can better inform
>> discussions.
>
> Based on Andreas's observations in [1]:
>
> #+caption: <https://yhetil.org/guix/Z8rJyIIUR84pWdLS <at> jurong/>
> #+begin_quote
> On the other hand, as soon as there is a patch series on
> issues, it also
> becomes more or less unreadable; after 5 versions of a 6-patch
> series,
> it becomes difficult to find the start of the current version
> and all
> comments in between.
> #+end_quote
>
> It seems if we are basing our experimentations on only "trivial
> patches"
> that are sent to <https://codeberg.org/civodul/guix>, we may not
> be
> observing the instances where a forge-style review process
> actually
> struggles; our conclusions may be flawed.
We have had non-trivial patches with a number of revisions on the
guix-science channel.
Examples:
https://codeberg.org/guix-science/guix-science/pulls/59
https://codeberg.org/guix-science/guix-science/pulls/75
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 16:02:01 GMT)
Full text and
rfc822 format available.
Message #218 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ricardo,
On Fri, Mar 07 2025, Ricardo Wurmus wrote:
> I'd rather work on Guix.
Then why is there a backlog of bugs?
I only see a group of software developers unable to close more bugs than
are being opened.
It's not because of technical limitations, but because the committers
are overwhelmed by the overall bug volume, are afraid to trigger
rebuilds or make other big changes, and are generally overworked
volunteers who also want to do other things in their lives.
> I don't see an active future for the GNU fork of Debbugs
There could be. I mated Debbugs with Public Inbox.
My system scans Debbugs for changes [1] but does not yet maintain
inboxes by bug number. The information is available via the NNTP news
protocol, for example with the Gnus configuration below. People could
subscribe to bugs via a news reader and reduce their mail load.
> [Debbugs] does not even do simple things like delivering notifications
> to *everyone* who participates in an issue discussion.
Debbugs does not copy folks automatically because many do not want it.
In Debian, submitters are often non-technical people. They do not care
about how a problem is solved, only when it is. Debbugs does that.
Kind regards
Felix
[1] https://patchwise.org/inbox/bugs-to-scan/
* * *
(setq gnus-select-method
'(nnimap "patchwise.org"
(nnimap-authenticator anonymous)
(nnimap-port "imap")
(nnimap-stream network)))
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 16:04:02 GMT)
Full text and
rfc822 format available.
Message #221 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
Am Fri, Mar 07, 2025 at 09:40:28AM -0500 schrieb Suhail Singh:
> Based on Andreas's observations in [1]:
> It seems if we are basing our experimentations on only "trivial patches"
> that are sent to <https://codeberg.org/civodul/guix>, we may not be
> observing the instances where a forge-style review process actually
> struggles; our conclusions may be flawed.
my observation was rather the inverse: our current debbugs approch
struggles for patch series. For the submitters, this starts with a
series of size 2 (whenever I have one of these, I look up the Guix
manual on the web and follow the process described there; yet another
example where what I do is actually web based). For reviewers and
committers, series with a few commits are still okay.
Which says nothing about the experience on a forge, logically.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 16:20:01 GMT)
Full text and
rfc822 format available.
Message #224 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Felix,
> On Fri, Mar 07 2025, Ricardo Wurmus wrote:
>
>> I'd rather work on Guix.
>
> Then why is there a backlog of bugs?
This is such an odd thing to ask, I cannot convince myself that
it's a
serious question asked in good faith. Surely you are not
suggesting
that my desire to work on Guix rather than doing sysadmin work or
hacking on infrastructure (which I *have* in fact been doing for
years
in service of the Guix project, even if you might be unaware of
it)
would be sufficient in reducing the backlog of bugs?
> I only see a group of software developers unable to close more
> bugs than
> are being opened.
>
> It's not because of technical limitations [...]
I don't know how you can make this claim with confidence. You
are, of
course, welcome to reject my experience here, but (like your
question
above) that's a really odd way of conducting yourself in a
discussion.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 16:45:01 GMT)
Full text and
rfc822 format available.
Message #227 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Andreas Enge <andreas <at> enge.fr> writes:
> my observation was rather the inverse: our current debbugs approch
> struggles for patch series.
Ah, my bad. I mistook "issues" to mean issues on a forge as opposed to
a debbugs issue. Thank you for correcting.
> Which says nothing about the experience on a forge, logically.
True.
--
Suhail
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 16:47:01 GMT)
Full text and
rfc822 format available.
Message #230 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Ricardo Wurmus <rekado <at> elephly.net> writes:
> We have had non-trivial patches with a number of revisions on the
> guix-science channel.
>
> Examples:
>
> https://codeberg.org/guix-science/guix-science/pulls/59
> https://codeberg.org/guix-science/guix-science/pulls/75
Thank you for sharing!
--
Suhail
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 17:03:02 GMT)
Full text and
rfc822 format available.
Message #233 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ricardo,
On Fri, Mar 07 2025, Ricardo Wurmus wrote:
> Surely you are not suggesting that my desire to work on Guix [...]
> would be sufficient in reducing the backlog of bugs?
The remainder of my message made that clear but you were offended and
hit reply too fast.
My observation was about the group. I suggested as a hook for my
argument that your desire to contribute, which you have done more than
most, was not sufficient to reduce the backlog of bugs.
Isn't that how you and many other committers feel as well?
Kind regards
Felix
P.S. Questioning my good faith or my conduct was below the belt.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 17:07:03 GMT)
Full text and
rfc822 format available.
Message #236 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ricardo,
On Thu, 06 Mar 2025 at 21:05, Ricardo Wurmus <rekado <at> elephly.net> wrote:
> It seems that on Codeberg the primary means of keeping track of things
> is through notifications. I fear I might still end up dropping the
> ball when a PR requires my attention if it gets buried in countless
> notifications -- especially if I have to keep them unread to ever have
> a chance of finding them again. Obviously, a fix here would be to
> adjust my behaviour and not let notifications pile up, but this has no
> chance of ever happening. (In completely unrelated news: I've got
> 17532 unread Guix emails.)
Yes, I agree. IMHO, it would be a mistake to think that Codeberg would
ease how to deal with all the submissions. Even, because there is no
simple tools at hand – as Maxim said in [1] – the current interface
makes the process harder, from my point of view.
For example, Leo wrote [2]:
For me, the big problem with email is that resolved tickets don't get
removed from my inbox. Currently, my guix-patches inbox has 7000
messages. And 520 for bug-guix. Since April 2024.
and yeah that’s an issue! Well, maybe I’ve missed the obvious but my
Notifications are not removed when the PR is merged.
Somehow, the way Codeberg Notifications is currently implemented does
the same way as “my inbox”, IIUC, except that instead of being able to
manipulate these tickets with the comfort on a good email reader, now we
need API queries or live in the browser.
To say it explicitly, only at the scale of guix-science, I was spending
boring time only to manage with these Notifications already processed,
so the fix of my annoyance: fully turn off the Notifications – too old
to be bored again and again and not enough free time to scratch my itch.
Result: the exact same situation as with Debbugs.el – but a bit worse
because fj.el provides less capabilities compared to Debbugs.el and
Notmuch.
To me, moving from “patch by email” to PR is a good thing, potentially.
However, I am not aligned with the proposed “Migration Path”.
Somehow, we need something more gradual. For instance, 2 or 3 steps with
concrete and detailed milestones; targeting the end of “patch by email”
something as next December.
Why? Because we need to learn more where the friction could be, what is
really lacking, what makes too much hurdle, etc. And adapt accordingly.
All that to say, I am not convinced that completely jumping to something
fully new for most of us is a good approach; especially when the same us
already know the pitfalls of our tools or behaviour.
Cheers,
simon
1: Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Tue, 04 Mar 2025 20:22:59 +0900
id:8734ftdoq4.fsf <at> gmail.com
https://lists.gnu.org/archive/html/guix-devel/2025-03
https://yhetil.org/guix/8734ftdoq4.fsf <at> gmail.com
2: Re: [GCD] Migrating repositories, issues, and patches to Codeberg
Leo Famulari <leo <at> famulari.name>
Thu, 06 Feb 2025 14:39:26 -0500
id:Z6UP7nNeJlrnkA4U <at> jasmine.lan
https://lists.gnu.org/archive/html/guix-devel/2025-02
https://yhetil.org/guix/Z6UP7nNeJlrnkA4U <at> jasmine.lan
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 17:07:03 GMT)
Full text and
rfc822 format available.
Message #239 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Fri, 07 Mar 2025 at 05:22, 45mg <45mg.writes <at> gmail.com> wrote:
>>> For one example, consider
>>> <https://codeberg.org/guix-science/guix-science/pulls/63>.
>>>
>>> As you can see, there is no “Commit“ and no “Files changed“. Why?
>>> Because Alexis deleted the PR branch. Therefore, harder to know what
>>> the PR was about; annoyances.
>>
>> Thanks for raising this. This is a very important point. Losing history
>> like this seems very bad. Ideally, we want to have an archive of every
>> conversation and contribution that went into the project. Emails provide
>> this. If Codeberg does not, we should rethink our move.
>
> If you read through the Conversation section, you can see a message for
> every time commits were added to the branch or it was force-pushed. If
> you click on the commit hashes or subjects in these messages, it takes
> you to a description of the commit, featuring a diff and files changed.
> In this way you can see every iteration of the PR, just like we have
> every patch revision in our mailing-list archives.
Yes, as I detailed in [1]. :-)
However, you still need to “click” here or there. My issue could “live
in the browser” but the one I raise is: you need a stable Internet
connection. Anyway, another story. :-)
What I wanted to illustrate is about the storage. Arun wrote [2]:
I was present with Ludo and others when we visited the Codeberg stall at
FOSDEM, and enquired about the possibility of hosting Guix on Codeberg.
The person at the stall was hesitant about our large repo, and our many
users. In fact, in order to save on disk space, they suggested that we
encourage our contributors to delete their forks once done. :-D Needless
to say, that's never going to happen!
And I’m adding elements to this question.
Well, my opinion on this topics of storage is: Without concrete numbers
and explicit questions to Codeberg team, the discussion is speculation
on one way or on the other.
I agree with Ludo [3]:
That they’re transparent and upfront about their scalability
issues is a rather good sign to me.
Therefore, the ball is our camp. :-) How many submissions per month on
average? How many revisions per submission? How many message per
submission? Etc.
Instead of answering, I could do that… Hum?!
Cheers,
simon
1: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <zimon.toutoune <at> gmail.com>
Thu, 06 Mar 2025 15:15:43 +0100
id:87ldti6y9c.fsf <at> gmail.com
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/87ldti6y9c.fsf <at> gmail.com
https://yhetil.org/guix/87ldti6y9c.fsf <at> gmail.com
2: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Arun Isaac <arunisaac <at> systemreboot.net>
Tue, 25 Feb 2025 14:03:02 +0000
id:87zfia2kbt.fsf <at> systemreboot.net
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/87zfia2kbt.fsf <at> systemreboot.net
https://yhetil.org/guix/87zfia2kbt.fsf <at> systemreboot.net
3: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Ludovic Courtès <ludo <at> gnu.org>
Wed, 26 Feb 2025 22:01:47 +0100
id:8734g01kuc.fsf <at> inria.fr
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/8734g01kuc.fsf <at> inria.fr
https://yhetil.org/guix/8734g01kuc.fsf <at> inria.fr
PS:
> One thing I particularly like is that the final message (well, the one
> before 'deleted branch *typst*') shows you the commit that was finally
> merged. On the mailing lists, many of the issues are closed with a
> message like 'applied with minor tweaks, thanks', and not all committers
> will note the commit hash - so you're left grepping for the patch
> subject line in `git log` if you want to know what tweaks were made.
> Codeberg automatically notes the hash, and you can see the final
> iteration just by clicking on it!
The introduction of Change-Id fixes. Indeed, it’s not at one click. :-)
Yes, it could be introduced to Mumi and showed in the web-interface.
And then it opens some questions described elsewhere. ;-)
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 17:07:04 GMT)
Full text and
rfc822 format available.
Message #242 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ricardo,
On Fri, 07 Mar 2025 at 10:21, Ricardo Wurmus <rekado <at> elephly.net> wrote:
> Divya Ranjan <divya <at> subvertising.org> writes:
>
>> We have a *humongous* backlog of patches, [...]
>
>> [...] we host a backend service that regularly checks the Codeberg
>> repository for any new issues or PRs and then communicates to us
>> through the Codeberg’s Forgejo API [0] the content of said issues and
>> PRs. The data received from the API then gets directed to our Debbugs
>> or Mumi backend, which parses the information from it and opens a new
>> Debbugs issue for it. Thus, for every issue opened on Codeberg, we
>> have a mirrored Debbugs issue [...]
>
> So at the end we'd have an even larger backlog of patches, and spread
> across two systems...? And where do we source the time and motivation
> to hack on yet another piece of software?
I proposed a similar one-way bridge here [1]. And obviously, my
proposal is also to volunteer for helping in implementing in Mumi
backend.
Cheers,
simon
1: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <zimon.toutoune <at> gmail.com>
Thu, 06 Mar 2025 17:35:25 +0100
id:875xkm6rsi.fsf <at> gmail.com
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/875xkm6rsi.fsf <at> gmail.com
https://yhetil.org/guix/875xkm6rsi.fsf <at> gmail.com
PS: I agree with the rest of your message, and to complement:
> It does not even do simple things like delivering notifications to
> *everyone* who participates in an issue discussion. This is the
> reason for the sudden eery silence that can be seen in many issues.
I’m not sure Codeberg notifies you without the dedicated @rekado;
similarly as adding you with CC.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 17:12:01 GMT)
Full text and
rfc822 format available.
Message #245 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sun, Feb 23, 2025 at 10:21 AM Ludovic Courtès <ludo <at> gnu.org> wrote:
>
> Hello Guix!
>
> This is the formal submission of “Migrating repositories, issues, and
> patches to Codeberg” (GCD 002), a preliminary draft of which I posted
> before the Guix Days⁰.
I support this proposal! It's about time! The email-based workflow
worked well enough in the early days, but Guix outgrew it 5+ years
ago. Savannah is a dead platform and I have long since given up trying
to deal with debbugs for anything other than small patches. I look
forward to being able to easily browse issues and scan through pull
requests.
- Dave
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 17:41:02 GMT)
Full text and
rfc822 format available.
Message #248 received at 76503 <at> debbugs.gnu.org (full text, mbox):
"Thompson, David" <dthompson2 <at> worcester.edu> writes:
> The email-based workflow worked well enough in the early days, but
> Guix outgrew it 5+ years ago.
Do you also believe that the Linux kernel has outgrown the "email-based
workflow"? If not, what makes things different for Guix, in your
opinion?
Since a number of criticisms about the current approach have been about
the GNU fork of Debbugs. I wonder if replacing that with something else
(say, Bugzilla) while still retaining the email-based workflow wouldn't
address most of the pain points. Unless I'm mistaken, I believe the
Linux kernel takes a similar approach.
--
Suhail
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 17:48:01 GMT)
Full text and
rfc822 format available.
Message #251 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 7, 2025 at 12:40 PM Suhail Singh <suhailsingh247 <at> gmail.com> wrote:
>
> "Thompson, David" <dthompson2 <at> worcester.edu> writes:
>
> > The email-based workflow worked well enough in the early days, but
> > Guix outgrew it 5+ years ago.
>
> Do you also believe that the Linux kernel has outgrown the "email-based
> workflow"? If not, what makes things different for Guix, in your
> opinion?
I don't contribute to Linux so I have nothing to add here.
> Since a number of criticisms about the current approach have been about
> the GNU fork of Debbugs. I wonder if replacing that with something else
> (say, Bugzilla) while still retaining the email-based workflow wouldn't
> address most of the pain points. Unless I'm mistaken, I believe the
> Linux kernel takes a similar approach.
I wouldn't support a switch to Bugzilla or something similar. I want
Guix to use a real forge with pull requests, webhooks, etc.
- Dave
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 18:04:01 GMT)
Full text and
rfc822 format available.
Message #254 received at 76503 <at> debbugs.gnu.org (full text, mbox):
"Thompson, David" <dthompson2 <at> worcester.edu> writes:
>> Do you also believe that the Linux kernel has outgrown the "email-based
>> workflow"? If not, what makes things different for Guix, in your
>> opinion?
>
> I don't contribute to Linux so I have nothing to add here.
I don't believe that that's a necessary pre-requisite to be able to add
something of value, but fair enough.
>> Since a number of criticisms about the current approach have been about
>> the GNU fork of Debbugs. I wonder if replacing that with something else
>> (say, Bugzilla) while still retaining the email-based workflow wouldn't
>> address most of the pain points. Unless I'm mistaken, I believe the
>> Linux kernel takes a similar approach.
>
> I wouldn't support a switch to Bugzilla or something similar.
Okay.
> I want Guix to use a real forge with pull requests, webhooks, etc.
Well, yes, that much is clear.
--
Suhail
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 18:08:01 GMT)
Full text and
rfc822 format available.
Message #257 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Simon,
> On Thu, 06 Mar 2025 at 21:05, Ricardo Wurmus
> <rekado <at> elephly.net> wrote:
>
>> It seems that on Codeberg the primary means of keeping track of
>> things
>> is through notifications. I fear I might still end up dropping
>> the
>> ball when a PR requires my attention if it gets buried in
>> countless
>> notifications -- especially if I have to keep them unread to
>> ever have
>> a chance of finding them again. Obviously, a fix here would be
>> to
>> adjust my behaviour and not let notifications pile up, but this
>> has no
>> chance of ever happening. (In completely unrelated news: I've
>> got
>> 17532 unread Guix emails.)
>
> Yes, I agree. IMHO, it would be a mistake to think that
> Codeberg would
> ease how to deal with all the submissions. Even, because there
> is no
> simple tools at hand – as Maxim said in [1] – the current
> interface
> makes the process harder, from my point of view.
>
> For example, Leo wrote [2]:
>
> For me, the big problem with email is that resolved
> tickets don't get
> removed from my inbox. Currently, my guix-patches inbox
> has 7000
> messages. And 520 for bug-guix. Since April 2024.
>
> and yeah that’s an issue! Well, maybe I’ve missed the obvious
> but my
> Notifications are not removed when the PR is merged.
>
> Somehow, the way Codeberg Notifications is currently implemented
> does
> the same way as “my inbox”, IIUC, except that instead of being
> able to
> manipulate these tickets with the comfort on a good email
> reader, now we
> need API queries or live in the browser.
It seems that Forgejo Notifications are not the correct interface
to improve our overview, because as you say they would suffer from
the same problem as emails with the added disadvantages of
cluttering the email inbox (with notification emails) and the lack
of a local client to make sense of them (which is what email
allows us to do).
I found that the URL
https://codeberg.org/org/guix-science/pulls?\
type=review_requested&\
sort=recentupdate&\
state=open&\
q=&fuzzy=true
Shows me current pull requests that still await my review.
Likewise I can list those I've reviewed already with
"type=reviewed_by" and those assigned to me with "type=assigned".
Curiously, these filters don't seem to be exposed in the API
endpoint /repos/{owner}/{repo}/pulls.
Reviews can automatically be requested via the CODEOWNERS file, so
I think moulding our workflow around this overview would be an
obvious improvement.
> Somehow, we need something more gradual. For instance, 2 or 3
> steps with
> concrete and detailed milestones; targeting the end of “patch by
> email”
> something as next December.
>
> Why? Because we need to learn more where the friction could be,
> what is
> really lacking, what makes too much hurdle, etc. And adapt
> accordingly.
This sounds reasonable, but perhaps the migration is not quite a
big as we think. There are not that many committers, who would be
on the receiving side of pull request review. What do the current
committers absolutely require of the forge to be able to complete
at least as many reviews as they do today? Perhaps we can
concretely list the committers' requirements, and see what
solutions or workarounds we can find for each of them.
This is setting aside more fundamental misgivings such as "I don't
like that Codeberg requires an account" or "I don't feel I can
trust Codeberg e.V. with our data", which ought to be negotiated
in this discussion. (I don't like that Codeberg requires an
account, even for the AGit workflow, but I think there could be
workarounds, and I don't consider this more than a minor
inconvenience.)
> All that to say, I am not convinced that completely jumping to
> something
> fully new for most of us is a good approach; especially when the
> same us
> already know the pitfalls of our tools or behaviour.
A complication of a partial move (perhaps just the r-team and the
python-team) is that it starts an extended period of confusion for
contributors. We would have to document the preferences of each
team. I don't know if the GCD process is laid out for per-team
decisions like this.
If the experiment is deemed a failure by those who have moved to
Codeberg they'll just move back. But what if the experiment is
only deemed a failure by those who haven't actually given Codeberg
a try? We'd end up with permanent fragmentation.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 18:13:02 GMT)
Full text and
rfc822 format available.
Message #260 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello Ricardo,
>> We have a *humongous* backlog of patches, [...]
>
>> [...] we host a backend service that regularly checks the Codeberg
>> repository for any new issues or PRs and then communicates to us
>> through the Codeberg’s Forgejo API [0] the content of said issues
>> and
>> PRs. The data received from the API then gets directed to our
>> Debbugs
>> or Mumi backend, which parses the information from it and opens a
>> new
>> Debbugs issue for it. Thus, for every issue opened on Codeberg, we
>> have a mirrored Debbugs issue [...]
>
> So at the end we'd have an even larger backlog of patches, and spread
> across two systems...? [...]
We would have that regardless of whether one follows my proposition or not. The old backlog is going nowhere. Even if we make a full-switch to Codeberg immediately, the committers would either have to work on both things tenaciously as they (committers such as Maxime) get used to an entirely new workflow. What is the probability that such an immediate increase in responsibilities will not lead to a further increase of existing backlog?
I don’t think anything can solve the backlog quickly, what I proposed was with the intent of solving the issue of committers not having to learn a new workflow altogether to work on the backlog, ergo, not having another hurdle to it amidst a list of others.
> And where do we source the time and motivation
> to hack on yet another piece of software? Outside contributions to
> mumi have been *very* few in all these years; that's not for a lack of
> problems we've had with the system, and for once it's not for a lack
> of
> review either.
Indeed, that is a problem. It was a mere proposition, so if enough people want it to happen, we can have it :)
> As a long time contributor with commit access I have the impression
> that
> people new to Guix hold the assumption that the current system and
> workflow works for long time contributors. I may just be wildly
> incompetent, but for me it most assuredly does not work in enabling
> reviews. I mostly review patches that were sent to me directly or
> that
> happen to solve a problem I'm trying to solve as part of my
> maintainance
> work.
I acknowledge your experience, but we heard from others such as Maxime how to them it might require learning and changing the workflow. So the people for whom the email-based workflow works isn’t really a null set.
> The haphazard GNU fork of Debbugs also lacks a number of features, has
> odd unaddressed bugs, lacks people who even understand in what ways it
> differs from the Debian version, lacks people working on improving it
> and addressing these issues. (There is literally *one* person who
> keeps
> the lights on.)
>
> It does not even do simple things like delivering notifications to
> *everyone* who participates in an issue discussion. This is the
> reason
> for the sudden eery silence that can be seen in many issues.
>
> I honestly have my doubts that the move to Codeberg would
> automatically
> solve all of my workflow issues, but let's please not eulogize the
> email-based workflow too much. It makes sense to me to base our
> efforts
> on a system that is *actively* developed by a *team* of aligned free
> software hackers.
>
> I don't see an active future for the GNU fork of Debbugs, and I think
> it
> is not a good use of our time to work on a system that won't improve
> unless we burden ourselves with even more work (like taking over
> hosting
> and administration). I'd rather work on Guix.
By all means, but I think you are confusing a plea for not breaking certain people’s workflow as a means to "eulogize" something. The goal here is to simply not put enough pressure on people who already have a lot on themselves to change their workflow in order to continue contributing to Guix. And my proposal is targetted towards an eventual move to Codeberg, just a more gradual approach, based on empirical feedback and with some time to clear the existing backlog and to learn the new system.
Regards,
--
Divya Ranjan,
Philosophy, Mathematics, Libre Software.
PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 18:19:02 GMT)
Full text and
rfc822 format available.
Message #263 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello Simon,
> Hi Ricardo,
>
> On Fri, 07 Mar 2025 at 10:21, Ricardo Wurmus <rekado <at> elephly.net> wrote:
>> Divya Ranjan <divya <at> subvertising.org> writes:
>>
>>> We have a *humongous* backlog of patches, [...]
>>
>>> [...] we host a backend service that regularly checks the Codeberg
>>> repository for any new issues or PRs and then communicates to us
>>> through the Codeberg’s Forgejo API [0] the content of said issues and
>>> PRs. The data received from the API then gets directed to our Debbugs
>>> or Mumi backend, which parses the information from it and opens a new
>>> Debbugs issue for it. Thus, for every issue opened on Codeberg, we
>>> have a mirrored Debbugs issue [...]
>>
>> So at the end we'd have an even larger backlog of patches, and spread
>> across two systems...? And where do we source the time and motivation
>> to hack on yet another piece of software?
>
> I proposed a similar one-way bridge here [1]. And obviously, my
> proposal is also to volunteer for helping in implementing in Mumi
> backend.
Apologies Simon, I had totally missed your mail and proposition. I came up with this earlier today. But I agree entirely with the proposal, and volunteer to work on such tooling as well.
Regards,
--
Divya Ranjan,
Philosophy, Mathematics, Libre Software.
PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 18:34:01 GMT)
Full text and
rfc822 format available.
Message #266 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello Suhail,
> "Thompson, David" <dthompson2 <at> worcester.edu> writes:
>
>> The email-based workflow worked well enough in the early days, but
>> Guix outgrew it 5+ years ago.
>
> Do you also believe that the Linux kernel has outgrown the "email-based
> workflow"? If not, what makes things different for Guix, in your
> opinion?
>
Despite me being in support of a workflow that doesn’t require opening a browser, while thinking about how Linux kernel does it and Guix, I had to realize that Linux gets a *lot* more in funding and infrastructure than Guix. Of course part of it is because of sheer technological necessity of handling a 30M LOC project that’s used by everyone. But it’s also because they *can* get it, through the help of Linux Foundation and so on.
I don’t think we have that many degrees of freedom here, so we need to be careful about our resources, and the work of volunteers and committers. I would be open to a consideration of using BugZilla or Gerrit for that matter, even though I’m not used to them, the possibility of working with them without a browser, motivates me to learn them.
Regards,
--
Divya Ranjan,
Philosophy, Mathematics, Libre Software.
PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 18:51:03 GMT)
Full text and
rfc822 format available.
Message #269 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Divya Ranjan <divya <at> subvertising.org> writes:
> I had to realize that Linux gets a *lot* more in funding and
> infrastructure than Guix.
While I agree in general, I don't understand the specific point you were
making. Was it that Linux with its greater funding has someone to
manage something like Bugzilla, where Guix may not?
> I don’t think we have that many degrees of freedom here, so we need to
> be careful about our resources, and the work of volunteers and
> committers.
Agreed.
--
Suhail
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 19:04:01 GMT)
Full text and
rfc822 format available.
Message #272 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Suhail Singh <suhailsingh247 <at> gmail.com> writes:
> Divya Ranjan <divya <at> subvertising.org> writes:
>
>> I had to realize that Linux gets a *lot* more in funding and
>> infrastructure than Guix.
>
> While I agree in general, I don't understand the specific point you were
> making. Was it that Linux with its greater funding has someone to
> manage something like Bugzilla, where Guix may not?
That, and they have the freedom to not worry if it’s costing them a bit too much, both financially and workload wise. I don’t think any of the kernel subsystem maintainers are heavily working on the infrastructure, it is simply provided to them from Linux Foundation. I think if a lot of our infrastructural worries could be handled by some other entity while the committers focus on contributing to Guix, it’d been much easier.
As much as we like to talk of Savannah being unstable, it is managed by less than 5 people at FSFSysOps. Last month I recommended to communicate or work with them[0], but I don’t think anyone wanted that. The degree to which a workflow is smooth depends not only on the workflow itself but on how it’s being supported.
[0]: https://yhetil.org/guix/177B8808-9D2B-43ED-BC6D-02F1DAC36795 <at> subvertising.org/
--
Divya Ranjan,
Philosophy, Mathematics, Libre Software.
PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 07 Mar 2025 20:35:01 GMT)
Full text and
rfc822 format available.
Message #275 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 07, 2025 at 01:49:46PM -0500, Suhail Singh wrote:
> While I agree in general, I don't understand the specific point you were
> making. Was it that Linux with its greater funding has someone to
> manage something like Bugzilla, where Guix may not?
Linux contributors and maintainers are paid to be persistent in
reviewing and landing patches, regardless of the tools and workflow.
There are thousands of them, mostly professionals.
As Guix's number 8 commit author and committer (two different stats,
both #8), I can say that I'd be doing Much More these days if it was my
job and not a personal hobby.
git shortlog -ns
git shortlog -ncs
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sat, 08 Mar 2025 17:55:02 GMT)
Full text and
rfc822 format available.
Message #278 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
Thanks for this, it is remarkable and obvious the amount of time you
have spend thinking about it in deep before submitting the GCD.
However, after a last read to the proposal, a question arises in my
mind. I haven’t found any reference to it in this long thread (maybe
I missed it ?).
> # Cost of Reverting
This point might become relevant at some point ahead on time. Do we
have any reference of a successful migration to another gitlab /
forgejo instance ? I’m thinking here about the long term retrieval of
all information we will deposit at codeberg during the incoming years.
No one knows what the future will provide, but I think, from my
perspective, that a complete demo exercise might be helpful to this
respect before going any further.
Thanks again,
--
Cayetano Santos
.
gpg: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682
key: meta.sr.ht/~csantosb.pgp
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 09 Mar 2025 08:46:02 GMT)
Full text and
rfc822 format available.
Message #281 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi everyone,
A few high-level comments, to prevent us from getting lost in technical
details.
Quoting the summary of the GCD:
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.
Onboarding: this means new community members, and it suggests, though
not explicitly saying it, growth. Is growth what we want? Or merely
replacement of people leaving or reducing their efforts? If we want
growth, how quickly and up to where? Do we want to operate like the
Linux kernel (recently cited here), in that most contributors are
employees of tech companies? If not, what is the profile of contributors
that we wish to attract? Which others are we willing to give up on in
exchange? (I am thinking of those who are not willing to create a
Codeberg account, for example.)
Is onboarding only about recruiting new community members, or also about
mentoring newcomers on their path from users to contributors to
reviewers and maintainers? I suppose it is. Then which step is the
bottleneck? My impression from this discussion: from contributor to
reviewer. Which is why I personally favor this proposal, because I see
the current workflow as most cumbersome for code reviewing.
Lack of legibility, complex, unreliable, and labor-intensive
infrastructure: these are more technical motivations. It's the current
maintainers that are most exposed to these issues. Not me, so I won't
comment, other than highlighting that we should listen to the current
and past maintainers.
Lack of automation: I haven't seen much discussion about this aspect so
far. Automating what, for who? Who needs to be able to control and
fine-tune automation? Who needs to understand what's happening?
At what stages in onboarding does this matter?
Cheers,
Konrad.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 09 Mar 2025 08:50:01 GMT)
Full text and
rfc822 format available.
Message #284 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Divya Ranjan via Guix-patches via <guix-patches <at> gnu.org> writes:
> I would be open to a consideration of using BugZilla or Gerrit for
> that matter, even though I’m not used to them, the possibility of
> working with them without a browser, motivates me to learn them.
Ignore me if I'm not adding anything to the discussion here, but I'd
like to remind everyone that there is also the possibility of working
with Codeberg without a browser:
https://codeberg.org/forgejo-contrib/delightful-forgejo#clients
https://github.com/magit/forge
I haven't tried these, and no doubt there will be shortcomings. But both
Forgejo and its clients are all open-source, so it's possible to work on
and improve them.
Speaking for myself at least, I know that if I could find the time, I'd
enjoy improving any of the existing CLI or Emacs interfaces to a modern
forge with a seemingly-bright future (federation!), knowing that my work
would benefit the countless open-source projects that use it, and the
modern FOSS movement by extension.
I can't really say the same for improving my personal email-based
workflow, whose setup is too complex for me to expect anyone else to
ever use it. Or for setting up and/or working on Bugzilla, or Gerrit, or
Debbugs... these are all great projects, I'm sure, but they're not
likely to have a lot of new adopters, which means that the impact of
improving them is going to be much smaller.
I realize that everyone's motivation comes from a different place, but I
think it's worth looking at the benefit this proposal could bring to the
FOSS community at large. We have a lot of active and competent power
users, and an active and competent userbase is the biggest asset for any
project. If we use program 'X' as a core part of our workflow, then
program 'X' gains all those users. Obviously improving Forgejo is far
from the first priority for us, but it is a nice bonus, and makes me
feel a lot more positive about this proposal.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 10 Mar 2025 12:06:01 GMT)
Full text and
rfc822 format available.
Message #287 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello all,
Reading a random fediverse thread, I came across some aspects about
growth of issues and governance around duplications and feature
requests:
https://social.wildeboer.net/@jwildeboer/114131748974841455
```
What I gather from the replies is that better issue tracking should work
with at least 3 separate queues:
- Bugs (things that don't work as they should, breaking functionality,
can be fixed relatively fast)
- Feature requests (Things that don't exist yet in the codebase but
could be added)
- Refactoring (Things that can be bugs or features, but to solve them a
redesign/rewrite/refactor of certain parts of the codebase is needed)
Triage should decide where a new issue belongs.
```
https://social.wildeboer.net/@jwildeboer/114132897616035930
```
often issue trackers are used for feature requests. I think it is
reasonable for those to stay open for long-ish periods of time as part
of a long term roadmap or a help-wanted list. I agree those should be
clearly distinguished from bugs, but sometimes the line between "missing
feature" and "bug" blurs.
```
https://kolektiva.social/@cscott/114132771181298941
Is there a need to provide more formal clarifications regarding
collective expectations and emphases?
Are there any case studies we are using to inform such outcomes?
In particular, is there anything distinct to the Guix experience that we
need to be mindful of?
Kind regards,
Jonathan
On 2025-03-07 06:18, Divya Ranjan wrote:
> Hello Carlo,
>
>> I don't think this is a fair summary of the goal. The first sentence
>> of
>> the GCD[1] is:
>>
>> The contribution workflow in Guix has been facing several
>> challenges:
>> difficult onboarding, lack of legibility, complex, unreliable, and
>> labor-intensive infrastructure, and lack of automation.
>>
>> Of these, only "difficult onboarding" is about newcomers. Your
>> proposal
>> (which I might describe as "proxy Codeberg into debbugs") involves
>> building new infrastructure without helping the other issues.
>
> You are correct, Carlo, the GCD does have multiple goals. But in my
> email I also elaborated how the onboarding issue is a high-priority
> task, reflective from the last survey and also something that can be
> achieved without risking too much. I believe we are at a probabilistic
> trade-off decision here, do we wish to achieve all the goals, including
> a complete change of infrastructure, workflow etc. in the proposed
> timeline of 15 days or so, and thus incurring a lot of problems that a
> team of committers would’ve to put a lot of effort into resolving? Or,
> do we wish to slowly achieve some of the goals, take those goals as a
> litmus test for the overall proposal and proceed gradually? I believe
> latter would be a safer bet, with less to risk immediately and
> opportunity to fix mistakes from feedback.
>
> So, yes, my proposal cannot resolve all the goals, but I am trying to
> find a way to integrate what we have with what we might switch to. I
> might be at fault here, and feel free to elaborate on that, such as how
> can we approach the proposed quick migration to Codeberg while having a
> huge backlog of patches?
>
>>> Since Codeberg already allows to communicate in issues over email,
>>> i.e. you can respond to someone in a particular issue over email,
>>> this
>>> shouldn’t be too difficult to arrange.
>>
>> This is not true today. While Forgejo supports replying via email,
>> Codeberg does not have that enabled due to bugs. They have an issue
>> tracking it: https://codeberg.org/Codeberg/Community/issues/1562
>
> Thank you for this. I had tried it on a Forgejo repository, not a
> Codeberg one, so I believed the same could be possible here as well.
> From the discussions I see, if we spend enough time with them--which we
> need to do either ways--for the migration, they might get it working?
> Does not look far from possible to me.
>
>> Even if it was true, the big disconnect here would be around
>> commenting
>> on specific lines of code. An email with a comment on a patch would
>> come
>> through as a top-level comment on the PR, which is not natural in that
>> context.
>
> Also thank you for bringing this issue, indeed this is a crucial
> functionality. But to be clear, this is specifically for a
> pull-request. The issues functionality is totally doable out of the box
> with Forgejo, we just need to make it work with Codeberg and polish it.
> With regards to the PR, one has to remember that the entire process
> needs to be wrapped around Forgejo’s API, not as our used to method of
> plain text. We’d be parsing JSON to-and-fro. For "reviewing a Pull
> Request" in Codeberg methodology, Forgejo provides a
> =/repos/{owner}/{repo}/pulls/{index}/reviews= API[0] to initiate a
> review. This API will take the comments from the patch in the Email,
> place them in the "body" string of the JSON, and the respective
> positions from the diff, the commit_id and so on. I agree it is
> non-trivial, but so is switching a workflow that has been in-place for
> years, also a non-trivial task. I think the API has enough things for
> what we need. And again, we don’t need all of them, we only require
> implementing those for now that bridge existing email workflow and the
> newcomers’ onboarding. Merging, for example, I propose to be done in
> the usual way of taking a patch and applying it. Eventually once we
> have less of a backlog, and more ease of migration, one might consider
> moving these core tasks to the Codeberg as well.
>
> Either ways, we are at the crossroads and we need to decide which
> trade-off is worth the pain. I believe it is *not* certain that once we
> entirely migrate to Codeberg, the goals of "complexity" and "lack of
> legibility" would be immediately reaped. It creates a possibility of
> enjoying them, but given the assumption that the switch from existing
> architecture is smooth. And, once again, if we were a relatively
> smaller project such as the Guix-Science, this could’ve been a decision
> much simpler and with less at stake, but that is not the case. But I
> think it *is* certain that if we take an approach that doesn’t directly
> replace one workflow with another, but bridges the new one with the
> previous one, the committers will have a better way to switch. Simply
> because they can try to finish the backlog using the existing workflow,
> and the new patches can come to them with that as well. Where we go
> from there, can be decided upon how good the litmus test goes.
>
> [0]: https://codeberg.org/api/swagger#/repository/repoCreatePullReview
>
> Regards,
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 10 Mar 2025 12:32:01 GMT)
Full text and
rfc822 format available.
Message #290 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Andreas,
On Fri, 07 Mar 2025 at 17:03, Andreas Enge <andreas <at> enge.fr> wrote:
> Which says nothing about the experience on a forge, logically.
If I might, I encourage you to subscribe to all the guix-science
channels. This way, you will have an foretaste: The Good, the Bad and
the Ugly. :-)
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 10 Mar 2025 12:32:02 GMT)
Full text and
rfc822 format available.
Message #293 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Sun, 09 Mar 2025 at 08:48, 45mg <45mg.writes <at> gmail.com> wrote:
> https://codeberg.org/forgejo-contrib/delightful-forgejo#clients
> https://github.com/magit/forge
>
> I haven't tried these, and no doubt there will be shortcomings.
Maybe you should. :-)
For instance, magit-forge does not work with Codeberg although their
documentation says so. Well, neither Ludo or I have succeeded in
configuring it, although we asked advice on Mastodon [1,2].
For the rest, I would not repeat [3,4]. :-)
Cheers,
simon
PS: Without any willing to be harsh, if I might, in order to keep the
discussion fruitful, I would refrain to raise speculations and
instead strive on arguments backed by experience. Somehow, let
avoid to oppose pure personal feelings and instead share various
angles or perspectives with the hope to get a common understanding.
--
1: https://toot.aquilenet.fr/@civodul/113560896535810894
2: https://social.sciences.re/@zimoun/113561826489905430
3: Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Tue, 04 Mar 2025 20:22:59 +0900
id:8734ftdoq4.fsf <at> gmail.com
https://lists.gnu.org/archive/html/guix-devel/2025-03
https://yhetil.org/guix/8734ftdoq4.fsf <at> gmail.com
4: Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <zimon.toutoune <at> gmail.com>
Thu, 06 Mar 2025 18:39:56 +0100
id:87r03a5a8j.fsf <at> gmail.com
https://lists.gnu.org/archive/html/guix-devel/2025-03
https://yhetil.org/guix/87r03a5a8j.fsf <at> gmail.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 10 Mar 2025 12:34:01 GMT)
Full text and
rfc822 format available.
Message #296 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ricardo,
On Fri, 07 Mar 2025 at 19:07, Ricardo Wurmus <rekado <at> elephly.net> wrote:
> https://codeberg.org/org/guix-science/pulls?\
> type=review_requested&\
> sort=recentupdate&\
> state=open&\
> q=&fuzzy=true
For instance, this is listed for me:
https://codeberg.org/guix-science/guix-science-nonfree/pulls/30
and…
> Reviews can automatically be requested via the CODEOWNERS file, so
> I think moulding our workflow around this overview would be an
> obvious improvement.
…and maybe I misread CODEOWNERS [1], but I miss why this PR is listed
for me.
1: https://codeberg.org/guix-science/guix-science-nonfree/src/branch/master/CODEOWNERS
>> Somehow, we need something more gradual. For instance, 2 or 3 steps
>> with concrete and detailed milestones; targeting the end of “patch by
>> email” something as next December.
>>
>> Why? Because we need to learn more where the friction could be, what
>> is really lacking, what makes too much hurdle, etc. And adapt
>> accordingly.
>
> This sounds reasonable, but perhaps the migration is not quite a
> big as we think.
Yeah good ol’ resistance to change. ;-)
However, the GCD reads
Within **30 days** following acceptance of this GCD, committers would
migrate all these repositories to https://codeberg.org/guix.
and we are just starting to discover what could be done with the API or
how to effectively improve the identified bottleneck with emails, but in
the same time, it also introduces annoyances.
For example, one thing is the backup of all what is going to happen in
Codeberg: all the history of PRs, revisions, discussions, etc.
We jump in without a concrete implementation for such backup. Bad
scenario, imagine: couple of months later – we will have several open
and closed PRs – Codeberg suddenly disappears for whatever unexpected
reasons: How do we get all the data associated to our open and closed
PRs?
> What do the current
> committers absolutely require of the forge to be able to complete
> at least as many reviews as they do today?
For me,
a) work offline and by batch;
b) comment on patches without the web-interface; comment from Emacs;
c) being able to personally tag for later retrieving back;
d) bridge with Org-mode.
If I am transparent, the biggest annoyance for me when reviewing isn’t
about the workflow but it’s about the CI and/or QA. In other words,
this “Big Move” will introduce much more frictions on my side than
effectively smooth.
My main issues with CI and/or QA is that it’s much too slow to work on.
Not slow to process the queue – it might be but hey! – no, it’s about
too slow to query; especially via the web-interface. Well, I do not
know what has changed over the past year, but now for me ci.guix is
almost unusable.
And the “Big Move” will change nothing about the data generated by CI
and/or QA. It could only ease the bridge, IIUC.
> (I don't like that Codeberg requires an
> account, even for the AGit workflow, but I think there could be
> workarounds, and I don't consider this more than a minor
> inconvenience.)
Somehow, I agree. The 4 items above are “minor inconvenience” because
it’s possible to find and/or implement workarounds. However, it does
not appear to me doable considering the time frame that the GCD proposes
with the “Migration Path”.
To say it explicitly, these 4 items are “no go” for me. Not that I
would block the GCD but for sure I will stay aside – and for being
consistent, I’ll ask to suspend my write access – the time to have
something that fulfills these requirements.
No big deal, I barely review these days after all. :-)
>> All that to say, I am not convinced that completely jumping to
>> something fully new for most of us is a good approach; especially
>> when the same us already know the pitfalls of our tools or behaviour.
>
> A complication of a partial move (perhaps just the r-team and the
> python-team) is that it starts an extended period of confusion for
> contributors. We would have to document the preferences of each
> team. I don't know if the GCD process is laid out for per-team
> decisions like this.
Well, maybe the level of team isn’t the good one for such partial move.
For sure, I find awkward to jump in the unknown without any prior
minimal experience with PR workflow for almost all the people who have
experience with email workflow and are reviewing.
Just to mention. What Ludo did months ago, Ludo tried Codeberg, then
Ludo moved the channels guix-science, then Romain adapted Cuirass – or
maybe Romain adapted Cuirass before the guix-science channels move,
anyway–, then ~100 PRs has been submitted. Etc. All that creates this
minimal experience.
Now, when Ludo says: it’s okish enough and it’ll be fine with me, yes I
trust their words. Because they are somehow backed.
How many of us have a same minimal experience with PR?
Somehow, it’s a biased decision: Here is the way you know well and thus
the way you concretely know the frictions and annoyances. Compared to
that, there is the way you imagine and thus the way you hypothetically
speculate how smooth it will be or how worse it’ll become.
Concretely, it does not sound to me reasonable to say: Hey after the
23rd of May, all will happen on Codeberg, post-scriptum: good luck! :-)
I find more reasonable to have 2-3 milestones. And we also must discuss
with Codeberg on concrete numbers because that’s not an unilateral
decision, IMHO.
All that to say, yes I totally agree, the best approach seems:
What do the current
committers absolutely require of the forge to be able to complete
at least as many reviews as they do today?
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 10 Mar 2025 13:01:02 GMT)
Full text and
rfc822 format available.
Message #299 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Simon Tournier <zimon.toutoune <at> gmail.com> writes:
> On Fri, 07 Mar 2025 at 19:07, Ricardo Wurmus
> <rekado <at> elephly.net> wrote:
>
>> https://codeberg.org/org/guix-science/pulls?\
>> type=review_requested&\
>> sort=recentupdate&\
>> state=open&\
>> q=&fuzzy=true
>
> For instance, this is listed for me:
>
> https://codeberg.org/guix-science/guix-science-nonfree/pulls/30
>
> and…
>
>> Reviews can automatically be requested via the CODEOWNERS file,
>> so
>> I think moulding our workflow around this overview would be an
>> obvious improvement.
>
> …and maybe I misread CODEOWNERS [1], but I miss why this PR is
> listed
> for me.
>
> 1:
> https://codeberg.org/guix-science/guix-science-nonfree/src/branch/master/CODEOWNERS
I don't see that your review has been requested for this PR. No
idea
what's up there.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 10 Mar 2025 22:18:01 GMT)
Full text and
rfc822 format available.
Message #302 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
Cayetano Santos <csantosb <at> inventati.org> skribis:
> This point might become relevant at some point ahead on time. Do we
> have any reference of a successful migration to another gitlab /
> forgejo instance ? I’m thinking here about the long term retrieval of
> all information we will deposit at codeberg during the incoming years.
> No one knows what the future will provide, but I think, from my
> perspective, that a complete demo exercise might be helpful to this
> respect before going any further.
We have experience migrating from GitHub (Guix-Science, etc.) and from a
GitLab instance (Guix-Past, etc.) to Codeberg: this is almost lossless
conversion.
Migrating between Forgejo instances would be trivial: Forgejo supports
it as well.
We don’t know what the future will look like, but given the rich
interface and structured data, I’m confident that it will always be
possible to extract it and feed it into other similar systems.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 10 Mar 2025 22:45:03 GMT)
Full text and
rfc822 format available.
Message #305 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello Konrad,
Konrad Hinsen <konrad.hinsen <at> fastmail.net> skribis:
> Lack of automation: I haven't seen much discussion about this aspect so
> far. Automating what, for who? Who needs to be able to control and
> fine-tune automation? Who needs to understand what's happening?
> At what stages in onboarding does this matter?
This phrase refers to the bots and CI systems many developers have
become used to.
Here’s an example:
https://gitlab.inria.fr/guix-hpc/guix-hpc/-/merge_requests/159
The build status of the packaging changes are reported in the
discussion; the GitLab pipeline goes green upon success. (Romain is
working on that sort of feedback for Forgejo instances in Cuirass though
the basics are already in place as noted in the GCD.)
A “modern forge” isn’t necessary for this, as https://qa.guix.gnu.org
has shown. But just like it’s easier to write and maintain a browser
written in Rust than one written in assembly, it’s easier to integrate
qa.guix, Cuirass, and similar tools with a forge than with email.
This workflow also eases onboarding: without knowing anything about the
project’s infra, the contributor gets feedback about their submission
right where they posted it. And it works: no worries about MUAs
wrapping lines, patches as MIME attachments vs. email body, etc.
With that in place, it becomes possible to have an auto-update bot like
that of Nixpkgs:
https://nix-community.github.io/nixpkgs-update/r-ryantm/#r-ryantm
… which creates pull requests for package updates:
https://github.com/NixOS/nixpkgs/pulls/r-ryantm
… which are then built, with package maintainers being pinged upon
success.
Again this could be done over email or UUCP, but having the interface
and semantics of a forge makes those things easier.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 11 Mar 2025 03:32:02 GMT)
Full text and
rfc822 format available.
Message #308 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2025-03-04, Maxim Cournoyer wrote:
> Ludovic Courtès <ludo <at> gnu.org> writes:
>> Within **30 days** following acceptance of this GCD, committers would
>> migrate all these repositories to https://codeberg.org/guix.
>>
>> For Guix itself, we would decide on a **flag day** 14 days after
>> acceptance of this GCD at the earliest, and 30 days at the latest. On
>> that day, the official URL of the Guix repository would become
>> https://codeberg.org/guix/guix.git. A commit would reflect that by
>> updating:
>
> I'd like to suggest extending the 'trial' period to something much
> longer, like a year or so, to make sure our parachute is properly
> installed before jumping the cliff :-). Letting both systems co-exist
> and compete for merit seems a good trial, and we could also extract
> useful data (such as how many contributions were merged on one or the
> other, etc.). It'd be a bit annoying to keep an eye at two places for
> some time, but at least we wouldn't commit to something that may not
> scale/match our peculiar requirements as well as we expected.
Well, I am on year... 7 ... Seven! ... I had to count it out on my
fingers ... of having been using both bugs.debian.org (Debbugs) and
salsa.debian.org (Gitlab) concurrently. I have been merging
merge-requests via the web interface, using regular old plain "git fetch
&& git merge && git push" (my favorite by far!), and applying patches
via email...
Admittedly Debian's Debbugs is not GNU's Debbugs, and Debian's Gitlab is
not Codeberg's Forgejo, and Guix is not Debian, but... I suspect there
is enough similarity for my experiences to be somewhat relevent to this
conversation...
My personal conclusion is that these very different models can coexist
for... extended periods of time!
Is it a bit fractured? Some people prefer one system over the other, so
yeah, I guess...
Is there duplication of issues? Yup. Sometimes one needs to get
forwarded to the other manually. Whee.
Do issues get automatically closed on both systems? Usually, if you
remember to include the right incantations in your commit messages!
Occasionally even if you forget, what magic is that?!
Sometimes having an entirely different model is beneficial; just a
couple days ago someone reported a bug in diffoscope on IRC, but was
having difficulty getting an account set up on salsa.debian.org, but was
able to send an email to bugs.debian.org ... so we did not loose track
of the issue. Having both options has been more beneficial than harmful,
at least in my eyes.
Over these seven years I have encountered people who absolutely refuse
to deal with email who had interesting contributions and happily
submitted stuff via salsa.debian.org. Some people do not have time or
interest in getting another account on yet another platform configured
and are happy to send a patch via email.
I have been accomodating both sorts of people, and all sorts of folks in
between (such as myself!), and it is fairly easy because the common
denominator is git!
So yes, maintaining multiple systems has some serious drawbacks, and I
have not actually had to maintain any of the Debian infrastructure
really, but transitions are always hard, and some resistance to change
is an absolutely reasonable strategy, especially amoung volunteers with
limited time.
Nearly every time I need to explore some new technology, I grump and
squint and maybe even work up a good scowl. I have skipped multiple
generations of the shinest new things, only to spend my time on the one
that actually stuck around a while. So I understand that reluctance. I
have also found new ways of thinking about problems when I explore some
new approaches, so I understand that enthusiasm.
I do feel, given what I have heard from several people in this
discussion, that proposing a flag day with a short time of overlap is
going to be very hard for this community, and possibly more divisive
than whatever fracturing we might encounter by maintaining two
concurrent technical systems over an extended time period...
Yet that is at odds with what sounds like people burning out on
maintaining parts of the old system as well... mainly from what I have
heard, mumi, as the glue making debbugs at all usable? Or is it more
than that?
Whew! Thanks for making it this far! If you still are craving more,
there are a few postscripts below that did not quite fit in anywhere,
but I just could not resist...
live well,
vagrant
P.S. I also had used alioth.debian.org ~2004-2018(?), which just so
happens to be based off of the same code base that savannah.gnu.org was
(which was based off of a version of sourceforge.net I had used
~2000-2002)... also concurrently with using Debbugs. So forgive me if I
sway under a mild bit of deja-vu.
P.P.S. I do think a huge difference between Debian's Debbugs and the way
Guix uses GNU's Debbugs is that Guix has precisely two buckets (that I
am aware of) ... "guix" for bug reports and "guix-patches" for
patches. In contrast, Debian has approximately one bucket for each
upstream source. The difference of granularity can be somewhat met with
various forms of tagging, searching, etc. but it is also more cumbersome
and requires some additional development (e.g. mumi) to abstract that
stuff out.
P.P.P.S. Guix has subjected itself to complicated policy choices that
are not limitations of Debbugs, per se, like sending one patch per email
for a patch series, which increase the complication for some submitters
and reviewers alike (perhaps limitations of email size limits have
required this, though).
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 13 Mar 2025 01:21:02 GMT)
Full text and
rfc822 format available.
Message #311 received at 76503 <at> debbugs.gnu.org (full text, mbox):
> One thing I particularly like is that the final message (well, the one
> before 'deleted branch *typst*') shows you the commit that was finally
> merged. On the mailing lists, many of the issues are closed with a
> message like 'applied with minor tweaks, thanks', and not all committers
> will note the commit hash - so you're left grepping for the patch
> subject line in `git log` if you want to know what tweaks were made.
> Codeberg automatically notes the hash, and you can see the final
> iteration just by clicking on it!
That is an excellent suggestion. I have registered a feature request at
https://issues.guix.gnu.org/76989 . I will implement it, unless we
switch to Codeberg and mumi is no more.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 13 Mar 2025 15:07:02 GMT)
Full text and
rfc822 format available.
Message #314 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I'm not really using Guix at this point, because of some weird
(and probably rare) updating issues (1) but I still do really like
the project. Also please note that I am barely a guix contributor.
I only have a few patches in guix, but I hope Guix continues to succeed!
Here's my two cents:
Guix sysadmins are really tired of maintaining mumi, right? We want to move
that maintence burden onto a forge that is externally maintained.
The goal in this proposal is to move guix development to a forge and depricate
issues.guix.gnu.org, and the guix mailing lists: guix-devel <at> gnu.org
and bugs-guix <at> gnu.org, guix-patches <at> gnu.org.
Would it be possible to depricate issues.guix.gnu.org, use codeberg as a forge,
and keep the mailing lists guix-devel <at> gnu.org, bug-guix <at> gnu.org and guix-patches <at> gnu.org?
That way people that perfer mailing lists can continue to use them, and the
people that want to use a forge can. And the guix sysadmins no longer
have to maintain issues.guix.gnu.org. The Savannah people would continue
to maintain guix's mailing lists.
I would request that we at least keep the bugs-guix <at> gnu.org. I like being
able to email and ask for help.
I am going to miss reading guix-devel <at> gnu.org. That's always a fun past time. :(
Joshua
1) https://gnucode.me/guix-deploy-failed-to-update-my-guix-server.html
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 13 Mar 2025 18:50:02 GMT)
Full text and
rfc822 format available.
Message #317 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Am 07.03.25 um 16:37 schrieb Ricardo Wurmus:
> We have had non-trivial patches with a number of revisions on the
> guix-science channel.
>
> Examples:
>
> https://codeberg.org/guix-science/guix-science/pulls/59
> https://codeberg.org/guix-science/guix-science/pulls/75
Thanks for sharing. IMHO these are good examples showing that a forge
can offer a better view on the state of the patches:
Under "commits" one gets a patch-based view, under "files" one gets a
file-based view — both at the current state of the code. If one is
interested in differences to the former attempts, they can compare the
revisions. One can also see which comments have been solved and which
are still open. This makes it easier to review and to know about the
current state of the patch than in an email-based workflow.
I'd never do this with a email-based workflow — as this requires to
create a local branch for every revision of the patch series.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goebel <at> crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 13 Mar 2025 19:00:02 GMT)
Full text and
rfc822 format available.
Message #320 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Am 07.03.25 um 10:21 schrieb Ricardo Wurmus:
>
> As a long time contributor with commit access I have the impression that
> people new to Guix hold the assumption that the current system and
> workflow works for long time contributors. I may just be wildly
> incompetent, but for me it most assuredly does not work in enabling
> reviews.
Same here.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goebel <at> crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 13 Mar 2025 19:32:02 GMT)
Full text and
rfc822 format available.
Message #323 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Am 07.03.25 um 17:01 schrieb Felix Lechner via Development of GNU Guix
and the GNU System distribution.:
> There could be. I mated Debbugs with Public Inbox.
>
> My system scans Debbugs for changes [1] but does not yet maintain
> inboxes by bug number. The information is available via the NNTP news
> protocol, for example with the Gnus configuration below. People could
> subscribe to bugs via a news reader and reduce their mail load.
Interesting solution. Glad that it works for you.
Anyhow it basically just moves from an email inbox to a news inbox. It's
still based on (email) messages, inheriting all the issues from there
(see e.g. Leo's description
<https://yhetil.org/guix/Z6AeWS0TjDRvPEiU <at> jasmine.lan/>).
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goebel <at> crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 14 Mar 2025 21:41:02 GMT)
Full text and
rfc822 format available.
Message #326 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Vagrant,
Thanks for sharing your experience, it’s definitely relevant!
Vagrant Cascadian <vagrant <at> debian.org> skribis:
> Is there duplication of issues? Yup. Sometimes one needs to get
> forwarded to the other manually. Whee.
>
>
> Do issues get automatically closed on both systems? Usually, if you
> remember to include the right incantations in your commit messages!
> Occasionally even if you forget, what magic is that?!
Wait, are users told they can report bugs not just to Debbugs but also
to salsa.debian.org? (Back when I used Debian, email, possibly via
‘reportbug’, was the only way to report bugs.)
In practice, would you say that there’s a group only paying attention to
salsa and another one only paying attention to Debbugs? Or is it less
clear-cut than that?
> I do feel, given what I have heard from several people in this
> discussion, that proposing a flag day with a short time of overlap is
> going to be very hard for this community, and possibly more divisive
> than whatever fracturing we might encounter by maintaining two
> concurrent technical systems over an extended time period...
Note that, as currently worded, the flag day is only for new bug reports
and patches; if we were to adopt it as-is, we’d continue using Debbugs
for months or years to process the backlog.
It wouldn’t be as sharp a transition as it may seem.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 14 Mar 2025 21:46:02 GMT)
Full text and
rfc822 format available.
Message #329 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello Guix!
It’s been one month since this GCD was submitted, which means there’s
only (only?) one month left! Thanks to everyone who contributed to the
discussion so far, it’s good to have this diversity of viewpoints and
experiences.
For the remaining time, I think we should focus on finding what it would
take to reach consensus on a variant of this proposal sharing goals
along the lines of those stated in the intro:
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.
If you brought up ideas or concerns, consider submitting a patch against
the existing proposal; what would you change to the text?
Please make sure to take a step back, taking into consideration the
experience we have collectively (with Codeberg and other forges, with
migrations, with free software project workflows, etc.) and what sounds
desirable for the project’s future, putting aside personal preferences
and short-term issues for a moment.
I’m confident we can find common ground!
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 14 Mar 2025 22:24:02 GMT)
Full text and
rfc822 format available.
Message #332 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2025-03-14, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant <at> debian.org> skribis:
>> Is there duplication of issues? Yup. Sometimes one needs to get
>> forwarded to the other manually. Whee.
>>
>>
>> Do issues get automatically closed on both systems? Usually, if you
>> remember to include the right incantations in your commit messages!
>> Occasionally even if you forget, what magic is that?!
>
> Wait, are users told they can report bugs not just to Debbugs but also
> to salsa.debian.org? (Back when I used Debian, email, possibly via
> ‘reportbug’, was the only way to report bugs.)
I suspect your days with Debian predate salsa.debian.org by wide
margins. :)
Not sure what users are told these days! I definitely get issues, bugs,
patches, etc. on both systems for most of my packages. Sometimes I get
issues which point to a prior submission on the other system.
> In practice, would you say that there’s a group only paying attention to
> salsa and another one only paying attention to Debbugs? Or is it less
> clear-cut than that?
I think there are both maintainers, contributors and other users paying
more attention to one or the other system... and to be honest, there are
maintainers that seem to pay attention to neither! It seems largely up
to individual preferences (and the intersection of multiple parties
preferences). I cannot say I get a sense of a "type" of user using one
or the other system.
>> I do feel, given what I have heard from several people in this
>> discussion, that proposing a flag day with a short time of overlap is
>> going to be very hard for this community, and possibly more divisive
>> than whatever fracturing we might encounter by maintaining two
>> concurrent technical systems over an extended time period...
>
> Note that, as currently worded, the flag day is only for new bug reports
> and patches; if we were to adopt it as-is, we’d continue using Debbugs
> for months or years to process the backlog.
>
> It wouldn’t be as sharp a transition as it may seem.
That seems like a reasonable plan to a large extent, though I still get
the sense that there are some people who would like it to last
considerably longer.
Might be worth spelling out the various tradeoffs of what it would
require for a short, medium and long transition; I am not really sure
what they are off the top of my head...
From my personal experiences with Debian, it looks to me possible to do
both systems for a long time, but the extent of the downsides are
unclear to me.
live well,
vagrant
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sat, 15 Mar 2025 07:05:01 GMT)
Full text and
rfc822 format available.
Message #335 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
I have only distantly followed the discussion, but this triggers a
reaction from me:
Le vendredi 14 mars 2025 à 22:45 +0100, Ludovic Courtès a écrit :
> and patch tracking to Codeberg,
> a “modern” forge hosted by a non-profit.
I would have written “a web-based forge” or web-firt or web-oriented or
web-facing… here instead of modern with quotes. “modern” may prompt
unwanted questions like why is it modern, why is the previous thing not
modern, why are there quotes etc.
Please discard if this is off-topic.
Vivien
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sat, 15 Mar 2025 21:12:02 GMT)
Full text and
rfc822 format available.
Message #338 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Vivien,
Vivien Kraus <vivien <at> planete-kraus.eu> skribis:
> Le vendredi 14 mars 2025 à 22:45 +0100, Ludovic Courtès a écrit :
>> and patch tracking to Codeberg,
>> a “modern” forge hosted by a non-profit.
>
> I would have written “a web-based forge” or web-firt or web-oriented or
> web-facing… here instead of modern with quotes. “modern” may prompt
> unwanted questions like why is it modern, why is the previous thing not
> modern, why are there quotes etc.
I dislike that term too (hence the quotes) but couldn’t think of a
better short qualifier.
Perhaps “an integrated forge with a Web interface, hosted by a
non-profit”?
Thanks,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sat, 15 Mar 2025 21:23:01 GMT)
Full text and
rfc822 format available.
Message #341 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Vagrant Cascadian <vagrant <at> debian.org> skribis:
> From my personal experiences with Debian, it looks to me possible to do
> both systems for a long time, but the extent of the downsides are
> unclear to me.
I’d say that the main downsides of having two systems, for
new/occasional contributors would be confusion (where am I supposed to
report issues/propose changes?) and extra work (having to search in both
places).
For regular contributors, it’s extra work of checking two systems,
missing out if you choose to use check only one.
For the community, fragmentation, information loss (due to having to
manually check if a topic is discussed in the other system), extra
friction due to difficulties to refer to entries across systems.
Perhaps worth discussing in the document under “Drawbacks and Open
Issues”?
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 17 Mar 2025 12:23:03 GMT)
Full text and
rfc822 format available.
Message #344 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
On Sat, 15 Mar 2025 at 22:22, Ludovic Courtès <ludo <at> gnu.org> wrote:
> Vagrant Cascadian <vagrant <at> debian.org> skribis:
>
>> From my personal experiences with Debian, it looks to me possible to do
>> both systems for a long time, but the extent of the downsides are
>> unclear to me.
That’s my proposal: having more milestones for the Migration Paths.
> I’d say that the main downsides of having two systems, for
> new/occasional contributors would be confusion (where am I supposed to
> report issues/propose changes?) and extra work (having to search in both
> places).
>
> For regular contributors, it’s extra work of checking two systems,
> missing out if you choose to use check only one.
>
> For the community, fragmentation, information loss (due to having to
> manually check if a topic is discussed in the other system), extra
> friction due to difficulties to refer to entries across systems.
Somehow, I’m a bit confused. One argument is to say: Codeberg has a
nice API. Cool! Therefore, on one hand, people™ can adapt their own
tools in order to exploit it. However, on the other hand, people™
cannot exploit it to teach Mumi and/or etc/teams.scm.
Well, I do not see any drawbacks if we are crystal clear that Codeberg
and PR will be the main entry-point and the reference.
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 17 Mar 2025 12:24:03 GMT)
Full text and
rfc822 format available.
Message #347 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
On Mon, 10 Mar 2025 at 23:17, Ludovic Courtès <ludo <at> gnu.org> wrote:
> Migrating between Forgejo instances would be trivial: Forgejo supports
> it as well.
Assuming we still have access to all the content hosted on Codeberg.
> We don’t know what the future will look like, but given the rich
> interface and structured data, I’m confident that it will always be
> possible to extract it and feed it into other similar systems.
This raises the question about the backup [1.2].
A worst scenario: tomorrow Codeberg closes for whatever unexpected
reasons. Obviously, we will find another solution. :-)
However, what about all the history hosted there? Yes, there is a nice
API and everything is doable. :-) To my knowledge, nothing is done for
having a backup of all the history. Therefore, if Codeberg suddenly
disappears, then all our history hosted there will be lost.
Cheers,
simon
1: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <zimon.toutoune <at> gmail.com>
Mon, 10 Mar 2025 13:30:44 +0100
id:87frjl6paj.fsf <at> gmail.com
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/87frjl6paj.fsf <at> gmail.com
https://yhetil.org/guix/87frjl6paj.fsf <at> gmail.com
2: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <zimon.toutoune <at> gmail.com>
Thu, 06 Mar 2025 17:36:29 +0100
id:874j066rqq.fsf <at> gmail.com
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/874j066rqq.fsf <at> gmail.com
https://yhetil.org/guix/874j066rqq.fsf <at> gmail.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 17 Mar 2025 12:24:03 GMT)
Full text and
rfc822 format available.
Message #350 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
On Fri, 14 Mar 2025 at 22:45, Ludovic Courtès <ludo <at> gnu.org> wrote:
> If you brought up ideas or concerns, consider submitting a patch against
> the existing proposal; what would you change to the text?
My concrete proposals:
1. Drop the section of « Issue Tracker Migration Path ».
It appears to me orthogonal. And to my knowledge, it’s not a
current bottleneck. Moreover, for what my opinion is worth on that
topic: I disagree to force people to register on Codeberg in order
to report a bug.
2. It’s missing:
a) How to deal with moderation?
b) How to deal with the backup of the history?
If tomorrow, the Debbugs instance suddenly disappears for some
unexpected reasons, nothing about our development history will be
lost: We have many copies of guix-patches around; even on
Software Heritage [1]. ;-)
We need a plan about Codeberg.
c) A discussion allowing write-access for dedicated branches.
If that’s not currently possible, we probably need to open a
request upstream and for sure mention this feature request under
section « Drawbacks and Open Issues ».
The short paragraph under section « Rights and Privileges » is
unclear, IMHO.
Under section « Teams », what does the paragraph “All these teams
would have read-only access to the repositories […]” mean?
3. More milestones for the « Repository Migration Paths ».
Let aside my personal opinion, so I will not repeat [2]. ;-)
Somehow, we are putting all our eggs in the same basket without any
guarantees about this very same basket. :-)
For sure, the Migration will be at worst a neutral thing – same
bottlenecks as today – and at best a good thing!
That’s said, do we all – The Reviewers™ – have enough a minimal
experience with PR workflows? In order to smooth the migration for
The Reviewers™. Concretely and today! Because if my count is
correct: on the 23rd of May, PR will be active and nothing more.
I propose to condition the migration with milestones:
a) “The [QA frontpage] and its [Data Service] 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.”
Why not make it first, before all the migration?
b) “scalability will be the major concern here; additional
developments may be needed to consolidate this support”
Why not automatically create AGit PR from Debbugs for 1-2 months
and guard the issues?
c) “We will arrange so that the build status of a pull request is
clearly visible right from that pull request.”
Why not make it first, before all the migration?
d) “This will have to be addressed to fully take advantage of the
new pull-request workflow.”
Why not make it first, before all the migration?
e) Open a discussion on Guix Foundation side about how to support,
etc.
All in all, the milestones I’m proposing could be:
i) Teach etc/teams.scm for refusing single patch with less than 5
lines or series including more than 10 patches; instead ask to
send it via PR.
Keep that for 3-4 months; feed the fixes about items a)--d)
ii) Only mention Codeberg in the documentation starting on 11th of
September.
iii) Increase the rule of etc/teams.scm for refusing more patches.
iv) On 1st of December, The Big Move.
Well, that’s a proposal. It’s up to many refinements. :-) Somehow,
it could help many of us without any minimal experience with the PR
workflow and in the same time also help to improve our infra
(CI/QA).
What I dislike – not to say I disagree – with the current Migration
Path is the “sudden” switch. The community is taking care about not
breaking existing tools or let the time to adjust. However, we do
not apply such principle for our own workflow: worry-hurry. :-)
Cheers,
simon
1: The first patch sent to guix-patches.
https://archive.softwareheritage.org/swh:1:cnt:ce7a09543926f7e5717b7a3f8fa3c1f6d5fdb5f1
2: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <zimon.toutoune <at> gmail.com>
Mon, 10 Mar 2025 13:30:44 +0100
id:87frjl6paj.fsf <at> gmail.com
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/87frjl6paj.fsf <at> gmail.com
https://yhetil.org/guix/87frjl6paj.fsf <at> gmail.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 17 Mar 2025 16:45:03 GMT)
Full text and
rfc822 format available.
Message #353 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Simon!
Simon Tournier <zimon.toutoune <at> gmail.com> skribis:
> 1. Drop the section of « Issue Tracker Migration Path ».
To be clear, are you suggesting to not use Codeberg for bug reports at
all?
To me using Codeberg’s bug tracker is an integral part of the proposal
(it’s in the title).
We could change it to “Migrating repositories and patches to Codeberg”;
that has less appeal to me, because I’m confident that (1) this would
lead to confusion, and (2) we’d miss out on cross-referencing and other
niceties.
I too hate having to create an account, but let’s face it: we’re used to
it these days, and Codeberg allows you to sign in with a gitlab.com or
github.com account (I don’t support any of these, but it’s a fact that
many people have an account there already.) “Necessary evil” for me.
As I wrote elsewhere, we’ll also gladly take bug reports on guix-devel
in practice (we already get bug reports occasionally on mailing lists,
IRC, etc.), so nobody would be “forced” to sign in on Codeberg.
> a) How to deal with moderation?
Conversations (PRs, issues) can be locked by the “owners” of the project
on Codeberg; it’s also possible to block individual users.
Is that the kind of moderation you have in mind?
> b) How to deal with the backup of the history?
I would rely on backups done by Codeberg e.V. after checking with them
what’s in place.
We could also set up our own thing; I’ll inquire to see if there are
tools to do that for regular users.
(Keep in mind though that nobody stepped up to help out with backups of
our existing infrastructure, though.)
> c) A discussion allowing write-access for dedicated branches.
Opening a PR gives access to a dedicated branch; I suppose that would be
the main approach, available to everyone.
Getting a dedicated branch on the guix/guix repo wouldn’t be different
from now, where committers can create branches on their own.
What would you add on this topic in the document?
> The short paragraph under section « Rights and Privileges » is
> unclear, IMHO.
The goal is to explain how to transfer rights from Savannah to Codeberg.
I’m happy to rewrite it if you can tell me more.
> Under section « Teams », what does the paragraph “All these teams
> would have read-only access to the repositories […]” mean?
I’ll drop it; it remains from the pre-GCD draft I sent and is beyond the
scope of this document.
> 3. More milestones for the « Repository Migration Paths ».
On experience: collectively, we have experience with Codeberg and with
other forges; many of us frequently interact with this kind of forge.
So, while switching to Codeberg is a big change, I think we should also
not downplay the ability of contributors to adapt to something many/most
of them already know.
> I propose to condition the migration with milestones:
>
> a) “The [QA frontpage] and its [Data Service] 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.”
>
> Why not make it first, before all the migration?
I did not make that a blocker because then someone would have to commit
to doing the work. My contribution here is to make sure that what is
done for Cuirass can easily be reused elsewhere; that’s largely the
case¹ and I’m also happy to give a hand with integration efforts.
¹ https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/src/cuirass/forges/forgejo.scm
> b) “scalability will be the major concern here; additional
> developments may be needed to consolidate this support”
>
> Why not automatically create AGit PR from Debbugs for 1-2 months
> and guard the issues?
What would it buy us?
How would we do that? (The Guix project is not an admin of bugs.gnu.org.)
> c) “We will arrange so that the build status of a pull request is
> clearly visible right from that pull request.”
>
> Why not make it first, before all the migration?
We (Romain and myself) have been working on that and eating our own
dogfood by using it for the Guix-Science channels:
<https://hpc.guix.info/blog/2025/01/join-the-guix-science-community/>.
Yet, I think that requiring it to be production-ready on Day 1 would be
too much to ask. Also, because we don’t have anything close to this
feature right now, I think it would be “unfair” to make it a
prerequisite.
> e) Open a discussion on Guix Foundation side about how to support,
> etc.
On how to support Codeberg e.V.? I can email guix-europe to test the
waters.
> All in all, the milestones I’m proposing could be:
>
> i) Teach etc/teams.scm for refusing single patch with less than 5
> lines or series including more than 10 patches; instead ask to
> send it via PR.
>
> Keep that for 3-4 months; feed the fixes about items a)--d)
>
> ii) Only mention Codeberg in the documentation starting on 11th of
> September.
>
> iii) Increase the rule of etc/teams.scm for refusing more patches.
>
> iv) On 1st of December, The Big Move.
An incremental move from guix-patches to PRs as you suggest sounds
perfectly reasonable to me (I see a risk of fragmentation between the
two systems but maybe it’s unlikely, as Vagrant’s experience suggests).
I’m not sure whether/how ‘teams.scm’ could help here, but I’ll propose
changes along these lines.
Thanks for your feedback!
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 17 Mar 2025 17:00:04 GMT)
Full text and
rfc822 format available.
Message #356 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Sun, 23 Feb 2025 at 16:20, Ludovic Courtès <ludo <at> gnu.org> wrote:
> ## Continuous Integration
[...]
> 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),
[...]
> ## 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).
Currently, the name of specifications reads [1]:
forgejo-pull-requests-guix-science-carputils-91
forgejo-pull-requests-guix-science-equinox-cherrypick-84
forgejo-pull-requests-guix-science-ghdl-87
forgejo-pull-requests-guix-science-master-47
forgejo-pull-requests-guix-science-nonfree-IPHC-dev-31
forgejo-pull-requests-guix-science-pyvhdlmodel-86
forgejo-pull-requests-guix-science-typst-languagetool-92
and that’s annoying: it’s difficult to find the relevant specifications.
Yes, I’ve seen [2] – cool! \o/ – and this potentially open a badge on
the PR webpage. :-)
Still, it would be much better to have the PR number first and not last.
For instance:
forgejo-pull-requests-guix-science-47-master
forgejo-pull-requests-guix-science-84-equinox-cherrypick
forgejo-pull-requests-guix-science-86-pyvhdlmodel
forgejo-pull-requests-guix-science-87-ghdl
forgejo-pull-requests-guix-science-91-carputils
forgejo-pull-requests-guix-science-92-typst-languagetool
forgejo-pull-requests-guix-science-nonfree-31-IPHC-dev
That’s a tiny detail but before we jump in the big bath… :-)
Cheers,
simon
1: https://guix.bordeaux.inria.fr/
2: [bug#76938] [PATCH Cuirass 00/13] Forges notification support.
Romain GARBAGE <romain.garbage <at> inria.fr>
Tue, 11 Mar 2025 11:29:21 +0100
id:20250311103218.28873-1-romain.garbage <at> inria.fr
https://issues.guix.gnu.org/76938
https://issues.guix.gnu.org/msgid/20250311103218.28873-1-romain.garbage <at> inria.fr
https://yhetil.org/guix/20250311103218.28873-1-romain.garbage <at> inria.fr
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 17 Mar 2025 17:09:01 GMT)
Full text and
rfc822 format available.
Message #359 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
>> c) A discussion allowing write-access for dedicated
>> branches.
>
> Opening a PR gives access to a dedicated branch; I suppose that
> would be
> the main approach, available to everyone.
>
> Getting a dedicated branch on the guix/guix repo wouldn’t be
> different
> from now, where committers can create branches on their own.
>
> What would you add on this topic in the document?
Can we as "owners" of the repository grant individuals write
access to a dedicated branch that was opened by a pull request?
This would allow a team to grant a collaborator write access to
pushing to their team branch.
I suppose even if this worked in principle we'd have the problem
that commits by these collaborators would have to be signed by a
known key in the keyring.
>> b) “scalability will be the major concern here; additional
>> developments may be needed to consolidate this support”
>>
>> Why not automatically create AGit PR from Debbugs for
>> 1-2 months
>> and guard the issues?
>
> What would it buy us?
Is the goal here to give the Codeberg bug tracker an honest try
before committing to switiching over? I think the downsides of
increased confusion weigh heavier. It is already confusing that
debbugs sends confirmation emails that mention something other
than issues.guix.gnu.org. Increasing the number of systems to
three does not seem like a good idea to me.
>> All in all, the milestones I’m proposing could be:
>>
>> i) Teach etc/teams.scm for refusing single patch with
>> less than 5
>> lines or series including more than 10 patches;
>> instead ask to
>> send it via PR.
>>
>> Keep that for 3-4 months; feed the fixes about items
>> a)--d)
>>
>> ii) Only mention Codeberg in the documentation starting on
>> 11th of
>> September.
>>
>> iii) Increase the rule of etc/teams.scm for refusing more
>> patches.
>>
>> iv) On 1st of December, The Big Move.
>
> An incremental move from guix-patches to PRs as you suggest
> sounds
> perfectly reasonable to me (I see a risk of fragmentation
> between the
> two systems but maybe it’s unlikely, as Vagrant’s experience
> suggests).
> I’m not sure whether/how ‘teams.scm’ could help here, but I’ll
> propose
> changes along these lines.
Can we already reject patches that have been sent without
involving our tooling? (E.g. without Cc-ing a team.) Only then
could we enforce anything like the above.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 19 Mar 2025 21:54:01 GMT)
Full text and
rfc822 format available.
Message #362 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
Ricardo Wurmus <rekado <at> elephly.net> skribis:
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>>> c) A discussion allowing write-access for dedicated
>>> branches.
>>
>> Opening a PR gives access to a dedicated branch; I suppose that
>> would be
>> the main approach, available to everyone.
>>
>> Getting a dedicated branch on the guix/guix repo wouldn’t be
>> different
>> from now, where committers can create branches on their own.
>>
>> What would you add on this topic in the document?
>
> Can we as "owners" of the repository grant individuals write access to
> a dedicated branch that was opened by a pull request? This would allow
> a team to grant a collaborator write access to pushing to their team
> branch.
When adding a “collaborator”, we give them read or write access to the
repo.
But then, the branch protection rules let you restrict push to only
specific users and/or teams.
So we could arrange so that only members of a specific team can push to
‘master’, for instance.
Though I’m not sure we have to come up with something more sophisticated
than we currently have, at least not from Day 1.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 19 Mar 2025 22:52:02 GMT)
Full text and
rfc822 format available.
Message #365 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
I pushed the changes below, which I think address some of the concerns
that you and others raised:
8d0b5c6 * 002-codeberg: Avoid “modern” in the summary.
fe88728 * 002-codeberg: Clarify “Repository Migration Path”.
21f57f0 * 002-codeberg: Change to a more gradual issue tracker migration.
75c96e9 * 002-codeberg: Clarify “Rights and Privileges”.
2c1b5cb * 002-codeberg: Fix typo.
The most important change is the gradual issue/patch tracker migration:
--8<---------------cut here---------------start------------->8---
- Until **December 31st, 2025**, bug reports will be accepted both by
email (`bug-guix` and `guix-patches`) and on Codeberg (issues and
pull requests); documentation will encourage people to choose
Codeberg, but contributors will keep paying attention to both
systems.
- Soon after **January 1st, 2026**, 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 to
open *new* issues will not get through anymore.
- Interaction on individual issues that were opened via Debbugs before
this deadline may continue on Debbugs for as long as needed, *via*
`NNN <at> debbugs.gnu.org`.
--8<---------------cut here---------------end--------------->8---
I believe this is the most contentious issue so we should keep iterating
and fine-tuning it.
I also clarified that the flag day mentioned under “Repository Migration
Path” is only for the repository, not for Debbugs, because I believe
this might have caused confusion.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 20 Mar 2025 10:44:02 GMT)
Full text and
rfc822 format available.
Message #368 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Simon Tournier <zimon.toutoune <at> gmail.com> writes:
> For instance, magit-forge does not work with Codeberg although their
> documentation says so. Well, neither Ludo or I have succeeded in
> configuring it, although we asked advice on Mastodon [1,2].
magit-forge has practically no support for forgejo yet, it only knows
how to find the urls of certain web pages related to a project such as
the issues page. The documentation is just a bit unclear about that.
As I understand it, proper forgejo support is planned, and it is
intended to be the next supported forge in magit-forge
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 21 Mar 2025 16:05:02 GMT)
Full text and
rfc822 format available.
Message #371 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
Simon Tournier <zimon.toutoune <at> gmail.com> skribis:
> Currently, the name of specifications reads [1]:
>
> forgejo-pull-requests-guix-science-carputils-91
> forgejo-pull-requests-guix-science-equinox-cherrypick-84
> forgejo-pull-requests-guix-science-ghdl-87
> forgejo-pull-requests-guix-science-master-47
> forgejo-pull-requests-guix-science-nonfree-IPHC-dev-31
> forgejo-pull-requests-guix-science-pyvhdlmodel-86
> forgejo-pull-requests-guix-science-typst-languagetool-92
>
> and that’s annoying: it’s difficult to find the relevant specifications.
Improving this is among the things that have been on our mind for a
while; it looks better now:
https://guix.bordeaux.inria.fr/pull-requests
We’re making progress, at our own pace. :-)
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 21 Mar 2025 19:14:02 GMT)
Full text and
rfc822 format available.
Message #374 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
I have not read yet the updated version…
> An incremental move from guix-patches to PRs as you suggest sounds
> perfectly reasonable to me
> I’ll propose
> changes along these lines.
…so I will comment elsewhere about how “incremental” it appears to
me. :-)
Initially, my objective here was to focus on few points and just precise
my previous comments. Then, I do not know who released my fingers. :-)
All will be fine with if my words are redirected to /dev/null. At
least, there are here for the record.
>> 1. Drop the section of « Issue Tracker Migration Path ».
>
> To be clear, are you suggesting to not use Codeberg for bug reports at
> all?
To be clear, yes.
> We could change it to “Migrating repositories and patches to Codeberg”;
> that has less appeal to me, because I’m confident that (1) this would
> lead to confusion, and (2) we’d miss out on cross-referencing and other
> niceties.
Cross-referencing fully locked in the Codeberg web-interface, right?
Which niceties do you speak about?
> I too hate having to create an account, but let’s face it: we’re used to
> it these days, and Codeberg allows you to sign in with a gitlab.com or
> github.com account (I don’t support any of these, but it’s a fact that
> many people have an account there already.) “Necessary evil” for me.
>
> As I wrote elsewhere, we’ll also gladly take bug reports on guix-devel
> in practice (we already get bug reports occasionally on mailing lists,
> IRC, etc.), so nobody would be “forced” to sign in on Codeberg.
It’s not about being “forced” or not, it’s about the signal it sends.
For instance, I cannot promote Free Software and advocate at length
about user-autonomy. Then somehow give up and say: Hey, no worry when
you don’t want to create yet another account, Codeberg bridges with .com
companies as gitlab or maybe worse github.
Somehow, I share the argument “we must act now about reviewing” because
a vicious circle is emerging and it could be detrimental more or less
quickly. And I also share the argument: it’s complicated to bridge the
submissions by email with CI – although we did not tried very hard if we
all are honest; Chris almost alone did – when it’s much easier with
Codeberg thanks to its rich API. For reviewing, what Codeberg brings on
the table outperforms the contradictory signal.
I consider the point about “lead to confusion” but that’s appear to me
weaker than the contradictory signal about user-autonomy.
Because we have to be very clear: the migration from emails to Codeberg
isn’t only the technical migration of the workflow. It’s much deeper:
it’s a “philosophical” migration.
It’s a migration from relying on standards protocols to relying on one
external central service. On one hand, it promotes user-autonomy and
illustrates the freedom by the example, because it pushes us to shape
our tools – yes, imperfect tools with many friction. On the other hand,
it promotes “efficiency” to do more or quicker with counterparts; the
freedom is locked. All the story isn’t about one being “evil” while the
other being “angel”, or vice-versa. All is grey and the story is about
the flavor of this grey.
We have to be very clear, it’s two-ways: communities shape their tool as
much as their tool shape the communities. I hope we are all aware that
this migration will modify the profile of people involved in the Guix
community. For the Good, the Bad and the Ugly.
>> b) How to deal with the backup of the history?
>
> I would rely on backups done by Codeberg e.V. after checking with them
> what’s in place.
Yes, OVH also told all will be fine. ;-)
> We could also set up our own thing; I’ll inquire to see if there are
> tools to do that for regular users.
This is what I have in mind. Please note I’m not considering this as
blocking or something we must have on Day-1.
> (Keep in mind though that nobody stepped up to help out with backups of
> our existing infrastructure, though.)
By design of mailing lists, it’s distributed and easy to recover in
extreme worst case scenario.
All the inboxes of subscribers are backup for patches and bugs. :-) In
addition, there is the mirrors of the mailing lists as Mail Archive or
others. Last, there is one public-inbox instance and thus many
public-inbox clones.
You agreed on more incremental migration. So I do not know who the
following is trying to convince. :-)
Maybe it’s an hidden call to the Deliberation member… Heh!
>> 3. More milestones for the « Repository Migration Paths ».
>
> On experience: collectively, we have experience with Codeberg and with
> other forges; many of us frequently interact with this kind of forge.
Who is the ’collective’? How many of the current people with write
access on Savannah have an account in Codeberg? And how many concretely
did at least one review (with comments) and merged a PR?
As I wrote elsewhere:
Just to mention. What Ludo did months ago, Ludo tried Codeberg, then
Ludo moved the channels guix-science, then Romain adapted Cuirass – or
maybe Romain adapted Cuirass before the guix-science channels move,
anyway–, then ~100 PRs has been submitted. Etc. All that creates this
minimal experience.
Now, when Ludo says: it’s okish enough and it’ll be fine with me, yes I
trust their words. Because they are somehow backed.
How many of us have a same minimal experience with PR?
Somehow, you developed a experience. Who Deliberation members might
report a minimal experience?
> So, while switching to Codeberg is a big change, I think we should also
> not downplay the ability of contributors to adapt to something many/most
> of them already know.
Obviously. :-) The question is about having an informed decision by the
people who deliberate. And not a vague picture from a galaxy far, far
away.
It’s not to make the decision bigger than it is. If I ask to the Ludo
from one year ago (before investing time with Codeberg and propose to
switch to the Guix-Science channel), do you want yo migrate? What would
have been your answer? Probably the same as I am doing now: Euh, yes
why not but hmm I am not sure, well I do not know.
Somehow, imagine all the annoyances you have with Emacs. Now, imagine I
tell you: Hey, look this tool does the same as Emacs without the
annoyances you are pointing and yes you can also extend it. Many people
use it. And some users are around. Wonderful, no? Do you switch
without trying it a bit?
If yes, cool now you are an happy user of VSCode for the next
decade. ;-)
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 24 Mar 2025 11:59:01 GMT)
Full text and
rfc822 format available.
Message #377 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Fri, 21 Mar 2025 at 17:04, Ludovic Courtès <ludo <at> gnu.org> wrote:
> Improving this is among the things that have been on our mind for a
> while; it looks better now:
>
> https://guix.bordeaux.inria.fr/pull-requests
>
> We’re making progress, at our own pace. :-)
Cool! It’s much better. :-)
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 24 Mar 2025 11:59:02 GMT)
Full text and
rfc822 format available.
Message #380 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
I’m just discovering the Forgejo instance of sourceware:
https://forge.sourceware.org/explore/organizations
Here, mirror of GCC, Glibc and others are already hosted.
Therefore, it would make sense to check their willing and capacity to
backup Guix; I have in mind to ask for hosting read-only copies of all
the PRs, i.e., a plan B for the history of all the PRs.
WDYT?
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 25 Mar 2025 08:48:02 GMT)
Full text and
rfc822 format available.
Message #383 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Simon,
Simon Tournier <zimon.toutoune <at> gmail.com> skribis:
>>> 1. Drop the section of « Issue Tracker Migration Path ».
>>
>> To be clear, are you suggesting to not use Codeberg for bug reports at
>> all?
>
> To be clear, yes.
OK. So postponing bug/issue tracker migration to Jan. 2026 as the GCD
now states (based on what you proposed¹) doesn’t address your concerns?
Or perhaps I misinterpreted your proposal?
¹ https://issues.guix.gnu.org/76503#115-lineno87
>> We could change it to “Migrating repositories and patches to Codeberg”;
>> that has less appeal to me, because I’m confident that (1) this would
>> lead to confusion, and (2) we’d miss out on cross-referencing and other
>> niceties.
>
> Cross-referencing fully locked in the Codeberg web-interface, right?
>
> Which niceties do you speak about?
Off the top of my head:
• notifications (subscribe/unsubscribe to individual issues, ping
individual people or team);
• automatically notify the right people on PRs via ‘CODEOWNERS’;
• cross-referencing (see when someone refers to an issue/PR from
another issue/PR/commit; close issues when a commit messages says
so);
• tagging, classification;
• ability to use PR/issue templates to guide people and ease
onboarding;
• API access allowing bots to comment on PRs for instance (fresh from
the oven: Cuirass now sends comments indivicating build status on
PRs).
Many of these features may seem anecdotal, but IME they really help with
triage and with getting the attention of the right people, which I think
is critical for a project the size of Guix.
(All this information is available to all the user interfaces, not just
the web interface.)
> For instance, I cannot promote Free Software and advocate at length
> about user-autonomy.
[...]
> Because we have to be very clear: the migration from emails to Codeberg
> isn’t only the technical migration of the workflow. It’s much deeper:
> it’s a “philosophical” migration.
As you know, I very much understand these issues, I know why I chose
Debbugs at a time when Git{Hub,Lab} were already popular; they are
discussed (on your request) in the GCD. To me, it’s a compromise.
In an ideal world, we would self-host, which would address some of these
concerns. It doesn’t seem viable at this point, but if/when somebody
steps up, this remains open.
>> We could also set up our own thing; I’ll inquire to see if there are
>> tools to do that for regular users.
>
> This is what I have in mind. Please note I’m not considering this as
> blocking or something we must have on Day-1.
I did inquire on Mastodon: nobody came up with the ready-to-use tool to
do backup. We could use the HTTP API, which exposes everything, to
approximate it, but it’d be an approximation.
>> On experience: collectively, we have experience with Codeberg and with
>> other forges; many of us frequently interact with this kind of forge.
>
> Who is the ’collective’? How many of the current people with write
> access on Savannah have an account in Codeberg? And how many concretely
> did at least one review (with comments) and merged a PR?
It’s a small but strictly-positive number. But probably 100% of us have
experience with similar forges, many of us using them daily, that’s what
I meant; we cannot pretend that we’re all discovering this.
> Somehow, you developed a experience. Who Deliberation members might
> report a minimal experience?
Not sure what you mean.
> It’s not to make the decision bigger than it is. If I ask to the Ludo
> from one year ago (before investing time with Codeberg and propose to
> switch to the Guix-Science channel), do you want yo migrate? What would
> have been your answer? Probably the same as I am doing now: Euh, yes
> why not but hmm I am not sure, well I do not know.
You’re right: I’ve long been reluctant to forges of that kind, as I
wrote before. It’s been a process for me: that of seeing the
unsustainable situation Guix is in, looking at other projects do it
(check out Nixpkgs or Brew or whatever!), getting first-hand experience
with GitLab and Codeberg and how it leads to a smooth and approachable
workflow.
I understand it’s hard to “transfer” experience, and that’s why I was
hoping active contributors would give it a try to at least get a taste
of it.
Thanks for your feedback,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 25 Mar 2025 08:53:01 GMT)
Full text and
rfc822 format available.
Message #386 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
Simon Tournier <zimon.toutoune <at> gmail.com> skribis:
> I’m just discovering the Forgejo instance of sourceware:
>
> https://forge.sourceware.org/explore/organizations
>
> Here, mirror of GCC, Glibc and others are already hosted.
>
> Therefore, it would make sense to check their willing and capacity to
> backup Guix; I have in mind to ask for hosting read-only copies of all
> the PRs, i.e., a plan B for the history of all the PRs.
Sure, sounds like a good idea.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 30 Mar 2025 16:29:02 GMT)
Full text and
rfc822 format available.
Message #389 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi all,
As a relatively new contributor I am very happy to see how good of a community exists around Guix and the amazing and intelligent people that push this project forward.
I think as many have already mentioned, we should lower the barrier of entry, and also not try to swim upstream in DX (developer experience). There is a reason PR based workflow is predominant. It enhances collaboration, visibility and automation.
IMHO Why don't we stop wasting our intelligent people's time on checking formatting / best practices and have some CI workflows that run on every PR. We can push it also further and do all kinds of testing / building as well and even create automated comments that bring knowledgeable people to the PR.
I think with a bit of love we could also find a good strategy to backup our project to a plan B type of thing, in case Codeberg somehow disappears (unlikely). As for the issue tracker, I personally have no preference and really actually think the mailing list is an acceptable solution for the time being with debbugs.
I know for a fact of many Guix users (of varying technical levels) that would like to upstream things but feel discouraged when having to use patches, series of patches, etc.
Reading discussions that are non trivial is for pretty impossible currently and on a PR with comments directly in the code this is so so much better.
Merge conflicts could also be much smoother to fix and more visible,
Appreciate all your comments, just my 2 cents here,
Visca Guix!
Best, Josep
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 30 Mar 2025 19:12:01 GMT)
Full text and
rfc822 format available.
Message #392 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi!
Simon Tournier <zimon.toutoune <at> gmail.com> skribis:
> I’m just discovering the Forgejo instance of sourceware:
>
> https://forge.sourceware.org/explore/organizations
>
> Here, mirror of GCC, Glibc and others are already hosted.
>
> Therefore, it would make sense to check their willing and capacity to
> backup Guix; I have in mind to ask for hosting read-only copies of all
> the PRs, i.e., a plan B for the history of all the PRs.
I checked with people at Sourceware: they’re unable to to provide any
guarantees around mirroring Guix at the moment, their Forgejo setup
being experimental and with limited capacity (but they do hope to set up
mirrors and federation eventually).
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 14 Apr 2025 10:23:02 GMT)
Full text and
rfc822 format available.
Message #395 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello Guix!
We have just 9 days left to discuss and improve this GCD.
Please do read the document in its current form:
https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/tree/002-codeberg.md
If you brought up ideas or concerns, or if you spot anything fishy,
please consider submitting a patch.
On April 23rd, we’ll enter the deliberation period. It’s important to
try hard and address outstanding issues by then.
Thanks,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 14 Apr 2025 14:02:01 GMT)
Full text and
rfc822 format available.
Message #398 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> We have just 9 days left to discuss and improve this GCD.
>
> Please do read the document in its current form:
>
> https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/tree/002-codeberg.md
In other news, for the Emacs users among us: there’s been a number of
nice changes in ‘fj.el’ recently, notably the ability to properly render
review diffs:
https://todon.nl/@mousebot/114298304111657426
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 14 Apr 2025 19:38:02 GMT)
Full text and
rfc822 format available.
Message #401 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
Am Montag, dem 14.04.2025 um 12:22 +0200 schrieb Ludovic Courtès:
> Hello Guix!
>
> We have just 9 days left to discuss and improve this GCD.
>
> Please do read the document in its current form:
>
>
> https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/tree/002-codeberg.md
>
> If you brought up ideas or concerns, or if you spot anything fishy,
> please consider submitting a patch.
I haven't been following the discussion (it's 130 mails, phew!), so I'm
a bit out of the loop and my concerns may have already been raised and
discussed. I will probably still support or at least accept the GCD
anyway, but two things stand out:
In "Detailed Design > User Interfaces", we do talk about dedicated
Forgejo clients and nice pull request tricks, but an important user
interface I think is missing is a (preferably unauthenticated, but
moderated) way of discussing patches/merge requests. Reading until the
end of the document, this appears to be acknowledged as an open issue,
"a step back compared to the email-based workflow" – but let's put
aside the need for authentication and focus on tools. We give fj.el as
one tool that can accomplish this (though online and not offline like
email), but it seems we don't have any other; or rather that they are
only useful for Codeberg/Forgejo and nothing else. Is there any more
generic tool (besides a browser, I guess) that one can incidentally use
to also look at discussions on Codeberg?
"Detailed Design > Repository Migration Path" quite notably does not
talk about how long the Savannah repo will stay up. We already
discussed in the the branch naming GCD that people don't always update
their Guix daemons all that regularly and could thus end up seeing an
error if the repo is gone out of nowhere. Should we possibly make
stronger guarantees both here and the branch naming GCD?
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 14 Apr 2025 20:10:02 GMT)
Full text and
rfc822 format available.
Message #404 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hello Guix!
>
> We have just 9 days left to discuss and improve this GCD.
>
> Please do read the document in its current form:
>
> https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/tree/002-codeberg.md
>
> If you brought up ideas or concerns, or if you spot anything fishy,
> please consider submitting a patch.
>
> On April 23rd, we’ll enter the deliberation period. It’s important to
> try hard and address outstanding issues by then.
>
> Thanks,
> Ludo’.
Hi Ludo!
Nice GCD :)
I’ve been victim of not receiving the answers to my comments on issues
so I fully support this for the reliability! Attached are a few
suggestions I think are important.
Firstly, I change “in the future… we should” to “we will” for clarifying
the documentation.
Then, I mention that a blog post will be made to announce to the general
public.
Additionaly, I mention that if someone is unable to access Codeberg, it
is tolerated that they send the patches to guix-devel. IMO this is
really important since people might suffer from censorship, being
banned, or having their ip range banned because there are ai scrapers in
it or because they are using tor or any other reason.
Lastly, I mention that manually merging is supported directly by
Forgejo.
I still have one question after reading: will non-committers still be
able to participate in bug triage (closing, merging two issues and
reviewing)? I really enjoyed that part of trust in the contributors, it
would be a shame if it would no longer be possible.
Good evening!
Noé
[suggestions.patch (text/x-patch, inline)]
diff --git a/002-codeberg.md b/002-codeberg.md
index 1427a25..55bff86 100644
--- a/002-codeberg.md
+++ b/002-codeberg.md
@@ -165,11 +165,11 @@ who can access each repository:
- Committers to one of the other repositories can request membership
of that repository.
-In the future, we should extend the [“Commit
+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.
+section of the manual will be extended 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
@@ -238,7 +238,8 @@ this has been submitted. The `%default-channel-url` variable would
refer to `https://git.guix.gnu.org/guix.git`.
Following this commit, an entry in `etc/news.scm` would explain the
-migration. See [this entry in
+migration, accompanied by a blog post on
+<https://guix.gnu.org/en/blog/>. See [this entry in
Guix-Science](https://codeberg.org/guix-science/guix-science/commit/fd1b2dacd8d37c9d1939f9dc5a5b74256171ccbd)
for an example.
@@ -267,6 +268,9 @@ simultaneously for several months:
set up the `bug-guix` and `guix-patches` mailing lists in “Emergency
Moderation” mode in the Mailman interface—meaning that messages to
open *new* issues will not get through anymore.
+ - It will be accepted that patches are sent occasionally to
+ `guix-devel` if Codeberg is inaccessible for any reason and for
+ anyone.
- Interaction on individual issues that were opened via Debbugs before
this deadline will continue on Debbugs for as long as needed, *via*
`NNN <at> debbugs.gnu.org`.
@@ -410,8 +414,8 @@ process](https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Bra
Note that 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. We will disable it to
-avoid mistakes.
+button nor to enable auto-merge on build success. We will disable it
+to avoid mistakes. Manual merge is supported by Forgejo.
If and when the project migrates, we will incrementally adjust our
workflow to ensure it scales better.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 14 Apr 2025 20:46:02 GMT)
Full text and
rfc822 format available.
Message #407 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Liliana,
Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
> In "Detailed Design > User Interfaces", we do talk about dedicated
> Forgejo clients and nice pull request tricks, but an important user
> interface I think is missing is a (preferably unauthenticated, but
> moderated) way of discussing patches/merge requests. Reading until the
> end of the document, this appears to be acknowledged as an open issue,
> "a step back compared to the email-based workflow" – but let's put
> aside the need for authentication and focus on tools. We give fj.el as
> one tool that can accomplish this (though online and not offline like
> email), but it seems we don't have any other; or rather that they are
> only useful for Codeberg/Forgejo and nothing else. Is there any more
> generic tool (besides a browser, I guess) that one can incidentally use
> to also look at discussions on Codeberg?
Besides fj.el (and possibly Magit-Forge—someone mentioned privately
working on the Forgejo backend), the section list command-line tools.
These are all Forgejo clients so one needs a Codeberg account to use
them, at least until federation over ActivityPub is fully operational.
Noé proposed explicitly saying that patches over guix-devel or similar
will remain accepted for those who don’t want/cannot have a Codeberg
account; I think that’s a good idea.
> "Detailed Design > Repository Migration Path" quite notably does not
> talk about how long the Savannah repo will stay up.
That section reads:
The Savannah `guix.git` repository will become a mirror of the one at
Codeberg, with a script periodically updating it for **at least one
year** after the switch, as a way to ease migration to the new
repository for users.
Let me know if you think something should be added.
Thanks for your feedback!
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 14 Apr 2025 20:50:01 GMT)
Full text and
rfc822 format available.
Message #410 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Am Montag, dem 14.04.2025 um 22:45 +0200 schrieb Ludovic Courtès:
> Noé proposed explicitly saying that patches over guix-devel or
> similar will remain accepted for those who don’t want/cannot have a
> Codeberg account; I think that’s a good idea.
SGTM.
> > "Detailed Design > Repository Migration Path" quite notably does
> > not talk about how long the Savannah repo will stay up.
>
> That section reads:
>
> The Savannah `guix.git` repository will become a mirror of the one
> at Codeberg, with a script periodically updating it for **at least
> one year** after the switch, as a way to ease migration to the new
> repository for users.
>
> Let me know if you think something should be added.
My bad. Also SGTM.
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 15 Apr 2025 13:37:02 GMT)
Full text and
rfc822 format available.
Message #413 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
Thanks for the recall. I thinks it is worth having a later and careful
reading on the proposal before the end of this period, considering its
relevance. A few remarks (disclaimer: low profile contributor, here).
First and most important, to me what really matters here is making
life easy to reviewers, committers and infrastructure maintainers.
Contributors will most probably find their way, no matter what
interface we use. To be honest, I don’t feel like Guix suffers from
attracting contributors (see
https://debbugs.gnu.org/rrd/guix-patches.html), but rather from
keeping them motivated.
I noticed that the service I personally use the most, yhetil.org
(public-inbox instance) for navigating issues, bugs, patches and mail
lists, is not even mentioned in the GCD.
Then, latest improvements (since the writing of this GCD) to mumi
(thanks !) greatly simplify locating relevant information, both using
issues web and cli.
Finally, the whole proposal may be understood as a delegation on
Codeberg e.V. capabilities, which makes Guix dependent on a third
party. This might reveal with time as a good or a bad idea, only
future can tell. Assuming there are no significant issues from their
side, I’m curious about how Guix as a whole would handle a significant
raise on contributions (see graphs above). Which brings to my previous
first and most important statement.
All the best,
C.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 15 Apr 2025 15:13:02 GMT)
Full text and
rfc822 format available.
Message #416 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Cayetano,
Cayetano Santos <csantosb <at> inventati.org> writes:
> I noticed that the service I personally use the most, yhetil.org
> (public-inbox instance) for navigating issues, bugs, patches and mail
> lists, is not even mentioned in the GCD.
I don’t use it personally, but if you think of a place where it can be
mentioned (under “Motivation” I suppose), please feel free to propose a
patch.
> Finally, the whole proposal may be understood as a delegation on
> Codeberg e.V. capabilities, which makes Guix dependent on a third
> party. This might reveal with time as a good or a bad idea, only
> future can tell. Assuming there are no significant issues from their
> side, I’m curious about how Guix as a whole would handle a significant
> raise on contributions (see graphs above). Which brings to my previous
> first and most important statement.
This is acknowledged under “Drawbacks and Open Issues” (and it’s not a
new issue) but again, let me know if you think this could be clarified.
Thanks for your feedback!
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 16 Apr 2025 17:54:01 GMT)
Full text and
rfc822 format available.
Message #419 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
This looks like a great idea to me!
In light of guix potentially moving to codeberg, i've began adding
forgejo support to magit/forge, see
https://github.com/magit/ghub/pull/171 and
https://github.com/magit/forge/pull/770
It's still a WIP, so testers (and patches) welcome :)
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 17 Apr 2025 11:14:03 GMT)
Full text and
rfc822 format available.
Message #422 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Sun, 30 Mar 2025 at 21:10, Ludovic Courtès <ludo <at> gnu.org> wrote:
> I checked with people at Sourceware: they’re unable to to provide any
> guarantees around mirroring Guix at the moment, their Forgejo setup
> being experimental and with limited capacity (but they do hope to set up
> mirrors and federation eventually).
Thanks! Let approach them again in the near future. :-)
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 17 Apr 2025 11:14:03 GMT)
Full text and
rfc822 format available.
Message #425 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Wed, 16 Apr 2025 at 19:53, pinoaffe <pinoaffe <at> gmail.com> wrote:
> https://github.com/magit/ghub/pull/171 and
> https://github.com/magit/forge/pull/770
Bah news from upstream:
https://github.com/magit/forge/pull/770#issuecomment-2812213785
Feel free to share the separate repository, if you do.
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 17 Apr 2025 14:25:06 GMT)
Full text and
rfc822 format available.
Message #428 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello!
pinoaffe <pinoaffe <at> gmail.com> writes:
> In light of guix potentially moving to codeberg, i've began adding
> forgejo support to magit/forge, see
> https://github.com/magit/ghub/pull/171 and
> https://github.com/magit/forge/pull/770
Excellent, that’s the spirit! :-)
Too bad upstream’s response is negative (and self-centered), but it’s
OK: in the end, we can use your branch for the time being and switch to
the other one if/when Forgejo support lands.
Thank you!
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 17 Apr 2025 16:49:01 GMT)
Full text and
rfc822 format available.
Message #431 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
Minor comments. :-)
> As a reviewer, it is possible to pull references of pending pull
> requests by adding something like this to `.git/config`:
>
> ```
> [remote "pulls"]
> url = git <at> codeberg.org:org/guix-science/guix-science.git
> fetch = +refs/pull/*/head:refs/remotes/pulls/pr/*
> ```
>
> Running `git fetch pulls` then retrieves references to branches
> corresponding to all the pull requests.
I think it is misleading. Because this does not really « pull
references of pending PRs » but retrieve « all the PRs ». Therefore,
then one needs to manually find their way.
Well, although I’m sure Git scripts are around, it appears to me a good
opportunity to show how the API is easy to exploit. For instance, I
propose this:
--8<---------------cut here---------------start------------->8---
```
[alias]
prs-fetch="!f() { for pr in \
$(curl -s 'https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=open' \
| sed 's/,/\n/g' | grep number | cut -f2 -d':' | sed 's/,//g'); \
do git fetch -u origin pull/$pr/head:pull/$pr/head ;done \
}; echo Fetch open PRs; f"
prs-clean="!f() { for pr in \
$(curl -s 'https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=closed' \
| sed 's/,/\n/g' | grep number | cut -f2 -d':' | sed 's/,//g'); \
do git show-ref pull/$pr/head && \
git update-ref -d refs/heads/pull/$pr/head && git update-ref -d refs/pullreqs/$pr ;done \
}; echo Clean closed PRs; f"
prs="!git prs-fetch && git prs-clean"
```
--8<---------------cut here---------------end--------------->8---
Using this tip, as a reviewer, you synchronize the pending PRs. The
idea, similarly as the initial tip, is to have something minimal and
pave the way; and not come with some full-featured solution.
Or this appears to you too “complicated”, I would not provide any
’.git/config’ tips and just write in plain text the tips:
As a reviewer, it is possible to pull references of pending pull
requests by exploiting Forgejo API. For instance, querying the
list of [open pull
requests](https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=open)
allows to get still pending pull request numbers and then fetch
them using `git fetch -u origin pull/123/head:pull/123/head`,
where `123` reads the pull request number.
Last, it appears to me a good idea to also provide the tip for removing
closed pull requests; because it’s not straightforward – at least, it
was not obvious for me before I did my homework. :-)
> 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.
I understand the intent of the last sentence. Well, I would not close
the door this way. And I would remove the mention of “author” – it’s a
Consensus Document after all. :-) Nitpicking for the very last part.
However, considering the current load of Guix system administrators for
many other tasks and considering the constraints (availability) we
expect from such a service, self-hosting appears an unreasonable
workload at first. Self-hosting might be considered later once the
switch is well-established and all the mail-based workflow is curated.
Or something along these lines.
For the rest, I would word differently the Motivation section but I do
not have enough time neither energy; especially when I can live with the
current state. :-)
I’m happy that many points had been resolved or discussed.
To complement a chat we had IRL some weeks ago, let me point you the
public message [1] containing my 4 requirements and my potential query
for write-access suspension while I will not have a setup that fulfills
them.
Last but not least, I support the outcome of this GCD. I know it’s not
yet the Deliberation Period and this will not be taken into account.
But I will be offline for some weeks and it appears to me worth to
express my plain support.
Cheers,
simon
1: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Simon Tournier <zimon.toutoune <at> gmail.com>
Mon, 10 Mar 2025 13:30:44 +0100
id:87frjl6paj.fsf <at> gmail.com
https://issues.guix.gnu.org/76503
https://issues.guix.gnu.org/msgid/87frjl6paj.fsf <at> gmail.com
https://yhetil.org/guix/87frjl6paj.fsf <at> gmail.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 17 Apr 2025 19:50:12 GMT)
Full text and
rfc822 format available.
Message #434 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
Simon Tournier <zimon.toutoune <at> gmail.com> writes:
> I think it is misleading. Because this does not really « pull
> references of pending PRs » but retrieve « all the PRs ». Therefore,
> then one needs to manually find their way.
>
> Well, although I’m sure Git scripts are around, it appears to me a good
> opportunity to show how the API is easy to exploit. For instance, I
> propose this:
Thanks, I keep learning! How about this patch:
[Message part 2 (text/x-patch, inline)]
diff --git a/002-codeberg.md b/002-codeberg.md
index f931354..349cea5 100644
--- a/002-codeberg.md
+++ b/002-codeberg.md
@@ -344,7 +344,7 @@ git push origin HEAD:refs/for/main \
-o description='This updates the `hello` package."
```
-As a reviewer, it is possible to pull references of pending pull
+As a reviewer, it is possible to pull references of pull
requests by adding something like this to `.git/config`:
```
@@ -356,6 +356,17 @@ requests by adding something like this to `.git/config`:
Running `git fetch pulls` then retrieves references to branches
corresponding to all the pull requests.
+In addition, one may fetch the list of [open pull requests as
+JSON](https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=open),
+extract the number of a pull request of interest, and retrieve just this
+pull request with:
+
+```
+git fetch -u origin pull/123/head:pull/123/head
+```
+
+… where `123` is the pull request number.
+
## Teams
All the teams currently defined in `etc/teams.scm` will be reified as
[Message part 3 (text/plain, inline)]
> Last, it appears to me a good idea to also provide the tip for removing
> closed pull requests; because it’s not straightforward – at least, it
> was not obvious for me before I did my homework. :-)
That’s the ‘prs-clean’ alias you provided, right?
We can add it, but maybe it’s best to keep it for some developer
documentation? (I did not intend this part of the GCD to be
documentation; rather my goal was to give an overview of the available
interfaces.)
> I understand the intent of the last sentence. Well, I would not close
> the door this way. And I would remove the mention of “author” – it’s a
> Consensus Document after all. :-) Nitpicking for the very last part.
How about this smaller change:
[Message part 4 (text/x-patch, inline)]
@@ -485,9 +496,10 @@ 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
+However, at the moment, 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.
+Whether to self-host is something that could be revisited in the future.
As of this writing, Forgejo integration in Cuirass is functional but
partial (useful configuration options and hardening mechanisms are
[Message part 5 (text/plain, inline)]
?
> To complement a chat we had IRL some weeks ago, let me point you the
> public message [1] containing my 4 requirements and my potential query
> for write-access suspension while I will not have a setup that fulfills
> them.
Noted.
> Last but not least, I support the outcome of this GCD. I know it’s not
> yet the Deliberation Period and this will not be taken into account.
> But I will be offline for some weeks and it appears to me worth to
> express my plain support.
Thanks!
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 18 Apr 2025 06:32:02 GMT)
Full text and
rfc822 format available.
Message #437 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
Simon Tournier <zimon.toutoune <at> gmail.com> writes:
> Bah news from upstream:
> https://github.com/magit/forge/pull/770#issuecomment-2812213785
yup, kinda expected that tbh, and fair, since forge has a lot of
callback related technical debt and since tarsius is quite hesitant to
merge PRs
> Feel free to share the separate repository, if you do.
I'll probably set it up somewhere, either just as a repo of my own or at
https://github.com/mobid/gitea-forge
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 18 Apr 2025 09:10:04 GMT)
Full text and
rfc822 format available.
Message #440 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Thu, 17 Apr 2025 at 15:37, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> In light of guix potentially moving to codeberg, i've began adding
>> forgejo support to magit/forge, see
>> https://github.com/magit/ghub/pull/171 and
>> https://github.com/magit/forge/pull/770
Why not add these references:
[Magit-Forge](https://github.com/magit/forge/) is another Emacs
interface to forges, with Magit integration and support for working
off-line. However, Forgejo support is currently not supported upstream:
only `forge-browse` is supported (allowing users to open a browser on a
forge page). See [#770](https://github.com/magit/forge/pull/770).
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 18 Apr 2025 09:10:07 GMT)
Full text and
rfc822 format available.
Message #443 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Fri, 18 Apr 2025 at 08:30, pinoaffe <pinoaffe <at> gmail.com> wrote:
> I'll probably set it up somewhere, either just as a repo of my own or at
> https://github.com/mobid/gitea-forge
Cool! Thank you for this work, very helpful!
Once this somewhere is defined, IMHO, the best seems to drop it as a
comment in <https://github.com/magit/forge/pull/770>.
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 18 Apr 2025 09:10:10 GMT)
Full text and
rfc822 format available.
Message #446 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
Ah, I forgot: I would remove the mention to your usual login civodul and
instead use classical aubrey or blake or carol or dana or … :-)
On Thu, 17 Apr 2025 at 21:48, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> Last, it appears to me a good idea to also provide the tip for removing
>> closed pull requests; because it’s not straightforward – at least, it
>> was not obvious for me before I did my homework. :-)
>
> That’s the ‘prs-clean’ alias you provided, right?
Yes. To me, it was not obvious how to delete a local reference and
clean my local repository.
Somehow, I’m thinking to the future myself in some months or in 2 years:
I read the GCD for fun and profit and see oh cool, nice tip! Let run
“git fetch pulls”… and bang it downloads hundreds (or thousand?) of pull
requests containing thousands of commits. Oops! Now I need to clean
because I do not care about the hundreds of already merged pull
requests.
> We can add it, but maybe it’s best to keep it for some developer
> documentation? (I did not intend this part of the GCD to be
> documentation; rather my goal was to give an overview of the available
> interfaces.)
I agree. All the tips are only appetizers (make us want to cook) and
not some real meal (make us full).
My point reads:
1) The document provide a “lengthy“ example of fj.el. And we are not
all Emacs users.
2) The tip ’git fetch pulls’ is almost useless for a regular reviewer.
I mean in practice, it’s almost useless or bazooka. Who care to
download all the pull requests? Download even all the closed ones,
and then manually trigger or look for the ones of interest.
3) This tip ’git fetch pulls’ does not expose Forgejo API.
That’s why, IMHO, the tip ’git fetch pulls’ should be replaced either by
a plain paragraphs, or either by some short and minimal examples exposing
how to exploit the API, or either by a mix of both.
All in all, I propose this:
[p.patch (text/x-diff, inline)]
diff --git a/002-codeberg.md b/002-codeberg.md
index f931354..4a63c9f 100644
--- a/002-codeberg.md
+++ b/002-codeberg.md
@@ -348,13 +348,28 @@ As a reviewer, it is possible to pull references of pending pull
requests by adding something like this to `.git/config`:
```
-[remote "pulls"]
- url = git <at> codeberg.org:org/guix-science/guix-science.git
- fetch = +refs/pull/*/head:refs/remotes/pulls/pr/*
+[alias]
+ prs-fetch="!f() { for pr in \
+ $(curl -s 'https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=open' \
+ | sed 's/,/\\n/g' | grep number | cut -f2 -d':' | sed 's/,//g'); \
+ do echo Fetch: $pr; \
+ git fetch -f -u origin pull/$pr/head:pull/$pr/head ;done \
+ }; echo Fetch open PRs; f"
```
-Running `git fetch pulls` then retrieves references to branches
-corresponding to all the pull requests.
+Running `git prs-fetch` then retrieves references to branches
+corresponding to the pending pull requests.
+
+In addition, one may fetch the list of [closed pull requests as
+JSON](https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=closed),
+extract the number of a pull request of interest, and clean just this
+pull request with:
+
+```
+git update-ref -d refs/heads/pull/123/head
+```
+
+… where `123` is the pull request number.
## Teams
[Message part 3 (text/plain, inline)]
And the part ’git update-ref -d refs/pullreqs/123’ let as an
exercise. ;-) As said, it’s appetizer and not a complete documentation.
> -However the author thinks that, as it stands, Guix system administrators
> +However, at the moment, 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.
> +Whether to self-host is something that could be revisited in the future.
LGTM.
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 18 Apr 2025 13:07:04 GMT)
Full text and
rfc822 format available.
Message #449 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
Simon Tournier <zimon.toutoune <at> gmail.com> writes:
> Ah, I forgot: I would remove the mention to your usual login civodul and
> instead use classical aubrey or blake or carol or dana or … :-)
Good point.
> All in all, I propose this:
I adapted a slightly modified variant of this (using ‘jq’ for parsing)
with slightly modified text.
Thanks,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 18 Apr 2025 13:35:07 GMT)
Full text and
rfc822 format available.
Message #452 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Re,
On Fri, 18 Apr 2025 at 14:09, Ludovic Courtès <ludo <at> gnu.org> wrote:
> I adapted a slightly modified variant of this (using ‘jq’ for parsing)
> with slightly modified text.
LGTM. Thanks.
Re-reading all, the sections « User Interfaces » and « Continuous
Integration » capture well all the potential of the switch for a better
scaling, IMHO. Release of the cross-fingers to make it happen. :-)
Well, I have various annoyances (and concerns) but I’m sure these are
opportunities for a better. Again, I express my support.
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sat, 19 Apr 2025 07:25:03 GMT)
Full text and
rfc822 format available.
Message #455 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
>>> We could also set up our own thing; I’ll inquire to see if
>>> there are
>>> tools to do that for regular users.
>>
>> This is what I have in mind. Please note I’m not considering
>> this as
>> blocking or something we must have on Day-1.
>
> I did inquire on Mastodon: nobody came up with the ready-to-use
> tool to
> do backup. We could use the HTTP API, which exposes everything,
> to
> approximate it, but it’d be an approximation.
I have no personal experience with forgejo but was inspired to
research
this a little.
The gitea and forgejo client CLIs have an option called
"dump-repo"[1]
which appears relevant. The call requires a hostname and user
creds, so
I don't think it's specifically a server-side tool. Unfortunately,
it
tends to hammer the backend service with lots of API
calls[2]. Also,
judging from the code[3], it seems to have no concept of
incremental
operation: if the export fails for any reason (such as backend
timeout),
the client just deletes the partially-written archive.
More recently, Forgejo has been developing an on-disk format for
data
dumps to/from various kinds of forges. It's called F3 ("Friendly
Forge
Format") [4] and there exists a reference implementation[5] that
can
write the archives and talk to forgejo backends. Its project page
states
that the tool is designed for "mirroring", which suggests that
efficient
incremental syncs might be possible.
Maybe there's a good reason why the Codeberg experts you consulted
on
Mastodon didn't mention these tools, but I thought I would share
my
findings anyway.
Cheers!
Jason
P.S. Although my opinion as a lurker won't count for much, :) I
support
this GCD. Up-thread, some discussions on ease-of-use ("it takes N
steps
to do it this way, vs. N+2 steps that way") make the tacit
assumption
that the user handles every step correctly. But in the real world
where
users make mistakes, I see value in a webservice-based workflow
that
provides instantaneous and very visible feedback to users, as
compared
to an asynchronous workflow that's driven by emails and several
loosely-coupled services.
[1] https://forgejo.org/docs/latest/admin/command-line/#dump-repo
[2] https://codeberg.org/Codeberg/Community/issues/896
[3]
https://codeberg.org/forgejo/forgejo/src/commit/f3882d45533bbfce234b3f127a33c19b8a7165ca/cmd/dump_repo.go#L165
[4] https://code.forgejo.org/f3
[5] https://code.forgejo.org/f3/gof3
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sat, 19 Apr 2025 09:33:02 GMT)
Full text and
rfc822 format available.
Message #458 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Jason,
Jason Conroy <jconroy <at> tscripta.net> writes:
> The gitea and forgejo client CLIs have an option called "dump-repo"[1]
> which appears relevant. The call requires a hostname and user creds,
> so
> I don't think it's specifically a server-side tool. Unfortunately, it
> tends to hammer the backend service with lots of API calls[2]. Also,
> judging from the code[3], it seems to have no concept of incremental
> operation: if the export fails for any reason (such as backend
> timeout),
> the client just deletes the partially-written archive.
OK, sounds like brute-force approach.
> More recently, Forgejo has been developing an on-disk format for data
> dumps to/from various kinds of forges. It's called F3 ("Friendly Forge
> Format") [4] and there exists a reference implementation[5] that can
> write the archives and talk to forgejo backends. Its project page
> states
> that the tool is designed for "mirroring", which suggests that
> efficient
> incremental syncs might be possible.
Nice! It looks like the right kind of tool.
I wanted to give it a try so I ran “guix import go
code.forgejo.org/f3/gof3/v3”, tweaked the result (file attached), but
then I’m stuck with a build failure of
go-github-com-davidmz-go-pageant-1.0.2. If Go-savvy people are reading
this, your guidance is welcome!
> P.S. Although my opinion as a lurker won't count for much, :) I
> support
> this GCD. Up-thread, some discussions on ease-of-use ("it takes N
> steps
> to do it this way, vs. N+2 steps that way") make the tacit assumption
> that the user handles every step correctly. But in the real world
> where
> users make mistakes, I see value in a webservice-based workflow that
> provides instantaneous and very visible feedback to users, as compared
> to an asynchronous workflow that's driven by emails and several
> loosely-coupled services.
I agree. Thanks for sharing your views and your findings on
backup/mirroring!
Ludo’.
[f3.scm (text/plain, inline)]
(define-module (gnu packages f3)
#:use-module (guix)
#:use-module (guix git-download)
#:use-module (guix build-system go)
#:use-module (gnu packages golang)
#:use-module (gnu packages golang-build)
#:use-module (gnu packages golang-check)
#:use-module (gnu packages golang-xyz)
#:use-module (gnu packages golang-web)
#:use-module ((guix licenses) #:prefix license:))
(define-public go-github-com-42wim-httpsig
(package
(name "go-github-com-42wim-httpsig")
(version "1.2.2")
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/42wim/httpsig")
(commit (string-append "v" version))))
(file-name (git-file-name name version))
(sha256
(base32 "0r6q3g0ghccnvqsw7g3g18s710q8haq5vzpvhrb48vmbcj0pdyn8"))))
(build-system go-build-system)
(arguments
(list
#:import-path "github.com/42wim/httpsig"))
(propagated-inputs (list go-golang-org-x-crypto))
(home-page "https://github.com/42wim/httpsig")
(synopsis "httpsig")
(description
"This package implements HTTP request and response signing and verification.
Supports the major MAC and asymmetric key signature algorithms. It has several
safety restrictions: One, none of the widely known non-cryptographically safe
algorithms are permitted; Two, the RSA SHA256 algorithms must be available in
the binary (and it should, barring export restrictions); Finally, the library
assumes either the Authorizationn or Signature headers are to be set (but not
both).")
(license license:bsd-3)))
(define-public go-github-com-davidmz-go-pageant
(package
(name "go-github-com-davidmz-go-pageant")
(version "1.0.2")
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/davidmz/go-pageant")
(commit (string-append "v" version))))
(file-name (git-file-name name version))
(sha256
(base32 "0b333bnzi8wncakff7b890gg4md9pcbhs9fdv5bhh68r5pm2dz41"))))
(build-system go-build-system)
(arguments
(list
#:import-path "github.com/davidmz/go-pageant"))
(propagated-inputs (list go-golang-org-x-crypto))
(home-page "https://github.com/davidmz/go-pageant")
(synopsis #f)
(description
"Package pageant provides an interface to @code{PyTTY} pageant.exe utility. This
package is windows-only.")
(license license:expat)))
(define-public go-github-com-santhosh-tekuri-jsonschema
(package
(name "go-github-com-santhosh-tekuri-jsonschema")
(version "6.0.1")
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/santhosh-tekuri/jsonschema")
(commit (string-append "v" version))))
(file-name (git-file-name name version))
(sha256
(base32 "0681b359f30f9pkyi4rl1k0rq8w83mn25n323l4lis61f2d2kizy"))))
(build-system go-build-system)
(arguments
(list
#:import-path "github.com/santhosh-tekuri/jsonschema/v6"
#:unpack-path "github.com/santhosh-tekuri/jsonschema"))
(propagated-inputs (list go-golang-org-x-text
go-github-com-dlclark-regexp2))
(home-page "https://github.com/santhosh-tekuri/jsonschema")
(synopsis "jsonschema v6.0.0")
(description
"see @@url{https://pkg.go.dev/github.com/santhosh-tekuri/jsonschema/v6,godoc} for
examples.")
(license license:asl2.0)))
(define-public go-gitlab-com-gitlab-org-api-client-go
(package
(name "go-gitlab-com-gitlab-org-api-client-go")
(version "0.127.0")
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://gitlab.com/gitlab-org/api/client-go.git")
(commit (string-append "v" version))))
(file-name (git-file-name name version))
(sha256
(base32 "1bhk18sazvgpii5ahpi9jn94pgy5kqw3qgsw1wbqfg04vjs4g4cf"))))
(build-system go-build-system)
(arguments
(list
#:go go-1.22
#:import-path "gitlab.com/gitlab-org/api/client-go"))
(propagated-inputs (list go-golang-org-x-time
go-golang-org-x-oauth2
go-go-uber-org-mock
go-github-com-stretchr-testify
go-github-com-hashicorp-go-retryablehttp
go-github-com-hashicorp-go-cleanhttp
go-github-com-google-go-querystring))
(home-page "https://gitlab.com/gitlab-org/api/client-go")
(synopsis "GitLab client-go (former")
(description "Copyright 2022, Daniela Filipe Bento.")
(license license:asl2.0)))
(define-public go-code-forgejo-org-f3-gof3
(package
(name "go-code-forgejo-org-f3-gof3")
(version "3.10.7")
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://code.forgejo.org/f3/gof3.git")
(commit (string-append "v" version))))
(file-name (git-file-name name version))
(sha256
(base32 "031hq66diwjiphdghcwm4fhlfmwbnxa1zsc4ccyhsgxn7c3svqzh"))))
(build-system go-build-system)
(arguments
(list
;; #:go go-1.24
#:import-path "code.forgejo.org/f3/gof3/v3"
#:unpack-path "code.forgejo.org/f3/gof3"))
(propagated-inputs (list go-golang-org-x-crypto
go-gitlab-com-gitlab-org-api-client-go
go-github-com-urfave-cli-v2
go-github-com-stretchr-testify
go-github-com-santhosh-tekuri-jsonschema
go-github-com-hashicorp-go-version
go-github-com-google-go-cmp
go-github-com-davidmz-go-pageant
go-github-com-42wim-httpsig))
(home-page "https://code.forgejo.org/f3/gof3")
(synopsis "gof3")
(description
"As a CLI or as a library, @code{GoF3} provides a single operation: mirroring.
The origin and destination are designated by the URL of a forge and a path to
the resource. For instance, @@code{mirror --from-type forgejo --from
https://code.forgejo.org/forgejo/lxc-helpers --to-type F3 --to /some/directory}
will mirror a project in a local directory using the F3 format.")
(license license:expat)))
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 09:12:01 GMT)
Full text and
rfc822 format available.
Message #461 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Guix,
It’s been two months since we started discussing GCD 002, entitled
“Migrating repositories, issues, and patches to Codeberg”. Its final
version is attached below.
In accordance with the GCD process, team members have until May 6th to
participate in deliberation by sending one of the following replies
(quoting the GCD process):
- “I support”, meaning that one supports the proposal;
- “I accept”, meaning that one consents to the implementation of the
proposal;
- “I disapprove”, meaning that one opposes the implementation of the
proposal. A team member sending this reply should have made constructive
comments during the discussion period.
Thanks in advance,
Ludo’.
[002-codeberg.md (text/plain, inline)]
title: Migrating repositories, issues, and patches to Codeberg
id: 002
status: submitted
discussion: https://issues.guix.gnu.org/76503
authors: Ludovic Courtès
sponsors: Tobias Geerinckx-Rice, Ricardo Wurmus
date-submitted: 2025-02-23
date: 2025-02-23
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later
---
# 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,
an integrated forge with a Web interface that is 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 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. Such a system is necessarily
more *complex* at first glance than the email-based tools we have but
(1) the increase in complexity is reasonable once we consider the
incidental complexity of the existing services, as mentioned above, and
(2) we think the added usage benefits outweigh this increase in
complexity.
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.
Currently, [committers in the “guix” group on
Savannah](https://savannah.gnu.org/project/memberlist.php?group=guix)
have write access to [all the repositories of that
group](https://savannah.gnu.org/git/?group=guix). Since Codeberg allows
for per-repository rules, we propose the following rules to determine
who can access each repository:
- Committers to *several* of the repositories as well as people marked
as [“group admins” on
Savannah](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 in the `.guix-authorizations` file of Guix can request
membership of the https://codeberg.org/guix/guix repository once it
is created.
- Committers to one of the other repositories can request membership
of that repository.
The [“Commit
Rights”](https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html)
section of the manual will be extended 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 to https://codeberg.org/guix.
For Guix itself, we would decide on a **flag day** 14 days after
acceptance of this GCD at the earliest, and 30 days at the latest. On
that day, the official URL of the Guix repository would become
https://codeberg.org/guix/guix.git (this flag day is *only* about the
canonical repository; see the next section for bug reports and patch
tracking.)
After this switch, committers will have to push exclusively to
https://codeberg.org/guix/guix.git.
The Savannah `guix.git` repository will become a mirror of the one at
Codeberg, with a script periodically updating it for **at least one
year** after the switch, as a way to ease migration to the new
repository for users. Other repositories would be deleted from Savannah
once migrated, to avoid confusion.
A commit will reflect the change of Guix’s repository URL 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,
in particular in the manual.
To ease this migration and possibly future migration, we may add a new
`git.guix.gnu.org` DNS entry with HTTP redirects to
`git.savannah.gnu.org` (before migration) and `codeberg.org` (after
migration); a [patch](https://issues.guix.gnu.org/76296) implementing
this has been submitted. The `%default-channel-url` variable would
refer to `https://git.guix.gnu.org/guix.git`.
Following this commit, an entry in `etc/news.scm` would explain the
migration, accompanied by a blog post on
<https://guix.gnu.org/en/blog/>. See [this entry in
Guix-Science](https://codeberg.org/guix-science/guix-science/commit/fd1b2dacd8d37c9d1939f9dc5a5b74256171ccbd)
for an example.
## 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.
We propose a gradual migration process, where both systems would be used
simultaneously for several months:
- 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.
- Until **December 31st, 2025**, bug reports and patches will be accepted both by
email (`bug-guix` and `guix-patches`) and on Codeberg (issues and
pull requests); documentation will encourage people to choose
Codeberg, but contributors will keep paying attention to both
systems.
- Soon after **January 1st, 2026**, 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 to
open *new* issues will not get through anymore.
- To better serve those for whom Codeberg is inaccessible,
occasionally patches sent by email to `guix-devel` will be accepted.
- Interaction on individual issues that were opened via Debbugs before
this deadline will continue on Debbugs for as long as needed, *via*
`NNN <at> debbugs.gnu.org`.
- The switchover will be advertised before it takes place with a post
to `info-guix <at> gnu.org`, to `guix-devel <at> gnu.org`, as well as through
a blog post.
- The “Contributing” section of the manual will be updated accordingly
at that time.
## User Interfaces
For many contributors, a strength of the email-based workflow is that it
works out of the browser, possibly offline; we want to preserve that
comfort as much as possible.
Everything that can be done through Forgejo’s web interface can be done
*via* its [HTTP
interface](https://forgejo.org/docs/latest/user/api-usage/). This has
given rise to several Emacs and command-line interfaces that existing
contributors may find convenient.
[forgejo-cli](https://codeberg.org/Cyborus/forgejo-cli/) and
[codeberg-cli](https://codeberg.org/Aviac/codeberg-cli) provide rather
comprehensive command-line interfaces, as [reported by
Efraim](https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00057.html).
[fj.el](https://codeberg.org/martianh/fj.el/) is an Emacs interface
similar to `mastodon.el` that lets you view and comment on issues and
pull requests, list repositories, view notifications, and so on. It
does not support off-line access. It can be set up with something like:
```lisp
(with-eval-after-load 'fj
(setq fj-host "https://codeberg.org")
(setq fj-user "charlie")
(setq fj-token
(funcall (plist-get
(car
(auth-source-search :host "codeberg.org/api/v1"
:user fj-user
:type 'netrc))
:secret))))
```
… and a line like this one to `~/.authinfo.gpg`:
```
machine codeberg.org/api/v1 login charlie password TOKEN
```
… where `TOKEN` is the [token obtained from
Codeberg](https://docs.codeberg.org/advanced/access-token/).
[Magit-Forge](https://github.com/magit/forge/) is another Emacs
interface to forges, with Magit integration and support for working
off-line. However, Forgejo support is currently next to nonexistent:
only `forge-browse` is supported (allowing users to open a browser on a
forge page).
Besides these interfaces, there is a couple of tricks that can simplify
the life of contributors and reviewers, out of the browser.
As a contributor, you can create pull requests without first creating a
fork and then a merge request thanks to the [AGit
workflow](https://forgejo.org/docs/latest/user/agit-support/). This
works by passing `git push` the relevant *options*, as in this example:
```
git push origin HEAD:refs/for/main \
-o topic="update-hello" \
-o title="gnu: hello: Update to 42." \
-o description='This updates the `hello` package."
```
As a reviewer, it is possible to pull references of pull
requests by adding something like this to `.git/config`:
```
[remote "pulls"]
url = git <at> codeberg.org:org/guix-science/guix-science.git
fetch = +refs/pull/*/head:refs/remotes/pulls/pr/*
```
Running `git fetch pulls` then retrieves references to branches
corresponding to _all_ the pull requests.
In addition, one may fetch the list of [open pull requests as
JSON](https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=open),
extract the number of a pull request of interest, and retrieve just this
pull request with:
```
git fetch -u origin pull/123/head:pull/123/head
```
… where `123` is the pull request number. The `.git/config` snippet
below combines these to define an alias to fetch branches for open pull
requests (it requires `wget` and `jq`):
```
[alias]
fetch-open-pull-requests="!for pr in \
$(wget -qO - 'https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=open' \
| jq '.[] | .number'); \
do \
echo Fetching PR $pr...; \
git fetch -f -u codeberg pull/$pr/head:pull/$pr/head; \
done" \
```
It allows you to run `git fetch-open-pull-requests` to retrieve
references for open pull requests only (it assumes the remote is called
`codeberg` and the project is `guix-science/guix-science`; adapt to your
needs!).
Last, one may similarly fetch the list of [closed pull
requests](https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=closed),
extract the number of a pull request of interest, and clean just this
pull request with:
```
git update-ref -d refs/heads/pull/123/head
```
… where `123` is the pull request number.
## 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).
Note that 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. We will disable it
to avoid mistakes. Manual merge is supported by Forgejo.
If and when the project migrates, we will incrementally adjust our
workflow to ensure it scales better.
## 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.
First, everyone will have to create an account and accept [Codeberg’s
Terms of
Use](https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md)
before they can contribute, which can be seen as a step back compared to
the email-based workflow.
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, by setting a joint team to
monitor resource consumption induced by Guix and discuss any issues
encountered by either parties proactively, or by [joining
it](https://join.codeberg.org/) as an active member with voting rights.
Backup (for issues and discussions in particular) remains an open issue.
We could set up a Forgejo instance for this purpose or find an existing
one willing to mirror the project.
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, at the moment, 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.
Whether to self-host is something that could be revisited in the future.
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.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 09:29:03 GMT)
Full text and
rfc822 format available.
Message #464 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
I support.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 09:30:01 GMT)
Full text and
rfc822 format available.
Message #467 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
>
I support.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 11:24:04 GMT)
Full text and
rfc822 format available.
Message #470 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On Wed, 23 Apr 2025 17:10:50 +0800,
Ludovic Courtès wrote:
>
> [1 <multipart/mixed (7bit)>]
> [1.1 <text/plain; utf-8 (quoted-printable)>]
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
I accept.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 11:43:04 GMT)
Full text and
rfc822 format available.
Message #473 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2025-04-23 11:10, Ludovic Courtès wrote:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
>
> title: Migrating repositories, issues, and patches to Codeberg
> id: 002
> status: submitted
> discussion: https://issues.guix.gnu.org/76503
> authors: Ludovic Courtès
> sponsors: Tobias Geerinckx-Rice, Ricardo Wurmus
> date-submitted: 2025-02-23
> date: 2025-02-23
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later
I support
--
Best regards,
Andrew Tropin
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 13:02:02 GMT)
Full text and
rfc822 format available.
Message #476 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
Ludovic Courtès <ludo <at> gnu.org> writes:
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
I support.
Regards,
--
Nicolas Goaziou
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 13:52:02 GMT)
Full text and
rfc822 format available.
Message #479 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On Wed, Apr 23, 2025 at 5:11 AM Ludovic Courtès <ludo <at> gnu.org> wrote:
>
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
I support.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 14:03:02 GMT)
Full text and
rfc822 format available.
Message #482 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I support.
On 23 April 2025 09:10:50 GMT, "Ludovic Courtès" <ludo <at> gnu.org> wrote:
>Hello Guix,
>
>It’s been two months since we started discussing GCD 002, entitled
>“Migrating repositories, issues, and patches to Codeberg”. Its final
>version is attached below.
>
>In accordance with the GCD process, team members have until May 6th to
>participate in deliberation by sending one of the following replies
>(quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
>
>Thanks in advance,
>Ludo’.
>
Divya Ranjan, Mathematics, Philosophy and Libre Software
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 15:49:09 GMT)
Full text and
rfc822 format available.
Message #485 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
I accept.
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 19:21:03 GMT)
Full text and
rfc822 format available.
Message #488 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2025-04-23, Ludovic Courtès wrote:
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
I support.
live well,
vagrant
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 19:33:02 GMT)
Full text and
rfc822 format available.
Message #491 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On 2025-04-23 11:10, Ludovic Courtès wrote:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
>
I accept
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 21:28:03 GMT)
Full text and
rfc822 format available.
Message #494 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On 2025-04-23 11:10, Ludovic Courtès wrote:
>Hello Guix,
>
>It’s been two months since we started discussing GCD 002, entitled
>“Migrating repositories, issues, and patches to Codeberg”. Its final
>version is attached below.
>
>In accordance with the GCD process, team members have until May 6th to
>participate in deliberation by sending one of the following replies
>(quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made
constructive
> comments during the discussion period.
>
>Thanks in advance,
>Ludo’.
>
I support
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 23 Apr 2025 22:40:02 GMT)
Full text and
rfc822 format available.
Message #497 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 23 Apr, Ludovic Courtès wrote:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
(...)
I support.
Steve / Futurile
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 24 Apr 2025 08:45:01 GMT)
Full text and
rfc822 format available.
Message #500 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I support.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 24 Apr 2025 08:46:01 GMT)
Full text and
rfc822 format available.
Message #503 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 23 Apr, Ludovic Courtès wrote:
> > Hello Guix,
> >
> > It’s been two months since we started discussing GCD 002, entitled
> > “Migrating repositories, issues, and patches to Codeberg”. Its final
> > version is attached below.
> >
> > In accordance with the GCD process, team members have until May 6th to
> > participate in deliberation by sending one of the following replies
> > (quoting the GCD process):
> >
> > - “I support”, meaning that one supports the proposal;
> > - “I accept”, meaning that one consents to the implementation of the
> > proposal;
> > - “I disapprove”, meaning that one opposes the implementation of the
> > proposal. A team member sending this reply should have made constructive
> > comments during the discussion period.
> (...)
I support.
Please excuse me, if team members here refer to committers only.
--
Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0
"If I destroy you, what business is it of yours ?" (Dark Forest, Liu Cixin)
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 24 Apr 2025 08:57:02 GMT)
Full text and
rfc822 format available.
Message #506 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ashish SHUKLA via Guix-patches via <guix-patches <at> gnu.org> writes:
>
> Please excuse me, if team members here refer to committers only.
The members here refer to the people defined in etc/teams.scm
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 24 Apr 2025 08:57:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 24 Apr 2025 14:59:02 GMT)
Full text and
rfc822 format available.
Message #512 received at 76503 <at> debbugs.gnu.org (full text, mbox):
qua 23 abr 2025 às 11:10:50 (1745417450), ludo <at> gnu.org enviou:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
I support.
Thanks
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 25 Apr 2025 08:15:02 GMT)
Full text and
rfc822 format available.
Message #515 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> title: Migrating repositories, issues, and patches to Codeberg
> id: 002
> status: submitted
> discussion: https://issues.guix.gnu.org/76503
> authors: Ludovic Courtès
> sponsors: Tobias Geerinckx-Rice, Ricardo Wurmus
> date-submitted: 2025-02-23
> date: 2025-02-23
> SPDX-License-Identifier: CC-BY-SA-4.0 OR
> GFDL-1.3-no-invariants-or-later
I support.
--
Ricardo (r-team)
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 25 Apr 2025 12:24:02 GMT)
Full text and
rfc822 format available.
Message #518 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
>
> title: Migrating repositories, issues, and patches to Codeberg
I support, thanks.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 25 Apr 2025 18:32:01 GMT)
Full text and
rfc822 format available.
Message #521 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I support
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
>
> title: Migrating repositories, issues, and patches to Codeberg
> id: 002
> status: submitted
> discussion: https://issues.guix.gnu.org/76503
> authors: Ludovic Courtès
> sponsors: Tobias Geerinckx-Rice, Ricardo Wurmus
> date-submitted: 2025-02-23
> date: 2025-02-23
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later
> ---
>
> # 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,
> an integrated forge with a Web interface that is 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 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. Such a system is necessarily
> more *complex* at first glance than the email-based tools we have but
> (1) the increase in complexity is reasonable once we consider the
> incidental complexity of the existing services, as mentioned above, and
> (2) we think the added usage benefits outweigh this increase in
> complexity.
>
> 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.
>
> Currently, [committers in the “guix” group on
> Savannah](https://savannah.gnu.org/project/memberlist.php?group=guix)
> have write access to [all the repositories of that
> group](https://savannah.gnu.org/git/?group=guix). Since Codeberg allows
> for per-repository rules, we propose the following rules to determine
> who can access each repository:
>
> - Committers to *several* of the repositories as well as people marked
> as [“group admins” on
> Savannah](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 in the `.guix-authorizations` file of Guix can request
> membership of the https://codeberg.org/guix/guix repository once it
> is created.
> - Committers to one of the other repositories can request membership
> of that repository.
>
> The [“Commit
> Rights”](https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html)
> section of the manual will be extended 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 to https://codeberg.org/guix.
>
> For Guix itself, we would decide on a **flag day** 14 days after
> acceptance of this GCD at the earliest, and 30 days at the latest. On
> that day, the official URL of the Guix repository would become
> https://codeberg.org/guix/guix.git (this flag day is *only* about the
> canonical repository; see the next section for bug reports and patch
> tracking.)
>
> After this switch, committers will have to push exclusively to
> https://codeberg.org/guix/guix.git.
> The Savannah `guix.git` repository will become a mirror of the one at
> Codeberg, with a script periodically updating it for **at least one
> year** after the switch, as a way to ease migration to the new
> repository for users. Other repositories would be deleted from Savannah
> once migrated, to avoid confusion.
>
> A commit will reflect the change of Guix’s repository URL 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,
> in particular in the manual.
>
> To ease this migration and possibly future migration, we may add a new
> `git.guix.gnu.org` DNS entry with HTTP redirects to
> `git.savannah.gnu.org` (before migration) and `codeberg.org` (after
> migration); a [patch](https://issues.guix.gnu.org/76296) implementing
> this has been submitted. The `%default-channel-url` variable would
> refer to `https://git.guix.gnu.org/guix.git`.
>
> Following this commit, an entry in `etc/news.scm` would explain the
> migration, accompanied by a blog post on
> <https://guix.gnu.org/en/blog/>. See [this entry in
> Guix-Science](https://codeberg.org/guix-science/guix-science/commit/fd1b2dacd8d37c9d1939f9dc5a5b74256171ccbd)
> for an example.
>
> ## 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.
>
> We propose a gradual migration process, where both systems would be used
> simultaneously for several months:
>
> - 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.
> - Until **December 31st, 2025**, bug reports and patches will be accepted both by
> email (`bug-guix` and `guix-patches`) and on Codeberg (issues and
> pull requests); documentation will encourage people to choose
> Codeberg, but contributors will keep paying attention to both
> systems.
> - Soon after **January 1st, 2026**, 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 to
> open *new* issues will not get through anymore.
> - To better serve those for whom Codeberg is inaccessible,
> occasionally patches sent by email to `guix-devel` will be accepted.
> - Interaction on individual issues that were opened via Debbugs before
> this deadline will continue on Debbugs for as long as needed, *via*
> `NNN <at> debbugs.gnu.org`.
> - The switchover will be advertised before it takes place with a post
> to `info-guix <at> gnu.org`, to `guix-devel <at> gnu.org`, as well as through
> a blog post.
> - The “Contributing” section of the manual will be updated accordingly
> at that time.
>
> ## User Interfaces
>
> For many contributors, a strength of the email-based workflow is that it
> works out of the browser, possibly offline; we want to preserve that
> comfort as much as possible.
>
> Everything that can be done through Forgejo’s web interface can be done
> *via* its [HTTP
> interface](https://forgejo.org/docs/latest/user/api-usage/). This has
> given rise to several Emacs and command-line interfaces that existing
> contributors may find convenient.
>
> [forgejo-cli](https://codeberg.org/Cyborus/forgejo-cli/) and
> [codeberg-cli](https://codeberg.org/Aviac/codeberg-cli) provide rather
> comprehensive command-line interfaces, as [reported by
> Efraim](https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00057.html).
>
> [fj.el](https://codeberg.org/martianh/fj.el/) is an Emacs interface
> similar to `mastodon.el` that lets you view and comment on issues and
> pull requests, list repositories, view notifications, and so on. It
> does not support off-line access. It can be set up with something like:
>
> ```lisp
> (with-eval-after-load 'fj
> (setq fj-host "https://codeberg.org")
> (setq fj-user "charlie")
> (setq fj-token
> (funcall (plist-get
> (car
> (auth-source-search :host "codeberg.org/api/v1"
> :user fj-user
> :type 'netrc))
> :secret))))
> ```
>
> … and a line like this one to `~/.authinfo.gpg`:
>
> ```
> machine codeberg.org/api/v1 login charlie password TOKEN
> ```
>
> … where `TOKEN` is the [token obtained from
> Codeberg](https://docs.codeberg.org/advanced/access-token/).
>
> [Magit-Forge](https://github.com/magit/forge/) is another Emacs
> interface to forges, with Magit integration and support for working
> off-line. However, Forgejo support is currently next to nonexistent:
> only `forge-browse` is supported (allowing users to open a browser on a
> forge page).
>
> Besides these interfaces, there is a couple of tricks that can simplify
> the life of contributors and reviewers, out of the browser.
>
> As a contributor, you can create pull requests without first creating a
> fork and then a merge request thanks to the [AGit
> workflow](https://forgejo.org/docs/latest/user/agit-support/). This
> works by passing `git push` the relevant *options*, as in this example:
>
> ```
> git push origin HEAD:refs/for/main \
> -o topic="update-hello" \
> -o title="gnu: hello: Update to 42." \
> -o description='This updates the `hello` package."
> ```
>
> As a reviewer, it is possible to pull references of pull
> requests by adding something like this to `.git/config`:
>
> ```
> [remote "pulls"]
> url = git <at> codeberg.org:org/guix-science/guix-science.git
> fetch = +refs/pull/*/head:refs/remotes/pulls/pr/*
> ```
>
> Running `git fetch pulls` then retrieves references to branches
> corresponding to _all_ the pull requests.
>
> In addition, one may fetch the list of [open pull requests as
> JSON](https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=open),
> extract the number of a pull request of interest, and retrieve just this
> pull request with:
>
> ```
> git fetch -u origin pull/123/head:pull/123/head
> ```
>
> … where `123` is the pull request number. The `.git/config` snippet
> below combines these to define an alias to fetch branches for open pull
> requests (it requires `wget` and `jq`):
>
> ```
> [alias]
> fetch-open-pull-requests="!for pr in \
> $(wget -qO - 'https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=open' \
> | jq '.[] | .number'); \
> do \
> echo Fetching PR $pr...; \
> git fetch -f -u codeberg pull/$pr/head:pull/$pr/head; \
> done" \
> ```
>
> It allows you to run `git fetch-open-pull-requests` to retrieve
> references for open pull requests only (it assumes the remote is called
> `codeberg` and the project is `guix-science/guix-science`; adapt to your
> needs!).
>
> Last, one may similarly fetch the list of [closed pull
> requests](https://codeberg.org/api/v1/repos/guix-science/guix-science/pulls?state=closed),
> extract the number of a pull request of interest, and clean just this
> pull request with:
>
> ```
> git update-ref -d refs/heads/pull/123/head
> ```
>
> … where `123` is the pull request number.
>
> ## 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).
>
> Note that 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. We will disable it
> to avoid mistakes. Manual merge is supported by Forgejo.
>
> If and when the project migrates, we will incrementally adjust our
> workflow to ensure it scales better.
>
> ## 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.
>
> First, everyone will have to create an account and accept [Codeberg’s
> Terms of
> Use](https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md)
> before they can contribute, which can be seen as a step back compared to
> the email-based workflow.
>
> 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, by setting a joint team to
> monitor resource consumption induced by Guix and discuss any issues
> encountered by either parties proactively, or by [joining
> it](https://join.codeberg.org/) as an active member with voting rights.
>
> Backup (for issues and discussions in particular) remains an open issue.
> We could set up a Forgejo instance for this purpose or find an existing
> one willing to mirror the project.
>
> 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, at the moment, 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.
> Whether to self-host is something that could be revisited in the future.
>
> 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.
--
Trev : 0FB7 D06B 4A2A F07E AD5B 1169 183B 6306 8AA1 D206
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 25 Apr 2025 21:19:01 GMT)
Full text and
rfc822 format available.
Message #524 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I support.
On Wed, Apr 23, 2025, at 05:10, Ludovic Courtès wrote:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
>
>
> Attachments:
> * 002-codeberg.md
> * signature.asc
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 25 Apr 2025 21:36:01 GMT)
Full text and
rfc822 format available.
Message #527 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> […]
> ## 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.
> […]
I support.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sat, 26 Apr 2025 08:17:02 GMT)
Full text and
rfc822 format available.
Message #530 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I accept.
On Wed Apr 23, 2025 at 11:10 AM CEST, Ludovic Courtès wrote:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sat, 26 Apr 2025 16:49:01 GMT)
Full text and
rfc822 format available.
Message #533 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Wed, 2025-04-23 at 11:10 +0200, Ludovic Courtès wrote:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th
> to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of
> the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of
> the
> proposal. A team member sending this reply should have made
> constructive
> comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
>
I support.
Regards,
Ashvith
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 27 Apr 2025 12:08:02 GMT)
Full text and
rfc822 format available.
Message #536 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I support
On Wed, 23 Apr 2025 at 11:11, Ludovic Courtès <ludo <at> gnu.org> wrote:
>
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
>
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 27 Apr 2025 12:17:02 GMT)
Full text and
rfc822 format available.
Message #539 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I support,
Thanks for taking actions in that direction.
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5
… наш разум - превосходная объяснительная машина которая способна найти
смысл почти в чем угодно, истолковать любой феномен, но совершенно не в
состоянии принять мысль о непредсказуемости.
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 27 Apr 2025 12:53:03 GMT)
Full text and
rfc822 format available.
Message #542 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès writes:
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
I accept.
Greetings,
Janneke
--
Janneke Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 27 Apr 2025 13:01:01 GMT)
Full text and
rfc822 format available.
Message #545 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I support
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sun, 27 Apr 2025 23:23:03 GMT)
Full text and
rfc822 format available.
Message #548 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002,
> entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its
> final
> version is attached below.
>
> In accordance with the GCD process, team members have until May
> 6th to
> participate in deliberation by sending one of the following
> replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation
> of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation
> of the
> proposal. A team member sending this reply should have made
> constructive
> comments during the discussion period.
I support.
-- Ian
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 28 Apr 2025 04:13:04 GMT)
Full text and
rfc822 format available.
Message #551 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I support.
--
Thanks,
Maxim
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 28 Apr 2025 04:13:06 GMT)
Full text and
rfc822 format available.
Message #554 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I accept.
--
Thanks,
Maxim
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 28 Apr 2025 12:22:03 GMT)
Full text and
rfc822 format available.
Message #557 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> skribis:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
I accept.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 30 Apr 2025 23:12:02 GMT)
Full text and
rfc822 format available.
Message #560 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I support
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 01 May 2025 02:01:01 GMT)
Full text and
rfc822 format available.
Message #563 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I accept.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 01 May 2025 09:40:01 GMT)
Full text and
rfc822 format available.
Message #566 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Le Wed, 23 Apr 2025 11:10:50 +0200,
Ludovic Courtès <ludo <at> gnu.org> a écrit :
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made
> constructive comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
>
I support.
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 01 May 2025 10:48:01 GMT)
Full text and
rfc822 format available.
Message #569 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I support
--
Efraim Flashner <efraim <at> 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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Thu, 01 May 2025 22:44:02 GMT)
Full text and
rfc822 format available.
Message #572 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I support.
-
Katherine
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 02 May 2025 11:22:02 GMT)
Full text and
rfc822 format available.
Message #575 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I (unsurprisingly) support.
Sent on the go. Excuse or enjoy my brevity.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Sat, 03 May 2025 13:37:02 GMT)
Full text and
rfc822 format available.
Message #578 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I accept.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 05 May 2025 15:21:02 GMT)
Full text and
rfc822 format available.
Message #581 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I support.
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 05 May 2025 18:38:02 GMT)
Full text and
rfc822 format available.
Message #584 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I support.
BTW, I already switched to Codeberg mirror in one of my Guix-based
GitHub CI actions to test it:
https://github.com/artyom-poptsov/SPARC/blob/master/.github/workflows/pdf.yaml
And it seems that it is way more stable than Savannah, I've yet to see
any problems with it since the migration.
Thanks,
- avp
--
Artyom "avp" Poptsov <poptsov.artyom <at> gmail.com>
Home page: https://memory-heap.org/~avp/
CADR Hackerspace co-founder: https://cadrspace.ru/
GPG: D0C2 EAC1 3310 822D 98DE B57C E9C5 A2D9 0898 A02F
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 05 May 2025 22:22:01 GMT)
Full text and
rfc822 format available.
Message #587 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> writes:
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
I accept.
I do see some advantages for some of the repositories on Savannah that
will have new associated features like issue and patch tracking by
moving to Codeberg, but since Guix does differ from typical software
projects in the nature of the "code" and contributions, I remain
concerned that conforming the guix.git repository and associated patch
tracking in to the Codeberg/Forgejo model might not be in the best long
term interests of the project and contributors.
While this document is in favour of using a hosted service, personally I
think there are benefits to self-hosting and the project controlling the
domain that users use for the Git repository. Maybe the latter is
achievable depending on how the "Detailed Design" is implemented.
In the short term, this move will mean that QA will require significant
changes to continue doing something similar to what it's doing now for
providing automated testing for patches. Of course QA has been
notoriously unreliable so this isn't a new thing, and there is a
commitment to setup Cuirass at ci.guix.gnu.org to process Forgejo Pull
requests, but I'm unsure if this will fill in for QA and this gap may be
unfilled for an extended period.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 07 May 2025 07:26:01 GMT)
Full text and
rfc822 format available.
Message #590 received at 76503 <at> debbugs.gnu.org (full text, mbox):
I support.
On 4/23/25 04:10, Ludovic Courtès wrote:
> Hello Guix,
>
> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”. Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
> proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
> proposal. A team member sending this reply should have made constructive
> comments during the discussion period.
>
> Thanks in advance,
> Ludo’.
>
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 07 May 2025 15:42:02 GMT)
Full text and
rfc822 format available.
Message #593 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi all,
I collated the results of the voting on GCD 002.
Voting by members:
- 49 people in the voting pool
- 33 votes in total
- 24 Support, 9 Accept
- 0 Disapprove
Declarations by observers (people not in teams):
- 7 total declarations
- 7 Support
- 0 Accept
- 0 Disapprove
Voting result:
- 67% (33 votes) voted to pass the GCD
- 0% disapproved
- 33% abstained by not voting
As more than 25% of members voted to pass, and there were no disapprovals this GCD is accepted as final and may now be implemented.
* Please check that I captured **your vote** correctly, the voting tally is here:
https://codeberg.org/futurile/guix-org/src/branch/master/gcd-voting-summary/gcd002-voting-record.rec
* Voting summary for this GCD is here:
https://codeberg.org/futurile/guix-org/src/branch/master/gcd-voting-summary/gcd002-voting-summary.md
Hope this is useful!
Steve / Futurile
On 23 Feb, Ludovic Courtès wrote:
> Hello Guix!
>
> This is the formal submission of “Migrating repositories, issues, and
> patches to Codeberg” (GCD 002), a preliminary draft of which I posted
> before the Guix Days⁰.
>
> In accordance with the GCD Process, discussion will end on April 23rd at
> the latest.
>
> I would like to remind everyone that you can try out Codeberg either by
> contributing to one of the Guix-Science repositories¹, or by reviewing
> or making a pull request for a trivial packaging change (and nothing
> more!) in my Guix clone at Codeberg:
>
> https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00313.html
>
> Please do try it especially if you feel reluctant or wonder what the
> workflow would be like.
>
> Ludo’.
>
> ⁰ https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00218.html
> ¹ https://codeberg.org/guix-science
>
> title: Migrating repositories, issues, and patches to Codeberg
> id: 002
> status: submitted
> discussion: https://issues.guix.gnu.org/<number assigned by issue tracker>
> authors: Ludovic Courtès
> sponsors: Tobias Geerinckx-Rice, Ricardo Wurmus
> date-submitted: 2025-02-23
> date: 2025-02-23
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later
> ---
>
> # 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. Such a system is necessarily
> more *complex* at first glance than the email-based tools we have but
> (1) the increase in complexity is reasonable once we consider the
> incidental complexity of the existing services, as mentioned above, and
> (2) we think the added usage benefits outweigh this increase in
> complexity.
>
> 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 to https://codeberg.org/guix.
>
> For Guix itself, we would decide on a **flag day** 14 days after
> acceptance of this GCD at the earliest, and 30 days at the latest. On
> that day, the official URL of the Guix repository would become
> https://codeberg.org/guix/guix.git. A commit would reflect that by
> updating:
>
> 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,
> in particular in the manual.
>
> To ease this migration and possibly future migration, we may add a new
> `git.guix.gnu.org` DNS entry with HTTP redirects to
> `git.savannah.gnu.org` (before migration) and `codeberg.org` (after
> migration); a [patch](https://issues.guix.gnu.org/76296) implementing
> this has been submitted. The `%default-channel-url` variable would
> refer to `https://git.guix.gnu.org/guix.git`.
>
> 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 for **at least one
> year** after the switch, as a way to ease migration to the new
> repository for users. Other repositories would be deleted from Savannah
> once migrated, to avoid confusion.
>
> ## 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 <at> debbugs.gnu.org`.
> - The switchover will be advertised before it takes place with a post
> to `info-guix <at> gnu.org`, to `guix-devel <at> gnu.org`, as well as through
> a blog post.
> - The “Contributing” section of the manual will be updated accordingly
> at that time.
>
> ## User Interfaces
>
> For many contributors, a strength of the email-based workflow is that it
> works out of the browser, possibly offline; we want to preserve that
> comfort as much as possible.
>
> Everything that can be done through Forgejo’s web interface can be done
> *via* its [HTTP
> interface](https://forgejo.org/docs/latest/user/api-usage/). This has
> given rise to several Emacs and command-line interfaces that existing
> contributors may find convenient.
>
> [forgejo-cli](https://codeberg.org/Cyborus/forgejo-cli/) and
> [codeberg-cli](https://codeberg.org/Aviac/codeberg-cli) provide rather
> comprehensive command-line interfaces, as [reported by
> Efraim](https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00057.html).
>
> [fj.el](https://codeberg.org/martianh/fj.el/) is an Emacs interface
> similar to `mastodon.el` that lets you view and comment on issues and
> pull requests, list repositories, view notifications, and so on. It
> does not support off-line access. It can be set up with something like:
>
> ```lisp
> (with-eval-after-load 'fj
> (setq fj-host "https://codeberg.org")
> (setq fj-user "civodul")
> (setq fj-token
> (funcall (plist-get
> (car
> (auth-source-search :host "codeberg.org/api/v1"
> :user fj-user
> :type 'netrc))
> :secret))))
> ```
>
> … and a line like this one to `~/.authinfo.gpg`:
>
> ```
> machine codeberg.org/api/v1 login civodul password TOKEN
> ```
>
> … where `TOKEN` is the [token obtained from
> Codeberg](https://docs.codeberg.org/advanced/access-token/).
>
> [Magit-Forge](https://github.com/magit/forge/) is another Emacs
> interface to forges, with Magit integration and support for working
> off-line. However, Forgejo support is currently next to nonexistent:
> only `forge-browse` is supported (allowing users to open a browser on a
> forge page).
>
> Besides these interfaces, there is a couple of tricks that can simplify
> the life of contributors and reviewers, out of the browser.
>
> As a contributor, you can create pull requests without first creating a
> fork and then a merge request thanks to the [AGit
> workflow](https://forgejo.org/docs/latest/user/agit-support/). This
> works by passing `git push` the relevant *options*, as in this example:
>
> ```
> git push origin HEAD:refs/for/main \
> -o topic="update-hello" \
> -o title="gnu: hello: Update to 42." \
> -o description='This updates the `hello` package."
> ```
>
> As a reviewer, it is possible to pull references of pending pull
> requests by adding something like this to `.git/config`:
>
> ```
> [remote "pulls"]
> url = git <at> codeberg.org:org/guix-science/guix-science.git
> fetch = +refs/pull/*/head:refs/remotes/pulls/pr/*
> ```
>
> Running `git fetch pulls` then retrieves references to branches
> corresponding to all the pull requests.
>
> ## 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).
>
> Note that 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.
>
> If and when the project migrates, we will incrementally adjust our
> workflow to ensure it scales better.
>
> ## 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.
>
> First, everyone will have to create an account and accept [Codeberg’s
> Terms of
> Use](https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md)
> before they can contribute, which can be seen as a step back compared to
> the email-based workflow.
>
> 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, by setting a joint team to
> monitor resource consumption induced by Guix and discuss any issues
> encountered by either parties proactively, or by [joining
> it](https://join.codeberg.org/) as an active member with voting rights.
>
> 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.
>
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Wed, 07 May 2025 16:21:01 GMT)
Full text and
rfc822 format available.
Message #596 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello,
Steve George <steve <at> futurile.net> writes:
> I collated the results of the voting on GCD 002.
[...]
> Voting result:
> - 67% (33 votes) voted to pass the GCD
> - 0% disapproved
> - 33% abstained by not voting
>
> As more than 25% of members voted to pass, and there were no disapprovals this GCD is accepted as final and may now be implemented.
This is good news. I’ll prepare a blog post to communicate more broadly
about the upcoming changes and start working on the items listed in the
GCD… with as many of you as possible I hope!
It’s going to be a process with many aspects necessitating fine-tuning.
Let’s not forget concerns raised by those who were less enthusiastic so
that this change is as inclusive as possible.
> * Please check that I captured **your vote** correctly, the voting tally is here:
>
> https://codeberg.org/futurile/guix-org/src/branch/master/gcd-voting-summary/gcd002-voting-record.rec
>
> * Voting summary for this GCD is here:
>
> https://codeberg.org/futurile/guix-org/src/branch/master/gcd-voting-summary/gcd002-voting-summary.md
>
> Hope this is useful!
Very! Thanks for capturing this information.
I think it would make sense to add it in a sub-directory of
guix-consensus-documents.git, and IMO does not require a change of
GCD 001 (though we could eventually propose to amend GCD 001 to
explicitly mention said sub-directory).
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 12 May 2025 13:52:02 GMT)
Full text and
rfc822 format available.
Message #599 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Steve,
Ludovic Courtès <ludo <at> gnu.org> writes:
> I think it would make sense to add it in a sub-directory of
> guix-consensus-documents.git, and IMO does not require a change of
> GCD 001 (though we could eventually propose to amend GCD 001 to
> explicitly mention said sub-directory).
I saw that you did that, thank you!
I would have two suggestions:
1. Renaming “voting-records” to “deliberation”.
2. In the ‘README’ and .rec files, change “Voting record” to
“Deliberation record”, and generally “Vote” to “Deliberation”.
This will be consistent with the terminology used in GCD 001 and also
dispel the impression that it all boils down to a vote: there is no vote
(and no campaign, no representatives, nothing like that), and I’d prefer
everyone in the community to focus on the discussion and improvements
that stem from it rather than on the final show of hands.
How does that sound? :-)
Thanks,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 12 May 2025 14:06:01 GMT)
Full text and
rfc822 format available.
Message #602 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On 12 May, Ludovic Courtès wrote:
> Hi Steve,
>
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
> > I think it would make sense to add it in a sub-directory of
> > guix-consensus-documents.git, and IMO does not require a change of
> > GCD 001 (though we could eventually propose to amend GCD 001 to
> > explicitly mention said sub-directory).
>
> I saw that you did that, thank you!
>
> I would have two suggestions:
>
> 1. Renaming “voting-records” to “deliberation”.
>
> 2. In the ‘README’ and .rec files, change “Voting record” to
> “Deliberation record”, and generally “Vote” to “Deliberation”.
>
> This will be consistent with the terminology used in GCD 001 and also
> dispel the impression that it all boils down to a vote: there is no vote
> (and no campaign, no representatives, nothing like that), and I’d prefer
> everyone in the community to focus on the discussion and improvements
> that stem from it rather than on the final show of hands.
>
> How does that sound? :-)
(...)
Both you and Simon [0] have brought this up, and I will change it if we want.
Note that 'Deliberate' means to "consider or discuss", and a person would "vote" at the end of a deliberation period to "to express your choice or opinion". That is the standard use in English. One doesn't keep a "Deliberation" as a record of choices (e.g. tally of votes). Also, to be explicit just because something is a "vote" doesn't imply that the it's "majority rule" on anything similar. I bring it up, because it's going to sounds odd to me as a native English speaker.
- https://dictionary.cambridge.org/dictionary/english/vote
- https://dictionary.cambridge.org/dictionary/english/deliberation
Again, I will change it if people are uncomfortable ...
Thanks,
Steve / Futurile
[0] https://social.sciences.re/@zimoun/114493797832431816
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 12 May 2025 15:35:02 GMT)
Full text and
rfc822 format available.
Message #605 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
Steve George <steve <at> futurile.net> writes:
> Note that 'Deliberate' means to "consider or discuss", and a person
> would "vote" at the end of a deliberation period to "to express your
> choice or opinion". That is the standard use in English. One doesn't
> keep a "Deliberation" as a record of choices (e.g. tally of
> votes). Also, to be explicit just because something is a "vote"
> doesn't imply that the it's "majority rule" on anything similar. I
> bring it up, because it's going to sounds odd to me as a native
> English speaker.
>
> - https://dictionary.cambridge.org/dictionary/english/vote
>
> - https://dictionary.cambridge.org/dictionary/english/deliberation
Oh, I perhaps mistakenly assumed “deliberation” was the same as French
“délibération”, “decision taken by a governing body”:
https://fr.wiktionary.org/wiki/d%C3%A9lib%C3%A9ration#Traductions
https://en.wiktionary.org/wiki/d%C3%A9lib%C3%A9ration
Wiktionary seems to agree with the “decision taken” meaning, but WordNet
(US English) less so.
So now I’m not so sure but I still find the term “vote” to be loaded
(and not what GCD 001 uses anyway).
WDYT?
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 12 May 2025 16:00:02 GMT)
Full text and
rfc822 format available.
Message #608 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On Mon, May 12, 2025 at 05:33:47PM +0200, Ludovic Courtès wrote:
> Oh, I perhaps mistakenly assumed “deliberation” was the same as French
> “délibération”, “decision taken by a governing body”:
>
> https://en.wiktionary.org/wiki/d%C3%A9lib%C3%A9ration
------
délibération f (plural délibérations)
1) deliberation; contemplation
2) deliberation; discussion
3) deliberation (decision taken by a governing body)
------
I agree with Steve that this use of 'deliberation' is unusual, at least
in American English. From the wiktionary entry above, I'm familiar with
first 2 senses of the word, but not the 3rd. I would expect to hear a
a phrase like "... the outcome of the deliberation ...".
I also agree that it's important to de-emphasize the idea of a vote and
focus on working together to build consensus. Instead of "voting
records", what about just using a term like "decision", "decision
taken", "decision made", etc?
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 12 May 2025 16:45:01 GMT)
Full text and
rfc822 format available.
Message #611 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2025-05-12, Ludovic Courtès wrote:
> Steve George <steve <at> futurile.net> writes:
>> Note that 'Deliberate' means to "consider or discuss", and a person
>> would "vote" at the end of a deliberation period to "to express your
>> choice or opinion". That is the standard use in English. One doesn't
>> keep a "Deliberation" as a record of choices (e.g. tally of
>> votes). Also, to be explicit just because something is a "vote"
>> doesn't imply that the it's "majority rule" on anything similar. I
>> bring it up, because it's going to sounds odd to me as a native
>> English speaker.
>>
>> - https://dictionary.cambridge.org/dictionary/english/vote
>>
>> - https://dictionary.cambridge.org/dictionary/english/deliberation
>
> Oh, I perhaps mistakenly assumed “deliberation” was the same as French
> “délibération”, “decision taken by a governing body”:
>
> https://fr.wiktionary.org/wiki/d%C3%A9lib%C3%A9ration#Traductions
> https://en.wiktionary.org/wiki/d%C3%A9lib%C3%A9ration
>
> Wiktionary seems to agree with the “decision taken” meaning, but WordNet
> (US English) less so.
To my take on english "deliberation" is usually focused more on the
process of making a decision, though possibly to make it clear and
explicit, we could use "deliberation results" or "results of the
deliberation" ?
> So now I’m not so sure but I still find the term “vote” to be loaded
> (and not what GCD 001 uses anyway).
I think that "vote" does tend to guide people towards other decision
making processes that are not really consensus building, if only for the
reason that many do not have much experience with anything other than
voting by majority rule... even if there are technically other meanings
for the word.
The term I am used to hearing instead of vote is "Call for consensus"
and then the result is nearly binary (e.g. consensus reached (with or
without abstentions), consensus not reached).
I find it is more important to record the issues and concerns that lead
to blocking consensus (e.g. "I disapprove") than to record who blocked
consensus. It gives a checklist of what needs to be fixed if something
similar is proposed later...
Without that, it is akin to those wonderful "Something went wrong" error
messages.
live well,
vagrant
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Mon, 12 May 2025 17:26:02 GMT)
Full text and
rfc822 format available.
Message #614 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Mon, May 12 2025, Vagrant Cascadian wrote:
> we could use "deliberation results" or "results of the deliberation" ?
Perhaps a clickable thesaurus could help to explore adjacent meanings?
According to The Free Dictionary, the shade meaning for "vote" you are
all chasing is "poll". [1]
If the word "poll" alone is not good enough, there are also "tally",
"record" or "survey" (although futurile will probably find that, in
Guix, the latter was already taken).
As a former minor public official for ten years (a library commissioner
in California) I'll add that words can only do so much. A consensus is
a living thing.
Compromise come from the heart. It's something we do for each other.
And then it doesn't matter what you call it. I always called it a vote,
but I would have called it anything that fits, without hesitation.
Kind regards,
Felix
[1] https://www.freethesaurus.com/poll
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 13 May 2025 06:39:02 GMT)
Full text and
rfc822 format available.
Message #617 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On 12 May, Ludovic Courtès wrote:
(...)
> This will be consistent with the terminology used in GCD 001 and also
> dispel the impression that it all boils down to a vote: there is no vote
> (and no campaign, no representatives, nothing like that), and I’d prefer
> everyone in the community to focus on the discussion and improvements
> that stem from it rather than on the final show of hands.
Understand the desired outcome.
> 1. Renaming “voting-records” to “deliberation”.
>
> 2. In the ‘README’ and .rec files, change “Voting record” to
> “Deliberation record”, and generally “Vote” to “Deliberation”.
(...)
Reflecting things that we agree on: I will try and avoid the word 'vote'. I'll rename to 'deliberation-record' (1). And, will use 'Deliberation record' elsehwere.
Things we don't agree on: I don't see a way to avoid the verb "vote" for the action of "officially recording ones position". It's the only usable word I can come up with (which is odd for English). I don't want to mis-use the word deliberation as a verb for vote. If someone can come up with a meaningful verb for 'vote' I will use that - I just genuinely can't find one that isn't really odd (e.g. "It's time to measure our consensus" sounds like a weird euphemism to me!). It means it's hard to avoid a sentence like "As the Deliberation Period is at an end, it's time to vote on GCDNNN"
Does that help?
Steve / Futurile
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 13 May 2025 09:02:02 GMT)
Full text and
rfc822 format available.
Message #620 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Mon, 12 May 2025 at 09:43, Vagrant Cascadian <vagrant <at> debian.org> wrote:
> To my take on english "deliberation" is usually focused more on the
> process of making a decision, though possibly to make it clear and
> explicit, we could use "deliberation results" or "results of the
> deliberation" ?
In French, the main meaning of “délibération” [1] is “the act to
scrutinize all the elements leading to a final decision”, i.e., it’s a
process.
Then by extension, “délibération” also means the final decision itself:
the “délibération” (process) leads to some “délibération” (conclusion).
1: https://www.cnrtl.fr/lexicographie/d%C3%A9lib%C3%A9ration
>> So now I’m not so sure but I still find the term “vote” to be loaded
>> (and not what GCD 001 uses anyway).
>
> I think that "vote" does tend to guide people towards other decision
> making processes that are not really consensus building, if only for the
> reason that many do not have much experience with anything other than
> voting by majority rule... even if there are technically other meanings
> for the word.
For me, the main raison d’être of the “Deliberation Period” is to
explicitly and concisely record the acceptance or the issues and
concerns.
If I read correctly, the meaning of “vote” is [2]: express your choice
or opinion, especially by officially writing; the act of showing your
choice or opinion; etc.
Therefore, the term “vote” appears to me ambiguous here. Somehow, yes
one expresses their opinion in the “Deliberation Period”, but not really
neither because they should only restate for the record their opinion
already expressed during the “Discussion Period”.
2: https://dictionary.cambridge.org/dictionary/english/vote
> I find it is more important to record the issues and concerns that lead
> to blocking consensus (e.g. "I disapprove") than to record who blocked
> consensus. It gives a checklist of what needs to be fixed if something
> similar is proposed later...
I agree! :-)
Assuming we amend GCD #001 – we need a new GCD for amending accepted
GCDs, BTW – WDYT about “Recording Period” instead of “Deliberation
Period”?
Somehow, I would propose to use “record” instead of “deliberation”.
WDYT?
Cheers,
simon
For a concrete example of such minor tweaks, does it appears to you
clearer?
--8<---------------cut here---------------start------------->8---
1 file changed, 10 insertions(+), 10 deletions(-)
001-gcd-process.md | 20 ++++++++++----------
modified 001-gcd-process.md
@@ -129,7 +129,7 @@ below.
using the assigned issue number.
- The *final* document is published to `info-guix <at> gnu.org` and the
- deliberating replies are sent to the assigned issue number.
+ recorded replies are sent to the assigned issue number.
## Timeline
@@ -139,7 +139,7 @@ consisting of several *periods*.
```
draft submitted final
+--------------------+ +---------------------+ +---------------------+
-| Submission Period | | Discussion Period | | Deliberation Period |
+| Submission Period | | Discussion Period | | Recording Period |
| (up to 7 days) |-X->| (30–60 days) |-->| (14 days) |
+--------------------+ : +---------------------+ +---------------------+
: : : |
@@ -177,17 +177,17 @@ included under section “Open Issues” in the document.
When deemed appropriate, between 30 days and 60 days after the start of the
discussion period, the author(s) may publish a final version and announce
-the start of the *deliberation period*. If the authors fail to do so, the
-deliberation period automatically starts 60 days after the start of the
+the start of the *recording period*. If the authors fail to do so, the
+recording period automatically starts 60 days after the start of the
discussion period based on the latest version provided by the author(s).
-### Deliberation Period (14 days)
+### Recording Period (14 days)
-Deliberation aims at consolidating consensus; see “Decision Making” below.
+Decision record aims at consolidating consensus; see “Decision Making” below.
-The *deliberation period* starts when the authors publish a final version
+The *recording period* starts when the authors publish a final version
of the GCD at `info-guix <at> gnu.org`. Anyone who is a team member is a
-deliberating member and is encouraged to contribute to the deliberation.
+recording member and is encouraged to contribute to the decision record.
Once the final version is published, team members have 14 days to send one
of the following replies on the patch-tracking entry of the GCD:
@@ -200,7 +200,7 @@ of the following replies on the patch-tracking entry of the GCD:
comments during the discussion period.
The GCD is *accepted* if (1) at least 25% of all team members–as of the
-start of the “Deliberation Period”–send a reply, and (2) no one
+start of the “Recording Period”–send a reply, and (2) no one
disapproves. In other cases, the GCD is *withdrawn*.
GCD acceptance is not a rubber stamp; in particular, it does not mean the
@@ -218,7 +218,7 @@ consensus. By using consensus, we are committed to finding solutions that
everyone can live with.
Thus, no decision is made against significant concerns; these concerns are
-actively resolved through counter proposals. A deliberating member
+actively resolved through counter proposals. A recording member
disapproving a proposal bears a responsibility for finding alternatives,
proposing ideas or code, or explaining the rationale for the status quo.
--8<---------------cut here---------------end--------------->8---
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 13 May 2025 13:32:02 GMT)
Full text and
rfc822 format available.
Message #623 received at 76503 <at> debbugs.gnu.org (full text, mbox):
(I previously sent this mail to steve alone, am resending it now with
the mailing list et al in CC)
Steve George <steve <at> futurile.net> writes:
> Reflecting things that we agree on: I will try and avoid the word
> 'vote'. I'll rename to 'deliberation-record' (1). And, will use
> 'Deliberation record' elsehwere.
>
> Things we don't agree on: I don't see a way to avoid the verb "vote"
> for the action of "officially recording ones position".
I think there's an issue here, as to me, the "voting" process at the end
of a GCD is not about recording ones position, but about recording not
just position, but also how strong that position is, and how tolerable
the other outcomes are to you.
If someone prefers that a GCD be withdrawn but would find its acceptance
acceptable, they should probably "vote" accept, even if their preference
is quite strong
> It's the only usable word I can come up with (which is odd for
> English). I don't want to mis-use the word deliberation as a verb for
> vote. If someone can come up with a meaningful verb for 'vote' I will
> use that - I just genuinely can't find one that isn't really odd
> (e.g. "It's time to measure our consensus" sounds like a weird
> euphemism to me!).
> It means it's hard to avoid a sentence like "As the Deliberation
> Period is at an end, it's time to vote on GCDNNN"
I would go for something along the lines of "As the Deliberation Period
is at an end, it's time to see/look whether consensus has been reached"
Alternatively, naming this process something like a (consensus) poll or
a show of hands might help prevent the associations with majority-based
decision making
And instead of "X people voted" you could say something like "X people
responded (to the poll)"
Kind regards,
pinoaffe
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 13 May 2025 14:07:01 GMT)
Full text and
rfc822 format available.
Message #626 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi Steve,
Steve George <steve <at> futurile.net> skribis:
> Reflecting things that we agree on: I will try and avoid the word 'vote'. I'll rename to 'deliberation-record' (1). And, will use 'Deliberation record' elsehwere.
Sounds great to me.
> Things we don't agree on: I don't see a way to avoid the verb "vote" for the action of "officially recording ones position". It's the only usable word I can come up with (which is odd for English). I don't want to mis-use the word deliberation as a verb for vote. If someone can come up with a meaningful verb for 'vote' I will use that - I just genuinely can't find one that isn't really odd (e.g. "It's time to measure our consensus" sounds like a weird euphemism to me!). It means it's hard to avoid a sentence like "As the Deliberation Period is at an end, it's time to vote on GCDNNN"
“Time to decide”?
But I think it’s okay if we use the word “vote” occasionally; I would
just prefer not overemphasizing it and giving a false impression, and I
thought that its prominent use in the records could be one such case.
Thanks for deliberating. :-)
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 13 May 2025 14:09:01 GMT)
Full text and
rfc822 format available.
Message #629 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On Tue, May 13, 2025 at 9:32 AM pinoaffe <pinoaffe <at> gmail.com> wrote:
>
> If someone prefers that a GCD be withdrawn but would find its acceptance
> acceptable, they should probably "vote" accept, even if their preference
> is quite strong
This preference is indicated by not voting. If 75% of team members
"vote" this way then the proposal fails.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 13 May 2025 14:58:02 GMT)
Full text and
rfc822 format available.
Message #632 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Greg Hogan <code <at> greghogan.com> writes:
> On Tue, May 13, 2025 at 9:32 AM pinoaffe <pinoaffe <at> gmail.com> wrote:
>> If someone prefers that a GCD be withdrawn but would find its acceptance
>> acceptable, they should probably "vote" accept, even if their preference
>> is quite strong
> This preference is indicated by not voting. If 75% of team members
> "vote" this way then the proposal fails.
Ah right, I stand corrected
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 13 May 2025 15:51:01 GMT)
Full text and
rfc822 format available.
Message #635 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2025-05-13, Greg Hogan wrote:
> On Tue, May 13, 2025 at 9:32 AM pinoaffe <pinoaffe <at> gmail.com> wrote:
>>
>> If someone prefers that a GCD be withdrawn but would find its acceptance
>> acceptable, they should probably "vote" accept, even if their preference
>> is quite strong
>
> This preference is indicated by not voting. If 75% of team members
> "vote" this way then the proposal fails.
Do you mean if 75% of team members simply do not reply, the proposal
fails? ... as a strategy when their preference is strongly against
seeing the decision carried out, but not so strong as to completely stop
the decision (e.g. "I disapprove")?
I initially read you as meaning 75% of team members reply with "I
accept", in which it would pass:
https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/tree/001-gcd-process.md#n184
- “I support”, meaning that one supports the proposal;
- “I accept”, meaning that one consents to the implementation of the
proposal;
- “I disapprove”, meaning that one opposes the implementation of the
proposal. A team member sending this reply should have made constructive
comments during the discussion period.
The GCD is *accepted* if (1) at least 25% of all team members–as of
the start of the “Deliberation Period”–send a reply, and (2) no one
disapproves. In other cases, the GCD is *withdrawn*.
The "I accept" replies counts towards the 25% quorum.
If only 24.99% of team members state "I support" or "I accept", then the
proposal fails. Or if a single team member states "I disapprove", it
fails.
Admittedly, an overwhelmingly large number of "I accept" with few or no
"I support" likely indicates something might be a bit off ... or just
some ambivalence and/or low stakes.
live well,
vagrant
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 13 May 2025 15:55:02 GMT)
Full text and
rfc822 format available.
Message #638 received at 76503 <at> debbugs.gnu.org (full text, mbox):
For the record, I reached out to Codeberg e.V. regarding storage and
bandwidth usage induced by Guix, to which they replied that they “expect
this to be fine”:
https://codeberg.org/Codeberg-e.V./requests/issues/784
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 13 May 2025 16:16:02 GMT)
Full text and
rfc822 format available.
Message #641 received at 76503 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2025-05-13, Simon Tournier wrote:
> On Mon, 12 May 2025 at 09:43, Vagrant Cascadian <vagrant <at> debian.org> wrote:
>> To my take on english "deliberation" is usually focused more on the
>> process of making a decision, though possibly to make it clear and
>> explicit, we could use "deliberation results" or "results of the
>> deliberation" ?
>
> In French, the main meaning of “délibération” [1] is “the act to
> scrutinize all the elements leading to a final decision”, i.e., it’s a
> process.
>
> Then by extension, “délibération” also means the final decision itself:
> the “délibération” (process) leads to some “délibération” (conclusion).
>
> 1: https://www.cnrtl.fr/lexicographie/d%C3%A9lib%C3%A9ration
Yeah, I think there is some difference in meaning here that could be
tripping some of us.
>>> So now I’m not so sure but I still find the term “vote” to be loaded
>>> (and not what GCD 001 uses anyway).
>>
>> I think that "vote" does tend to guide people towards other decision
>> making processes that are not really consensus building, if only for the
>> reason that many do not have much experience with anything other than
>> voting by majority rule... even if there are technically other meanings
>> for the word.
>
> For me, the main raison d’être of the “Deliberation Period” is to
> explicitly and concisely record the acceptance or the issues and
> concerns.
>
> If I read correctly, the meaning of “vote” is [2]: express your choice
> or opinion, especially by officially writing; the act of showing your
> choice or opinion; etc.
>
> Therefore, the term “vote” appears to me ambiguous here. Somehow, yes
> one expresses their opinion in the “Deliberation Period”, but not really
> neither because they should only restate for the record their opinion
> already expressed during the “Discussion Period”.
>
> 2: https://dictionary.cambridge.org/dictionary/english/vote
Yeah, I think you hit upon something here. At least as a native english
speaker, deliberation ~= discussion, so the distinction between
"Discussion period" and "Deliberation period" sound effectively the
same, even though obviously the process spelled out is significantly
different. "Deliberation" might have slightly more formal overtones. I
had a little unease with the original proposal wording, but it was not
clear to me until now...
"Deliberation" is simply a misleading word for that phase of the
process, at least for some english speakers.
>> I find it is more important to record the issues and concerns that lead
>> to blocking consensus (e.g. "I disapprove") than to record who blocked
>> consensus. It gives a checklist of what needs to be fixed if something
>> similar is proposed later...
>
> I agree! :-)
>
> Assuming we amend GCD #001 – we need a new GCD for amending accepted
> GCDs, BTW – WDYT about “Recording Period” instead of “Deliberation
> Period”?
>
> Somehow, I would propose to use “record” instead of “deliberation”.
Not in love with "Deliberation" -> "Recording" but would accept it as
better than the status quo. :)
As said earlier, I would use "Call for consensus" or maybe "Poll for
consensus" although "Poll" is often used as an informal non-binding
thing in various processes I have worked with, so that could be
confusing too.
I also like dark purple, but am not a fan of lighter shades.
live well,
vagrant
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 13 May 2025 16:27:02 GMT)
Full text and
rfc822 format available.
Message #644 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hi,
On 2025-05-12 15:33, Ludovic Courtès wrote:
> Steve George <steve <at> futurile.net> writes:
>
>> Note that 'Deliberate' means to "consider or discuss", and a person
>> would "vote" at the end of a deliberation period to "to express your
>> choice or opinion". That is the standard use in English. One doesn't
>> keep a "Deliberation" as a record of choices (e.g. tally of
>> votes). Also, to be explicit just because something is a "vote"
>> doesn't imply that the it's "majority rule" on anything similar. I
>> bring it up, because it's going to sounds odd to me as a native
>> English speaker.
>>
>> - https://dictionary.cambridge.org/dictionary/english/vote
>>
>> - https://dictionary.cambridge.org/dictionary/english/deliberation
>
> Oh, I perhaps mistakenly assumed “deliberation” was the same as French
> “délibération”, “decision taken by a governing body”:
>
> https://fr.wiktionary.org/wiki/d%C3%A9lib%C3%A9ration#Traductions
> https://en.wiktionary.org/wiki/d%C3%A9lib%C3%A9ration
>
> Wiktionary seems to agree with the “decision taken” meaning, but
> WordNet
> (US English) less so.
>
> So now I’m not so sure but I still find the term “vote” to be loaded
> (and not what GCD 001 uses anyway).
>
> WDYT?
I consider any quantification of opinion to be a vote.
I can readily accept that Guix is using everything within the scope of
deliberation but I cant shake off this perspective.
Given my last message covering EU governance, I should consider that a
lot of votes would occur within the domain of deliberative activity.
FIWI, I made an arbitrary choice to peruse governance of a
not-for-profit, The Magic Circle.
While, `Section 6' and other facets is heavy towards to use of 'vote',
it is the case that `6.6.3' does make reference to the term `poll':
https://themagiccircle.co.uk/about/the-societys-rules/
Perhaps the use of the word `poll' would be considered as having softer
meaning withing Guix's nomenclature?
Kind regards,
>
> Ludo’.
Jonathan
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 13 May 2025 17:23:02 GMT)
Full text and
rfc822 format available.
Message #647 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On Tue, May 13, 2025 at 11:50 AM Vagrant Cascadian <vagrant <at> debian.org> wrote:
>
> On 2025-05-13, Greg Hogan wrote:
> > On Tue, May 13, 2025 at 9:32 AM pinoaffe <pinoaffe <at> gmail.com> wrote:
> >>
> >> If someone prefers that a GCD be withdrawn but would find its acceptance
> >> acceptable, they should probably "vote" accept, even if their preference
> >> is quite strong
> >
> > This preference is indicated by not voting. If 75% of team members
> > "vote" this way then the proposal fails.
>
> Do you mean if 75% of team members simply do not reply, the proposal
> fails? ... as a strategy when their preference is strongly against
> seeing the decision carried out, but not so strong as to completely stop
> the decision (e.g. "I disapprove")?
Yes, the fourth option is not to vote. And as you note I should have
said "more than 75%". We have strong ("support") and weak ("accept")
options for approval and strong ("disapprove") and weak ("abstain")
options for disapproval. One can even respond with a justification for
abstention (just refrain from the three magic words!).
We could explicitly list this option ("dissent"?) to provide a weak
alternative to disapproval but then we are further rejecting consensus
building.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Tue, 13 May 2025 18:45:02 GMT)
Full text and
rfc822 format available.
Message #650 received at 76503 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-13 17:54, Ludovic Courtès wrote:
> For the record, I reached out to Codeberg e.V. regarding storage and
> bandwidth usage induced by Guix, to which they replied that they “expect
> this to be fine”:
>
> https://codeberg.org/Codeberg-e.V./requests/issues/784
>
> Ludo’.
>
Oh!
This is great!
Thanks for checking this. As you know, I'm a little bit worried about
them. I'm happy to see this is working out greatly.
We should keep an eye on them, to make sure they are fine.
Thanks!
Information forwarded
to
guix-patches <at> gnu.org:
bug#76503; Package
guix-patches.
(Fri, 23 May 2025 17:12:02 GMT)
Full text and
rfc822 format available.
Message #653 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Hello dear guix maintainers,
Maybe i talk in the wrong place but i would like to suggest 'Settlement
Period' or stronger 'Casting Period'.
I found it on a famous shorter dictionnary!
Sébastien.
Vagrant Cascadian <vagrant <at> debian.org> writes:
> On 2025-05-13, Simon Tournier wrote:
>> On Mon, 12 May 2025 at 09:43, Vagrant Cascadian <vagrant <at> debian.org> wrote:
>>> To my take on english "deliberation" is usually focused more on the
>>> process of making a decision, though possibly to make it clear and
>>> explicit, we could use "deliberation results" or "results of the
>>> deliberation" ?
>>
>> In French, the main meaning of “délibération” [1] is “the act to
>> scrutinize all the elements leading to a final decision”, i.e., it’s a
>> process.
>>
>> Then by extension, “délibération” also means the final decision itself:
>> the “délibération” (process) leads to some “délibération” (conclusion).
>>
>> 1: https://www.cnrtl.fr/lexicographie/d%C3%A9lib%C3%A9ration
>
> Yeah, I think there is some difference in meaning here that could be
> tripping some of us.
>
>
>>>> So now I’m not so sure but I still find the term “vote” to be loaded
>>>> (and not what GCD 001 uses anyway).
>>>
>>> I think that "vote" does tend to guide people towards other decision
>>> making processes that are not really consensus building, if only for the
>>> reason that many do not have much experience with anything other than
>>> voting by majority rule... even if there are technically other meanings
>>> for the word.
>>
>> For me, the main raison d’être of the “Deliberation Period” is to
>> explicitly and concisely record the acceptance or the issues and
>> concerns.
>>
>> If I read correctly, the meaning of “vote” is [2]: express your choice
>> or opinion, especially by officially writing; the act of showing your
>> choice or opinion; etc.
>>
>> Therefore, the term “vote” appears to me ambiguous here. Somehow, yes
>> one expresses their opinion in the “Deliberation Period”, but not really
>> neither because they should only restate for the record their opinion
>> already expressed during the “Discussion Period”.
>>
>> 2: https://dictionary.cambridge.org/dictionary/english/vote
>
> Yeah, I think you hit upon something here. At least as a native english
> speaker, deliberation ~= discussion, so the distinction between
> "Discussion period" and "Deliberation period" sound effectively the
> same, even though obviously the process spelled out is significantly
> different. "Deliberation" might have slightly more formal overtones. I
> had a little unease with the original proposal wording, but it was not
> clear to me until now...
>
> "Deliberation" is simply a misleading word for that phase of the
> process, at least for some english speakers.
>
>
>>> I find it is more important to record the issues and concerns that lead
>>> to blocking consensus (e.g. "I disapprove") than to record who blocked
>>> consensus. It gives a checklist of what needs to be fixed if something
>>> similar is proposed later...
>>
>> I agree! :-)
>>
>> Assuming we amend GCD #001 – we need a new GCD for amending accepted
>> GCDs, BTW – WDYT about “Recording Period” instead of “Deliberation
>> Period”?
>>
>> Somehow, I would propose to use “record” instead of “deliberation”.
>
> Not in love with "Deliberation" -> "Recording" but would accept it as
> better than the status quo. :)
>
> As said earlier, I would use "Call for consensus" or maybe "Poll for
> consensus" although "Poll" is often used as an informal non-binding
> thing in various processes I have worked with, so that could be
> confusing too.
>
> I also like dark purple, but am not a fan of lighter shades.
>
> live well,
> vagrant
bug closed, send any further explanations to
76503 <at> debbugs.gnu.org and Ludovic Courtès <ludo <at> gnu.org>
Request was from
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sat, 31 May 2025 14:04:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 16 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.