Retrospective on glibc 2.34 and glibc 2.35 release.

[Stafford Horne]

On Wed, Feb 09, 2022 at 09:57:42AM -0500, Carlos O'Donell via Libc-alpha wrote:
> Community,
> 
> I was the release manager for 2.34 and 2.35, and in retrospect I have
> played the hard ABI deadline too loose for my own liking, and I think
> this causes additional stress and work at the last minute that doesn't
> help the project.
> 
> If I think about improving the release process it is to come back to
> a harder ABI freeze deadline within the first week of the freeze.
> That is to say that it looks like this:
> 
> 1st week
> - Freeze ABI.
> - Review outstanding patches that change ABI that we want in the release.
> - Be critical about which can be resolved within the 1st week.
> - Move all others that need more time to the next release.
> 
> As RM I ran ABI changes very late into 2.34 and 2.35, and while I'm happy
> with the results of the release, I'm not happy with the process. I consider
> it my own failure as RM for not hardening that release sooner. The time boxed
> release for glibc supports downstreams that have aligned their release windows
> against our ABI changes, and last minute ABI changes are not good for anyone.
> 
> In order to support these ABI changes I wonder if we don't need a specific
> window within the release like "Month 1: ABI" where we focus on this theme
> of getting new ABIs into the first month of development? There is a similarity
> here with respect to gcc's staged development.
> 
> Thoughts?

Re, ABI freeze I think it sounds OK to me and it gives port maintainers time to
test.

Regarding port testing, I usually test with GCC mainline.  During the test phase
it seemed to coincide with some big changes in GCC which broke things for a lot
of architectures.  This made it hard to test, and actually I am just getting the
OpenRISC port to run the test suite now.

 PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153

Do we see any possiblity to sync our 1-month phase with a stable GCC period?

-Stafford