Re: Retrospective on glibc 2.34 and glibc 2.35 release.

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

On 09/02/2022 20:27, 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.

I concur with Joseph; the process as we defined it is not broken, we 
were only lax in implementing it.  You're not the sole person to blame 
either IMO; we share blame because all of us let it slide for various 
reasons.  I would normally have called you out for letting the freeze 
slip but I'm a hypocrite ;)  I was glad that it slid for 2.34 because it 
allowed me to drop malloc hooks and similarly we got some needed ABI 
changes in at the last moment in 2.35 and so far it doesn't look like we 
had any fallout from it.

We just need to make sure that we put a hard freeze on approving ABI 
changes beyond the freeze deadline and then as Joseph suggested, 
consider backing out ABI changes that continue to be broken during the 
last couple of weeks of the freeze.

The one concern I have about the freeze period though is that once a 
year it descends on us during the year-end holidays.  Getting reviews 
during that period has always been hard, which means that the freeze is 
implicitly a couple of weeks earlier for anyone who doesn't have enough 
leverage within the community to get reviews for their patches.  I 
wonder if there's scope for a 2 week shift in our schedule so that we 
freeze on 15th Jan and 15th Jul and release on 15th Feb and 15th Aug.

Thanks,
Siddhesh