Dragan Simic <[email protected]> writes: > On 2025-09-28 19:42, Collin Funk wrote: >> Arsen Arsenović <[email protected]> writes: >>> Dragan Simic <[email protected]> writes: >>>> On 2025-09-28 11:31, Arsen Arsenović wrote: >>>>> IMO this is a good idea. New contributors would likely find the >>>>> workflow easier (even though I personally like a mail-based workflow a >>>>> lot), we can incorporate automated testing, and Codeberg appears to be >>>>> ideologically aligned with the GNU project goals. >>>> Would sending patches through a mailing list disappear as an option >>>> after the migration to Codebeerg? I'd find that a huge step back. >>> There might be no need for that for coreutils (which is relatively >>> simple to test - consistent and automated testing is the core benefit of >>> forges IMO). >>> That said, it'd be good to address whatever concerns you might have with >>> such a switch to see if it is possible to build up improvements in >>> workflow. >> Myself and I assume others, who may correct me if I am wrong, still like >> mailing lists. Therefore, I would be for keeping that as the primary way >> to report bugs/send patches. > > I also prefer mailing lists. They offer flexibility that no forge can > even come close by, simply because on mailing lists nearly nothing has > to be in some strictly predefined layout or conforming to some strict > form.
This is also their downfall. It directly leads to the contribution
process being inconsistent, incoherent, and hard to automate.
Consider testing for a project like GCC. To test GCC properly, you
cannot just run a testsuite on your machine.
Due to unfortunate circumstances, GCC requires a baseline of tests to
compare against, and this comparison is considered successful only if
the differences between the baseline and patched GCC are passing tests.
So, you need to also test the baseline. This process is easy to
automate but (relatively) difficult to explain to new contributors.
The previous part was possible to do on just your machine, but
"properly" testing GCC also requires testing on various weird platforms.
For this, we have the cfarm. Access to the cfarm is a privilege not
available to many contributors (though luckily I have it), awareness of
this issue is also not something everyone has, and access to the cfarm
is moot if you aren't knowledgeable in the strange targets GCC ought to
be tested for (e.g. AIX.. I've spent many hours digging around for AIX
documentation, and trying to figure out AIX executable formats and
library formats). Such weird machines are non readily-available
(another such example are MS-w workstations - I haven't owned any in
years and I couldn't honestly say that I could operate one for purposes
of testing MinGW - as a real-world example, the Glorious Glasgow Haskell
Compiler project automatically tests GHC on Windows and when I
contributed to GHC I never had to worry about that decrepit platform).
> For example, I'm unaware of any forge that offers fully threaded
> discussions about pull requests and issues, which are simply mandatory
> for any kind of complex discussion.
This, I agree, is unfortunate. But, for most changes, heavily-threaded
discussion doesn't tend to happen, whereas extensive testing is required
for all changes. It would be nice if the forges grew in this regard
(and I hope that the use of forges by, say, the GNU toolchain, could
lead to funds being redirected to enable work in that direction).
Note that many forges (not sure about Forgejo specifically, however)
offer some form of threading for discussing individual parts of code
(e.g. commenting on a line starts a new, albeit linear, thread about
it).
> On top of everything, forges pull the metadata, as what's contained in
> the discussions, into some kind of their own format that's either tied
> to the particular forge or isn't some simple data format that can be
> used with no need for tools that are more complex than a pager such as
> less(1). Mailing lists don't do any of that, and they allow everyone
> to have a full local copy of all the metadata, which can only be good
> in the long term. Metadata is gold.
Metadata is lacking in MLs, besides plain email metadata, though.
I do agree with the rest of this paragraph. I can't concede that only
MLs can achieve this, however; it is easy to imagine (and possibly
implement) a way to download discussions from a forge. Such a download
would necessarily also be richer.
>> I don't think anyone will complain if the Codeberg interface leads to
>> more *quality* bug reports and patches, though. Some of us track the
>> pull requests and bugs on the GitHub mirror. But the closed history
>> there will show a lot of spam.
>
> I think people are focussing a bit too much on the need for having new
> contributors, which actually may or may not prefer the GitHub-style
> workflow. Assuming that by default all new contributors prefer that
> kind of workflow and find the mailing lists as a huge barrier to entry
> is simply a false assumption. See, I was a new contributor to quite
> a few projects, and I always preferred mailing lists.
Please don't project such intention on me. I have detailed other
significant reasons why a more structured approach is preferable.
Practice shows that ML-based workflows are hard to automate around, and
automation as described above is very necessary.
While this extreme form of the assumption ("all" rather than "many" or
even "most") is indeed false, the weaker form is not a false assumption.
Anecdotally, as someone who taught at a university I can tell you that
interacting with mailing software is enough to dissuade many students.
Heck, many students don't even realize what "mailing software" is or
that they are using it (when using webmail).
(at my university the situation was yet more depressing, to my awareness
only two faculty members besides myself used non-webmail mail clients,
specifically Alpine and Thunderbird)
This kind of workflow is not something present in most enterprise
environments (exceptions being IME mostly firms dealing with free
software primarily, and even then a specific subsection dealing with GNU
and Linux), where most engineers will be located most of the time, or
even in academic environments, where most students are (by definition)
present, ergo it is fair to assume most will have little interaction
with it.
Many contributors doing cost-benefit analysis with this in mind for
minor changes will result in many minor but useful proposals being lost.
(note, however, that a web alternative also has some barrier to entry
assuming there isn't OpenID-esque ways to authenticate without creating
new accounts, which is also annoying, so, assuming no such way of
access, this could dissuade some contributors - I hope allowing
authetication using external services combined with the usefulness of
signing up for a generally-used forge like Codeberg or a heavily-used
forge like the Sourceware one is enough to overcome this cost)
I'd love to show empirical data for this, but I am not aware of anyone
collecting such data.
> Also, focusing too much on the new contributors and not thinking about
> the already existing ones at the same time may not be the best
> approach in the long run.
Naturally.
I'd love to see a magical way to make a non-fragile CI system for
mailing lists, but I am not aware of any such system so far. SourceHut
has appeared to come closest in my opinion, but it relies strictly on
emails generated by git format-patch. This is easy to get wrong
(unintentionally misconfiguring git send-email, or failing to configure
it and hence falling back to sending patches in one of many arbitrary
ways), it may even be impossible in some conditions (e.g. corporate
email servers munging outgoing emails).
I, too, like the convenience of git-send-email combined with a mailing
client I can use as efficiently as muscle memory, but the above points
outweigh the slight loss of convenience on my end.
Have a lovely night.
(PS: we appear to be in the same region, that's fun!)
--
Arsen Arsenović
signature.asc
Description: PGP signature
