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

On Tue, 23 May 2023, Konstantin Ryabitsev wrote:

> > (I consider it important that we do *not* insist on contributors meeting a 
> > shibboleth of sending plain-text email before they can interact with our 
> > mailing lists, especially for user lists such as libc-help - we should be 
> > friendly to people sending email in the ordinary form they are used to 
> > using today even if we might rather they didn't send HTML email - we 
> > shouldn't impose that view of proper email on them.)
> 
> 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.

> 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.

> There are better ways of doing it that don't generate email, e.g.:

For projects using email for development, commit emails have the obvious 
advantage of not adding yet another different system to watch.

> > What about denying merge commits on master and release branches?
> 
> I'm not sure I understand -- you mean, all commits must have a single parent
> and have a fully linear structure?

Yes.  We use linear history (on master and release branches) for GCC and 
glibc.  (Shared development branches use merge commits for merging master 
into the branch.  Ones in the users and vendors namespaces might use 
merges or might be rebased, depending on the policy for the individual 
branch.)

> Doesn't that make it super difficult to resolve conflicts?

No.

> > 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.  We have some optional configuration 
(gcc-git-customization.sh), but there's no requirement to use it.  
Checking on push is much more reliable than expecting custom configuration 
on the user's side.

-- 
Joseph S. Myers
[email protected]