Re: Next steps from GTI TAC meeting on 2023-03-08 - Evaluate cost of glibc migration.

On Tue, May 23, 2023 at 07:34:52PM +0000, Joseph Myers wrote:
> > It's possible, but it is an empirical fact that permitting HTML messages
> > raises the amount of spam that goes through by several orders of magnitude.
> > Allowing it per-list is okay and normal (e.g. the list aimed at newbies and
> > people seeking occasional help). However, I think it is perfectly normal to
> > disallow it on development lists where one is already expected to follow a
> > fairly rigid set of rules.
> 
> The toolchain lists universally allow mail from non-subscribers, and I 
> think most can expect sometimes to be included in discussions involving 
> people who are not particularly active developers of that particular 
> project (but may still be relevant to include in that individual 
> discussion).
> 
> When allowing HTML through to the lists (with or without any form of 
> moderation) we should make sure public-inbox properly archives those 
> messages that include HTML.

Yes, that's always been the case -- public-inbox does not do any filtering, it
just archives whatever the mailing list allows through.

> > If you insist, though I still think this is the case of "everyone assumes that
> > someone else is paying attention to it." I am highly critical of setups that
> > fire messages into the ether in hopes that someone checks them. 
> 
> People do in practice monitor the commit emails.

Okay, if you insist -- after all, we do the same thing for all kernel commits.
I just find it a pretty terrible waste of resources, as I'm pretty sure 99% of
everyone who subscribes to that list has set things up to go to a folder that
they never check.

> > > I think those things *should* be happening on push - to prevent obviously 
> > > bad history getting onto master or release branches (at least) in the 
> > > first place.  For glibc, that's (apart from the non-fast-forward checks 
> > > and rejecting merge commits on branches meant to have linear history):
> > > 
> > > * Disallowing lines with trailing whitespace in certain files.
> > > 
> > > * Disallowing commits with a mailing list address as the author email 
> > > (even if your mailing list setup is designed to be DKIM-safe so author 
> > > emails don't need rewriting, people might still use "git am" with old 
> > > messages, so this remains relevant).
> > > 
> > > * Disallowing commit subject lines that look like a ChangeLog header.
> > > 
> > > * Disallowing single-word (or empty) commit subject lines.
> > 
> > In my view these all should be happening on the client as pre-commit checks,
> > not on the server. Any reason why they can't run on the client, e.g. via a
> > framework like https://pre-commit.com/ ?
> 
> A server can't ensure that the user's clone has any particular custom 
> configuration.

Okay, perhaps I'm not fully grokking the picture. How many people are able to
push to master/release branches? I was expecting it to be 1-2, maybe a handful
of people, but perhaps it's a much wider set of developers?

-K