[COFF] Re: [TUHS] Re: SunOS 4 in 2024

[COFF] Re: [TUHS] Re: SunOS 4 in 2024

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 6740 bytes --]

[ moved to coff ]

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

[-- Attachment #2: Type: text/html, Size: 8022 bytes --]