Re: Suggestion: Changes to release process, release from branch

Sam James <[email protected]> Mon, 27 Jul 2026 06:39:32 +0100
Newsgroups	gmane.comp.lib.glibc.alpha
Organization	Gentoo
Message-ID	<[email protected]>
Collin Funk <[email protected]> writes:

> Sam James <[email protected]> writes:
>
>>> Hello everyone, 
>>>
>>> even though the next release is now still quite far away, I would like to already
>>> propose some (in my opinion) minor changes to the release process:
>>>
>>> * No changes to the procedure during soft freeze and freeze, no changes to basic
>>>   timetable
>>>
>>> * With the hard freeze two weeks before nominal/last possible release date, 
>>>   the release branch is made, and the master branch is re-opened for development.
>>>
>>> * The release branch is treated as "machine testing, only important bugfixes, 
>>>   minimal activity", basically as before master during that period.
>>>
>>> * Once things are OK, the release is cut from the release branch.
>>>
>>> This has several advantages. What comes to my mind:
>>>
>>> * The master branch is open earlier for the backlog of accumulated patches again.
>>>
>>> * There is less chance of stray commits being pushed at last minute.
>>>
>>> * Distros can treat the branch point as a release candidate for testing purposes.
>>>   We could even add a corresponding tag.
>>>
>>> * Last but not least, this means we'd be handling releases similar to gcc and
>>>   binutils.
>>>
>>> What do you think?
>>
>> Yes please, for all the reasons you've mentioned.
>>
>> No downsides come to mind, other than perhaps a caveat which gcc
>> applies: they ask people not to apply huge changes as soon as master
>> opens / the branch is made, so that backports can be done without too
>> much hassle (and so the things to-be-backported are effectively the same
>> as what was on master, and so received some testing). But that's not a
>> big deal I think.
>
> Sounds good to me as well.
>
> I had meant to do more testing with Gnulib this release, but got side
> tracked. Sorry about that... I would have hoped to catch the
> posix_spawn_file_actions_addchdir issue pre-release [1], to avoid
> distributions needing to patch things or a new m4 release being made.

I feel a little guilty too. I only started using glibc from master a few
days ago which is much later than I normally do in the cycle.

It is what it is. The change to use all-modules + branching will help
avoid this in future I think.

>
> I assume that Fedora Rawhide, or some other distribution, would likely
> use the release branch pre-release for testing. That would make things
> easy to test.

Yeah, I think Rawhide even often ships a snapshot for a little while
before the release. I don't know if that happened this time or if they
just didn't catch this by chance?

>
> Collin
>
> [1] https://inbox.sourceware.org/libc-alpha/3774961.atdPhlSkOF@cagnes/T/#mf1b386da6723b16d2df5b99a8d3c40874c6979cf

sam
signature.asc (application/pgp-signature, 418 B)