| Message ID | 20241028102218.185208-1-dceara@redhat.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [ovs-dev] Documentation: Clarify OVS submodule bump strategy. | expand |
| Context | Check | Description |
|---|---|---|
| ovsrobot/apply-robot | success | apply and check: success |
| ovsrobot/github-robot-_Build_and_Test | success | github build: passed |
| ovsrobot/github-robot-_ovn-kubernetes | success | github build: passed |
On Mon, Oct 28, 2024 at 11:22 AM Dumitru Ceara <dceara@redhat.com> wrote: > The documentation was a bit unclear regarding how the submodule bumps > happen. Explicitly document that we aim to eventually point the > submodule to a stable OVS release on stable OVN branches. > > Reported-by: Vladislav Odintsov <vlodintsov@k2.cloud> > Reported-at: > https://mail.openvswitch.org/pipermail/ovs-dev/2024-October/417702.html > Signed-off-by: Dumitru Ceara <dceara@redhat.com> > --- > Documentation/internals/ovs_submodule.rst | 62 +++++++++++++---------- > 1 file changed, 35 insertions(+), 27 deletions(-) > > diff --git a/Documentation/internals/ovs_submodule.rst > b/Documentation/internals/ovs_submodule.rst > index 51f2a8c758..5b296ac6e1 100644 > --- a/Documentation/internals/ovs_submodule.rst > +++ b/Documentation/internals/ovs_submodule.rst > @@ -53,44 +53,48 @@ Submodules for releases > ----------------------- > > For OVN releases, it is preferred for the OVS submodule to point to a > stable > -release branch of OVS. Therefore, as part of the release process for OVN, > we > -will point the submodule to the latest stable branch of OVS before > releasing. > +release of OVS. Therefore, as part of the release process for OVN, we will > +point the submodule to the latest stable version of OVS before releasing. > > The exception to this is if the current OVS submodule is pointing to a > commit > -that is not in a current stable branch of OVS. In that case, the submodule > +that is not in a current stable release of OVS. In that case, the > submodule > will continue to point to that particular commit. We may, however, bump > the > -submodule to the next stable branch of OVS at a later time. > +submodule to the next stable version of OVS at a later time. > > As an example, let's assume that the OVS commit history looks something > like > this in the main branch: > > :: > > - (Newest) > - Commit 3 > - | > - | > - Commit 2 (used to create OVS branch-Y) > - | > - | > - Commit 1 > - (Oldest) > + (Newest) > + Commit 4 > + | > + | > + Commit 2 ------------------------------- Commit 3 > + (used to create OVS branch-Y) (latest stable release on OVS > branch-Y) > + | > + | > + Commit 1 > + (Oldest) > > Let's say that we are planning to release OVN version X. At this point, > the > -submodule is pointing to Commit 1. As part of the release process, we > will bump > -the OVS submodule in OVN to point to Commit 2, or more likely the tip of > OVS > -branch-Y. This way, the released version of OVN is based on a stable > release > -branch of OVS, and it has all of the necessary changes that we require. > - > -What if the OVS submodule currently points to Commit 3, though? There is > no > -stable branch that exists after this commit. In this case, we have two > choices: > - > -# Create OVN release X and point the OVS submodule to Commit 3. At a later > - time, if it makes sense to do so, we may bump the submodule to OVS > branch-Z > - when it is released, since Commit 3 will be included in that branch. > -# If Commit 3 is a bug fix in OVS, then we can try to ensure that Commit > 3 gets > - backported to OVS branch-Y, and then point the submodule commit to the > tip of > - OVS branch-Y. > +submodule is pointing to Commit 1. As part of the release process, we will > +bump the OVS submodule in OVN to point to Commit 2, or more likely the > latest > +OVS release on branch-y (Commit 3). This way, the released version of OVN > is > +based on a stable release of OVS, and it has all of the necessary changes > +that we require. > + > +What if the OVS submodule currently points to Commit 4, though? There is > no > +stable OVS release that exists after this commit. In this case, we have > two > +choices: > + > +# Create OVN release X and point the OVS submodule to Commit 4. At a later > + time, if it makes sense to do so, we may bump the submodule to the new > + OVS stable release on branch-Z when it is released, since Commit 4 will > + be included in that branch. > +# If Commit 4 is a bug fix in OVS, then we can try to ensure that Commit > 4 gets > + backported to OVS branch-Y, and then point the submodule commit to the > next > + stable release of OVS on branch-Y. > > For choice 1, the decision of whether to update the submodule commit to > OVS > branch-Z is based on several factors. > @@ -101,6 +105,10 @@ branch-Z is based on several factors. > submodule? > - Is there risk in updating the submodule? > > +For choice 2, it's preferable to bump to a new stable OVS release but if > +the bug fix is urgent maintainers may decide to temporarily point the OVS > +submodule bump to the tip of brach-Y. > + > For an LTS of OVN, we might update the submodule several times during its > lifetime as more new OVS branches are released. For a standard release, > it is > less likely that we will update the OVS submodule during the standard > release's > -- > 2.46.2 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > Looks good to me, thanks. Reviewed-by: Ales Musil <amusil@redhat.com>
On 12/10/24 12:33 PM, Ales Musil wrote: > On Mon, Oct 28, 2024 at 11:22 AM Dumitru Ceara <dceara@redhat.com> wrote: > >> The documentation was a bit unclear regarding how the submodule bumps >> happen. Explicitly document that we aim to eventually point the >> submodule to a stable OVS release on stable OVN branches. >> >> Reported-by: Vladislav Odintsov <vlodintsov@k2.cloud> >> Reported-at: >> https://mail.openvswitch.org/pipermail/ovs-dev/2024-October/417702.html >> Signed-off-by: Dumitru Ceara <dceara@redhat.com> >> --- >> Documentation/internals/ovs_submodule.rst | 62 +++++++++++++---------- >> 1 file changed, 35 insertions(+), 27 deletions(-) >> >> diff --git a/Documentation/internals/ovs_submodule.rst >> b/Documentation/internals/ovs_submodule.rst >> index 51f2a8c758..5b296ac6e1 100644 >> --- a/Documentation/internals/ovs_submodule.rst >> +++ b/Documentation/internals/ovs_submodule.rst >> @@ -53,44 +53,48 @@ Submodules for releases >> ----------------------- >> >> For OVN releases, it is preferred for the OVS submodule to point to a >> stable >> -release branch of OVS. Therefore, as part of the release process for OVN, >> we >> -will point the submodule to the latest stable branch of OVS before >> releasing. >> +release of OVS. Therefore, as part of the release process for OVN, we will >> +point the submodule to the latest stable version of OVS before releasing. >> >> The exception to this is if the current OVS submodule is pointing to a >> commit >> -that is not in a current stable branch of OVS. In that case, the submodule >> +that is not in a current stable release of OVS. In that case, the >> submodule >> will continue to point to that particular commit. We may, however, bump >> the >> -submodule to the next stable branch of OVS at a later time. >> +submodule to the next stable version of OVS at a later time. >> >> As an example, let's assume that the OVS commit history looks something >> like >> this in the main branch: >> >> :: >> >> - (Newest) >> - Commit 3 >> - | >> - | >> - Commit 2 (used to create OVS branch-Y) >> - | >> - | >> - Commit 1 >> - (Oldest) >> + (Newest) >> + Commit 4 >> + | >> + | >> + Commit 2 ------------------------------- Commit 3 >> + (used to create OVS branch-Y) (latest stable release on OVS >> branch-Y) >> + | >> + | >> + Commit 1 >> + (Oldest) >> >> Let's say that we are planning to release OVN version X. At this point, >> the >> -submodule is pointing to Commit 1. As part of the release process, we >> will bump >> -the OVS submodule in OVN to point to Commit 2, or more likely the tip of >> OVS >> -branch-Y. This way, the released version of OVN is based on a stable >> release >> -branch of OVS, and it has all of the necessary changes that we require. >> - >> -What if the OVS submodule currently points to Commit 3, though? There is >> no >> -stable branch that exists after this commit. In this case, we have two >> choices: >> - >> -# Create OVN release X and point the OVS submodule to Commit 3. At a later >> - time, if it makes sense to do so, we may bump the submodule to OVS >> branch-Z >> - when it is released, since Commit 3 will be included in that branch. >> -# If Commit 3 is a bug fix in OVS, then we can try to ensure that Commit >> 3 gets >> - backported to OVS branch-Y, and then point the submodule commit to the >> tip of >> - OVS branch-Y. >> +submodule is pointing to Commit 1. As part of the release process, we will >> +bump the OVS submodule in OVN to point to Commit 2, or more likely the >> latest >> +OVS release on branch-y (Commit 3). This way, the released version of OVN >> is >> +based on a stable release of OVS, and it has all of the necessary changes >> +that we require. >> + >> +What if the OVS submodule currently points to Commit 4, though? There is >> no >> +stable OVS release that exists after this commit. In this case, we have >> two >> +choices: >> + >> +# Create OVN release X and point the OVS submodule to Commit 4. At a later >> + time, if it makes sense to do so, we may bump the submodule to the new >> + OVS stable release on branch-Z when it is released, since Commit 4 will >> + be included in that branch. >> +# If Commit 4 is a bug fix in OVS, then we can try to ensure that Commit >> 4 gets >> + backported to OVS branch-Y, and then point the submodule commit to the >> next >> + stable release of OVS on branch-Y. >> >> For choice 1, the decision of whether to update the submodule commit to >> OVS >> branch-Z is based on several factors. >> @@ -101,6 +105,10 @@ branch-Z is based on several factors. >> submodule? >> - Is there risk in updating the submodule? >> >> +For choice 2, it's preferable to bump to a new stable OVS release but if >> +the bug fix is urgent maintainers may decide to temporarily point the OVS >> +submodule bump to the tip of brach-Y. >> + >> For an LTS of OVN, we might update the submodule several times during its >> lifetime as more new OVS branches are released. For a standard release, >> it is >> less likely that we will update the OVS submodule during the standard >> release's >> -- >> 2.46.2 >> >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> >> > Looks good to me, thanks. > > Reviewed-by: Ales Musil <amusil@redhat.com> > Thanks, Ales! Applied to main. Regards, Dumitru
diff --git a/Documentation/internals/ovs_submodule.rst b/Documentation/internals/ovs_submodule.rst index 51f2a8c758..5b296ac6e1 100644 --- a/Documentation/internals/ovs_submodule.rst +++ b/Documentation/internals/ovs_submodule.rst @@ -53,44 +53,48 @@ Submodules for releases ----------------------- For OVN releases, it is preferred for the OVS submodule to point to a stable -release branch of OVS. Therefore, as part of the release process for OVN, we -will point the submodule to the latest stable branch of OVS before releasing. +release of OVS. Therefore, as part of the release process for OVN, we will +point the submodule to the latest stable version of OVS before releasing. The exception to this is if the current OVS submodule is pointing to a commit -that is not in a current stable branch of OVS. In that case, the submodule +that is not in a current stable release of OVS. In that case, the submodule will continue to point to that particular commit. We may, however, bump the -submodule to the next stable branch of OVS at a later time. +submodule to the next stable version of OVS at a later time. As an example, let's assume that the OVS commit history looks something like this in the main branch: :: - (Newest) - Commit 3 - | - | - Commit 2 (used to create OVS branch-Y) - | - | - Commit 1 - (Oldest) + (Newest) + Commit 4 + | + | + Commit 2 ------------------------------- Commit 3 + (used to create OVS branch-Y) (latest stable release on OVS branch-Y) + | + | + Commit 1 + (Oldest) Let's say that we are planning to release OVN version X. At this point, the -submodule is pointing to Commit 1. As part of the release process, we will bump -the OVS submodule in OVN to point to Commit 2, or more likely the tip of OVS -branch-Y. This way, the released version of OVN is based on a stable release -branch of OVS, and it has all of the necessary changes that we require. - -What if the OVS submodule currently points to Commit 3, though? There is no -stable branch that exists after this commit. In this case, we have two choices: - -# Create OVN release X and point the OVS submodule to Commit 3. At a later - time, if it makes sense to do so, we may bump the submodule to OVS branch-Z - when it is released, since Commit 3 will be included in that branch. -# If Commit 3 is a bug fix in OVS, then we can try to ensure that Commit 3 gets - backported to OVS branch-Y, and then point the submodule commit to the tip of - OVS branch-Y. +submodule is pointing to Commit 1. As part of the release process, we will +bump the OVS submodule in OVN to point to Commit 2, or more likely the latest +OVS release on branch-y (Commit 3). This way, the released version of OVN is +based on a stable release of OVS, and it has all of the necessary changes +that we require. + +What if the OVS submodule currently points to Commit 4, though? There is no +stable OVS release that exists after this commit. In this case, we have two +choices: + +# Create OVN release X and point the OVS submodule to Commit 4. At a later + time, if it makes sense to do so, we may bump the submodule to the new + OVS stable release on branch-Z when it is released, since Commit 4 will + be included in that branch. +# If Commit 4 is a bug fix in OVS, then we can try to ensure that Commit 4 gets + backported to OVS branch-Y, and then point the submodule commit to the next + stable release of OVS on branch-Y. For choice 1, the decision of whether to update the submodule commit to OVS branch-Z is based on several factors. @@ -101,6 +105,10 @@ branch-Z is based on several factors. submodule? - Is there risk in updating the submodule? +For choice 2, it's preferable to bump to a new stable OVS release but if +the bug fix is urgent maintainers may decide to temporarily point the OVS +submodule bump to the tip of brach-Y. + For an LTS of OVN, we might update the submodule several times during its lifetime as more new OVS branches are released. For a standard release, it is less likely that we will update the OVS submodule during the standard release's
The documentation was a bit unclear regarding how the submodule bumps happen. Explicitly document that we aim to eventually point the submodule to a stable OVS release on stable OVN branches. Reported-by: Vladislav Odintsov <vlodintsov@k2.cloud> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2024-October/417702.html Signed-off-by: Dumitru Ceara <dceara@redhat.com> --- Documentation/internals/ovs_submodule.rst | 62 +++++++++++++---------- 1 file changed, 35 insertions(+), 27 deletions(-)