From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id 0079525E93 for ; Thu, 14 Mar 2024 15:58:36 +0100 (CET) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 195DC428D3; Fri, 15 Mar 2024 00:58:35 +1000 (AEST) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by minnie.tuhs.org (Postfix) with ESMTPS id EBF8C428CB for ; Fri, 15 Mar 2024 00:58:27 +1000 (AEST) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a467d8efe78so7958666b.3 for ; Thu, 14 Mar 2024 07:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1710428306; x=1711033106; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=h24vzxFrIBUUEhZ+XosuiLg4Hwt6wOmkwBpzUvT4vAc=; b=n45HipyMzyUEFzpZPR2k/ONZlyYDw4nkyQKhtwAF3gq4prOWKrO9gcolO5/PxZhK59 khCqO+IH+lbv8WmSSmoC6W4EYlMjhfnK4dD+mfQyvRwntjk+R9cHTrApVsQhLlcuORx1 0wPgdDWcOIA45lICpfFPMQ8sRTO42bnWbfDli+bSyBQuPUxc1+laVlWQru01Xiturcs9 8Wtj6sIGjOdwxMQkK2Z0Rtab2GNALpFqDT9WAEM5dx/8DO6DRwr1mvRA4mnhhZTkattj S8drHlmkUdIrrSEnCHnQngsrcHYOgpc3ORhT0ck2Mow0v9+aohbGsf2AMk9BXf+XIKuY jDlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710428306; x=1711033106; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=h24vzxFrIBUUEhZ+XosuiLg4Hwt6wOmkwBpzUvT4vAc=; b=dkQFjoi1kGrKdGOTphUMobGv0DugZm6u+MEo8vN5eK+yOb/I1SKc8mcqb+XCtyxcz7 qU9bGH2SZbLnM2CgYv04MG3JMH4O19QhjI4HKp8bVoYtu4lfmgG+txK5Oz5P2H6wgcLf 83fMyK7azwlasHztqyLBlSoKq4Woygt+Nyed/WnCKLE1DQjULHPY3lTPAfmhFTGFRchw 3pAYW/IfR/BTw+3LpyXKTzXq6QvqidALvdmkS5g6qIJ6fVi+4ukEzGJsickikNS83Ngd VWWVQ9y2QCZ3oHk+C8C3R6Hn8wyICHQWYwvVbre/2t3viDsmIn5JrtL6QboPWFsOdrO/ J+yw== X-Forwarded-Encrypted: i=1; AJvYcCV4A9zDa7nVKfAdubiTzPmRqIM08G8tmfoTQ2FmXhyL2dcin6BNUrHiX63YqWl9fEETLaejGbRNTycsZkkS X-Gm-Message-State: AOJu0YzPT9jKwEC7hsi7QVv8GshK88u0M7lSTEHYH2aAGFvWgfvq1rgc BXzhFnps/3sLmqI2RbZrx0CEvlBD5MDfRkhBYuj/GUtLzcG0MICIbDN/IBaqeFbZfy8FAfKuUdP kQNREQ6ZUjW2knRxZkvVjzi2ZjAHgdGP8eL5E1VAdWqs8jqIsH+s= X-Google-Smtp-Source: AGHT+IFuGxttlhxHq1YDcgNeevgsU7E7LRt8AmOJuvLF+DrRanu6VHCL+uwfunG/YYYNU056nAWMCaJ4twf+7uzuy9c= X-Received: by 2002:a17:907:119b:b0:a45:f6de:ed18 with SMTP id uz27-20020a170907119b00b00a45f6deed18mr1259534ejb.33.1710428306218; Thu, 14 Mar 2024 07:58:26 -0700 (PDT) MIME-Version: 1.0 References: <87h6h93e4q.fsf@gmail.com> <87zfv11w1u.fsf@gmail.com> <20240314134945.GC143836@mit.edu> In-Reply-To: <20240314134945.GC143836@mit.edu> From: Warner Losh Date: Thu, 14 Mar 2024 08:58:15 -0600 Message-ID: To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary="0000000000009b3c030613a01fd0" Message-ID-Hash: IDS5RVERPX5UB7MKSCTSG5EWEQR27RSJ X-Message-ID-Hash: IDS5RVERPX5UB7MKSCTSG5EWEQR27RSJ X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Alexis , Computer Old Farts Followers X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: [TUHS] Re: SunOS 4 in 2024 List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000009b3c030613a01fd0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [ moved to coff ] On Thu, Mar 14, 2024 at 7:49=E2=80=AFAM Theodore Ts'o 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 wa= s 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, extr= a 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 request= s 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 t= o 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 --0000000000009b3c030613a01fd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[ moved to coff ]

On Thu, Mar 14, 2024 at 7:49=E2=80= =AFAM Theodore Ts'o <tytso@mit.edu<= /a>> wrote:
O= n 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,<= br> > another community on platform Y, another community on platform Z
> .... Whereas, for example, the 'Rocksolid Light' BBS/forum sof= tware
> 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.=C2=A0 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.=C2=A0 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<= br> up-and-coming programmers, we should meet them were they were at.=C2=A0 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.=C2=A0 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.=C2=A0 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.
<= div>
email based flows are horrible. Absolutely the worst. Th= ey are impossible
to manage. You can't subscribe to them w/o = insane email filtering rules,
you can't discover patches or l= ost patches easily. There's no standard way
to do something a= s 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= =C2=A0to 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
<= div>to CC on the patches. You have to look at the maintainers file, which i= s often
stale and many of the people you CC never respond. If a p= atch 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&= #39;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
<= div>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. You= r 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 grea= t 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 a= s Linux, sure. I'll grant. the
code review tools we've us= ed 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.=C2=A0 We've t= aken an all
of the above approach and it makes the project more a= pproachable.In addition,
I can land reviewed and tested code in F= reeBSD in under an hour (including the
review and acceptance test= ing process). This makes it way more efficient for me
to do thing= s 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 do= ne (and I've graduated to
maintainer status).

<= /div>
So the summary might be email is so 1970s, but the real problem w= ith it is
that it requires huge learning curve. But really, it= 9;s not something any sane person would
design from scratch today= , it has all these rules you have to cope with, many unwritten.
Y= ou have to hope that the right people didn't screw up their email filte= rs. You have to
wait days or weeks for an answer, and the enthusi= asm to contribute dies in that time.
A quick turnaround time is e= ssential for driving enthusiasm for new committers in the
communi= ty. 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 i= t's git workflow. And
none of the current developers thin= k it's a good idea. In fact, I got huge amounts of grief,
dea= th 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 g= ood enough.

So, respectfully, I think Linux has su= cceed despite its tooling, not because of it. Other factors
have = made it successful. The heroics that are needed to make it work are possibl= e only
because there's a huge supply that can be wasted a= nd inefficiently deployed and still meet
the needs of the project= .

Warner
--0000000000009b3c030613a01fd0--