1. TSC
  2. Topics

Relevancy of branch locks during the release process

Guillaume Lambert
 

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.

Best Regards

Guillaume


De : LAMBERT Guillaume INNOV/NET
Envoyé : lundi 8 août 2022 17:45
À : Daniel de la Rosa; TSC
Objet : RE: Code freeze for Sulfur SR2
 

Hi Daniel


You are right.
For the moment, I assume that we can still process as before once again.

Bacuase we didn't close the debate about this point.
I still have to send an email with more details to trigger it.
Most people including myself were on vacation just after this meeting.
I can do it soon now that everyone is back.


Best Regards

Guillaume



De : Daniel de la Rosa <ddelarosa0707@...>
Envoyé : lundi 8 août 2022 17:00:00
À : TSC; LAMBERT Guillaume INNOV/NET
Objet : Code freeze for Sulfur SR2
 
Hello Guillaume and all,  I just remembered that we wanted to shorten the code freeze for new releases, as it is documented in our TSC meeting minutes from July 7th. So based on this, when do we want to announce and/or start the code freeze for Sulfur SR2? 

Please let me know here or directly in the checklist

--
Daniel de la Rosa
ODL Release Manager

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Robert Varga
 

On 09/08/2022 15:44, Guillaume Lambert via lists.opendaylight.org wrote:
Hello
As discussed during the TSC meeting of 7th July <https://wiki.opendaylight.org/display/ODL/2022-07-07+TSC+Minutes>,
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.

Regards,
Robert

OpenPGP_signature

OpenPGP_signature

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 


Thanks 

On Tue, Aug 9, 2022 at 2:03 PM Robert Varga <nite@...> wrote:
On 09/08/2022 15:44, Guillaume Lambert via lists.opendaylight.org wrote:
> Hello
>
>
> As discussed during the TSC meeting of 7th July
> <https://wiki.opendaylight.org/display/ODL/2022-07-07+TSC+Minutes>,
> 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.

Regards,
Robert

1 - 3 of 3