Re: Relevancy of branch locks during the release process

Daniel de la Rosa

Hello all

Since we don't have any objections to this, I'm going to remove this step from Sulfur SR2 checklist and just pick an RC 


On Tue, Aug 9, 2022 at 2:03 PM Robert Varga <nite@...> wrote:
On 09/08/2022 15:44, Guillaume Lambert via wrote:
> Hello
> As discussed during the TSC meeting of 7th July
> <>,
> I'd like to challenge the relevancy of branch locks during releases
> processes.
> In my opinion they have more cons than pros today.
> I agree they used to be meaningful in the past to avoid potential
> overlaps and incoherence.
> But it was a time when many active projects and committers were taking
> part to the release.
> I am not convinced the size of the community still justifies such a
> process today.
> And since most active projects and their committers are quite experienced,
> I am quite convinced that branch locks more brake the release than they
> help.
> I think especially of repeated situations such as when downstream
> projects face
> bugs in their upstream dependencies and have to wait for the branch to
> be unlocked
> to update their poms and trigger stage-releases jobs.
> But I might have missed some aspects.
> So I would like to have other community members'opinion on the topic.

I tend to agree. The branch lock is relevant only to MSI projects at
this point. Those projects do not even have what I would call active
committers (with the notable exception on OFP).

Meanwhile the way branch-lock works is quite wrong, as it should only be
affecting MSI projects (e.g. those in autorelease.git), but affects
everyone (who happens to match their branch naming).

Ditch it for all I care.


Join { to automatically receive all group messages.