On Thu, Mar 14, 2024 at 7:49 AM Theodore Ts'o <
tytso@mit.edu> wrote:
On Thu, Mar 14, 2024 at 11:44:45AM +1100, Alexis wrote:
>
> i basically agree. i won't dwell on this too much further because i
> recognise that i'm going off-topic, list-wise, but:
>
> i think part of the problem is related to different people having
> different preferences around the interfaces they want/need for
> discussions. What's happened is that - for reasons i feel are
> typically due to a lock-in-oriented business model - many discussion
> systems don't provide different interfaces/'views' to the same
> underlying discussions. Which results in one community on platform X,
> another community on platform Y, another community on platform Z
> .... Whereas, for example, the 'Rocksolid Light' BBS/forum software
> provides a Web-based interface to an underlying NNTP-based system,
> such that people can use their NNTP clients to engage in forum
> discussions. i wish this sort of approach was more common.
This is a bit off-topic, and so if we need to push this to a different
list (I'm not sure COFF is much better?), let's do so --- but this is
a conversation which is super-improtant to have. If not just for Unix
heritage, but for the heritage of other collecvtive systems-related
projects, whether they be open source or proprietary.
A few weeks ago, there were people who showed up on the git mailing
list requesting that discussion of the git system move from the
mailing list to using a "forge" web-based system, such as github or
gitlab. Their reason was that there were tons of people who think
e-mail is so 1970's, and that if we wanted to be more welcoming to the
up-and-coming programmers, we should meet them were they were at. The
obvious observations of how github was proprietary, and locking up our
history there might be contra-indicated was made, and the problem with
gitlab is that it doesn't have a good e-mail gateway, and while we
might be disenfranchising the young'uns by not using some new-fangled
web interface, disenfranchising the existing base of expertise was
even worse idea.
The best that we have today is lore.kernel.org, which is used by both
the Linux Kernel and the git development communities. It uses
public-inbox to archive the mailing list traffic, and it can be
accessed via threaded e-mail interface, as well as via NNTP. There
are also tools for subscribing to messages that match a filtering
criteria, as well as tools for extracting patches plus code review
sign-offs into a form that can be easily consumed by git.
email based flows are horrible. Absolutely the worst. They are impossible
to manage. You can't subscribe to them w/o insane email filtering rules,
you can't discover patches or lost patches easily. There's no standard way
to do something as simple as say 'never mind'. There's no easy way
to follow much of the discussion or find it after the fact if your email was
filtered off (ok, yea, there kinda is, if you know which archives to troll
through).
As someone who recently started contributing to QEMU I couldn't get over
how primitive the email interaction was. You magically have to know who
to CC on the patches. You have to look at the maintainers file, which is often
stale and many of the people you CC never respond. If a patch is dropped,
or overlooked it's up to me to nag people to please take a look. There's
no good way for me to find stuff adjacent to my area (it can be done, but
it takes a lot of work).
So you like it because you're used to it. I'm firmly convinced that the email
workflow works only because of the 30 years of toolings, work arounds, extra
scripts, extra tools, cult knowledge, and any number of other "living with the
poo, so best polish up" projects. It's horrible. It's like everybody has collective
Stockholm syndrome.
The peoople begging for a forge don't care what the forge is. Your philisophical
objections to one are blinding you to things like self-hosted gitea, gitlab, gerrit
which are light years ahead of this insane workflow.
I'm no spring chicken (I sent you patches, IIRC, when you and bruce were having
the great serial port bake off). I've done FreeBSD for the past 30 years and we have
none of that nonsense. The tracking isn't as exacting as Linux, sure. I'll grant. the
code review tools we've used over the years are good enough, but everybody
that's used them has ideas to make them better. We even accept pull requests
from github, but our source of truth is away from github. We've taken an all
of the above approach and it makes the project more approachable.In addition,
I can land reviewed and tested code in FreeBSD in under an hour (including the
review and acceptance testing process). This makes it way more efficient for me
to do things in FreeBSD than in QEMU where the turn around time is days, where
I have to wait for the one true pusher to get around to my pull request, where I have
to go through weeks long processes to get things done (and I've graduated to
maintainer status).
So the summary might be email is so 1970s, but the real problem with it is
that it requires huge learning curve. But really, it's not something any sane person would
design from scratch today, it has all these rules you have to cope with, many unwritten.
You have to hope that the right people didn't screw up their email filters. You have to
wait days or weeks for an answer, and the enthusiasm to contribute dies in that time.
A quick turnaround time is essential for driving enthusiasm for new committers in the
community. It's one of my failings in running FreeBSD's github experiment: it takes me
too long to land things, even though we've gone from years to get an answer to days to
weeks....
I studied the linux approach when FreeBSD was looking to improve it's git workflow. And
none of the current developers think it's a good idea. In fact, I got huge amounts of grief,
death threads, etc for even suggesting it. Everybody thought, to a person that as badly
as our hodge-podge of bugzilla, phabricator and cruddy git push hooks, it was lightyears
ahead of Linux's system and allowed us to move more quickly and produced results that
were good enough.
So, respectfully, I think Linux has succeed despite its tooling, not because of it. Other factors
have made it successful. The heroics that are needed to make it work are possible only
because there's a huge supply that can be wasted and inefficiently deployed and still meet
the needs of the project.
Warner