Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)
Adhemerval Zanella
adhemerval.zanella@linaro.org
Tue Jan 12 12:02:47 GMT 2021
On 12/01/2021 08:49, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>>> In fact, I want to start a conversation on whether we should
>>> reconsider this aspect of the release freeze process. The freeze
>>> process made sense 7-8 years ago when we were a smaller contributor
>>> group and all of us would be focused on bug fixes and testing during
>>> that time and there was little scope of us being able to review new
>>> patches during that time. We are a significantly larger group now, so
>>> does it make sense to change the process to make the release branch at
>>> the freeze point and continue development on master? That way we
>>> potentially allow development to continue on the master branch while
>>> the release branch stabilizes. Tentatively, the freeze point would
>>> look like this:
>>>
>>> 1. RM calls freeze and asks everyone to stop commits to the repo
>>> 2. Make a release/2.x/master
>>> 3. Update VERSION to 2.x+1.9000 in master
>>> 4. Announce release branch on libc-alpha and reopen development
>>>
>>> From this point on, development continues as normal on master. For
>>> inclusion in release/2.x/master, RM approval is necessary.
>>
>> I though about that and the drawback of this procedure is we will either
>> will have to tag the release branch itself or the tag in master will
>> be incomplete.
>
> OpenJDK puts fixes on the release branch and merges the branch regularly
> into the mainline branch. This way, the release tag will also end up on
> the mailine branch.
We will need to layout the merge strategies, but this seems to be used for
multiple projects (specially when community has a more active development).
I think we can discuss this for new release, since we will need to proper
document and change the release wiki page.
More information about the Libc-alpha
mailing list