Retrospective on glibc 2.34 and glibc 2.35 release.

[Carlos O'Donell <carlos@redhat.com>]

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?

-- 
Cheers,
Carlos.