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

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 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.

Collin

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