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

On Wed, 24 May 2023, Carlos O'Donell wrote:

> (1) CVS/SVN read-only repositories.
> 
> If the GCC community decides not to keep the read-only CVS and SVN 
> repositories in favour of the git repository with all the currently 
> converted history, then does this remove some of the more complex git 
> hooks?

No.  The point of logic that looks for From-SVN: (and thus requires no new 
commits to have a line in the commit message starting From-SVN:) is 
precisely to convert from an SVN commit reference in e.g. an old email or 
bug report to a corresponding git commit, *without* referring to the 
read-only SVN repository.  I'm expecting the read-only repository to be 
made available as a downloadable tarball/dump rather than continuing to be 
served with the SVN protocol.

> (2) Changelog invariant checking.
> 
> ChangeLog generation as I understand it is a concatenation of the commit 
> message ChangeLog snippet (Nightly update_version_git), and already 
> would need manual editing if someone makes a mistake e.g. 
> 32582c190b91287a0d1239162333f5ad0ac81e72 in gcc where Jakub adjusts the 
> entries? Does dropping this hook create more work for you and Jakub and 
> Richie to udpate malformed ChangeLog entries for the day? Who gets email 
> if the update fails?

Manual work is rarely needed, generally only if there is a bug in the hook 
that means the hook fails to reject a commit but the nightly ChangeLog 
generation falls over (see the total of seven commits listed in 
git_update_version.py:IGNORED_COMMITS that resulted in such issues).  
Almost all the time when someone makes a mistake in the commit message 
formatting that would affect that nightly generation, it's caught by the 
hook and never gets into the repository.

-- 
Joseph S. Myers
[email protected]