Hi Ludo’,
I support this overall direction. Implementation details may
require additional concensus, though I’m not sure if they’ll rise
to the level of a GCD, but would like to see some discussion of
problems as they crop up.
Forgejo is purpose-built for developing software; email is not.
This difference shows up clearly in areas of tooling and
consistency.
Because email isn’t purpose-built for this, it must be adapted
through the development of tooling to make it fit for purpose.
This causes a lot of accidental complexity, rough integrations,
and maintenance burden. I have personally encounterd a large
number of problems with the workflow and tooling which simply do
not exist in forge-style tooling:
I want to preface this by saying, I’m not criticizing individuals
or work or approach here. The done on Guix infrastructure and
process was valuable and useful, but IMO Guix has simply outgrown
parts of it. But I think problems need to be acknowledged, so
these are some of my observations about them.
- As of today, February 8th, the most recent bug shown on
issues.guix.gnu.org is from February 2nd. It’s been running at
least a week behind for many weeks. Since it’s harder for
pepole to see patches and bugs, it’s harder to get them reviewed
and worked on.
- The QA status on issues.guix.gnu.org is not very useful. By far
the most common thing to see here is "QA: Unknown," with no
indication of why it’s unknown or when it may become known[1].
Sometimes this is infrastructure failures; other times, QA is
overloaded. Both present the same way. The important
information this should provide is, in large part, absent. In
turn, that makes it much harder for contributors -- particularly
non-committers -- to ascertain if a given patch is problematic
or not.
- Sending a patch series is well-known to be harder than it
should.
- Much of the infrastructure has suffered from frequent outages
(once a week or more) which disrupt the user and contributer
experience, and the situation hasn’t improved in at least a
year.
- The large number of tools needed to participate in Guix
development is a real barrier to doing so.
- Using email means that contributors often send patches "the
wrong way" (ex. as attachments), which the tooling then rejects.
Forges don’t suffer from this, because there’s only one way to
contribute, which is the same for everyone.
- The depth of patch review is inconsistent depending on the
reviewer, which I believe is due to lacking a consistent process
for doing so. Forge-style CI would improve this: it could
report whether a package passes `guix lint', whether it triggers
a large number of rebuilds, etc. The consistent application of
these standards will, I believe, both ease burden on committers
(you don’t have to remember to check these things) and raise the
consistency of these policies getting applied.
I am sensitive to those who are unhappy about using a web
interface. I live in Emacs, I use EXWM, I’m writing this email in
mu4e. I would like to see better Emacs tooling for interacting
with Forgejo, so the heavier web interface can be avoided. I
believe that in this instance, and others, the problems of making
Forgejo work cleanly and consistently are significantly more
tractable than making the existing email patch flow and tooling
work cleanly and consistently.
Therefore, to reiterate, I support this.
-- Ian
[1]: Here’s a patch I pulled at random, opened a week ago, which
is stuck in "yet to process revision":
https://qa.guix.gnu.org/issue/75991
