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