| Message ID | 20230525182217.2280366-7-mmichels@redhat.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | OVN Release Policy Updates | 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 | fail | github build: failed |
On 5/25/23 20:22, Mark Michelson wrote: > The OVN team has had no concrete policy regarding when releases are > made for a given version. In the past, new releases have been made only > when something critical has been found, meaning that most bug fixes > applied to a given OVN version never end up in a release. > > This change proposes a monthly release per supported OVN version. > > Signed-off-by: Mark Michelson <mmichels@redhat.com> > --- > Documentation/internals/release-process.rst | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst > index 1f4b90143..0287795dc 100644 > --- a/Documentation/internals/release-process.rst > +++ b/Documentation/internals/release-process.rst > @@ -152,6 +152,12 @@ approximate: > | T + 6 | Sep 1, Mar 1, ... | Release version x.y.0 | > +---------------+---------------------+--------------------------------------+ > > +After the .0 release is created for a given OVN version, that version will have > +releases made every month until its support lifetime has concluded. If for some > +reason, no changes occur to a supported OVN version during a month, then no > +release will be made that month. Therefore, there is no guarantee about the > +exact number of releases to be expected for any given OVN version. > + > Release Calendar > ---------------- > It makes sense but (I think I may have mentioned this during an upstream meeting) can we automate the process? It's going to be 2 patches per release, 2 standard term releases + 2 LTS releases, release every month => 96 patches to ack throughout the year (unless my reasoning is wrong). Regards, Dumitru
On 5/26/23 08:45, Dumitru Ceara wrote: > On 5/25/23 20:22, Mark Michelson wrote: >> The OVN team has had no concrete policy regarding when releases are >> made for a given version. In the past, new releases have been made only >> when something critical has been found, meaning that most bug fixes >> applied to a given OVN version never end up in a release. >> >> This change proposes a monthly release per supported OVN version. >> >> Signed-off-by: Mark Michelson <mmichels@redhat.com> >> --- >> Documentation/internals/release-process.rst | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst >> index 1f4b90143..0287795dc 100644 >> --- a/Documentation/internals/release-process.rst >> +++ b/Documentation/internals/release-process.rst >> @@ -152,6 +152,12 @@ approximate: >> | T + 6 | Sep 1, Mar 1, ... | Release version x.y.0 | >> +---------------+---------------------+--------------------------------------+ >> >> +After the .0 release is created for a given OVN version, that version will have >> +releases made every month until its support lifetime has concluded. If for some >> +reason, no changes occur to a supported OVN version during a month, then no >> +release will be made that month. Therefore, there is no guarantee about the >> +exact number of releases to be expected for any given OVN version. >> + >> Release Calendar >> ---------------- >> > > It makes sense but (I think I may have mentioned this during an upstream > meeting) can we automate the process? It's going to be 2 patches per > release, 2 standard term releases + 2 LTS releases, release every month > => 96 patches to ack throughout the year (unless my reasoning is wrong). The basic mechanics of a release would be easy to automate. I already use a script provided by Ilya to create the release commits, send them to the mailing list, and merge the commits and create the tag. The things that currently cannot be automated are: 1) Acks for release patches. We currently post the patches to the mailing list and await acks before merging/tagging. We could potentially agree as a project that these commits could just be automatically created and pushed/tagged without developer acks. 2) Signing the tag. When I create OVN releases, I sign the tag with my GPG key. I'm not sure what a good automated substitute for this would be. 3) Updating ovn.org. For .0 releases, I typically will go through all the commits and keep a list of new features and performance enhancements. I then write these up on the release page. Automating this exact process would not be possible. However we could switch to a changelog style where we list all the commits that went into a given release. This would be easier to automate. For .1 releases, we shouldn't have new features or performance improvements. We should only have bug fixes. The changelog approach would fit for these types of releases well. > > Regards, > Dumitru >
On 5/30/23 22:22, Mark Michelson wrote: > On 5/26/23 08:45, Dumitru Ceara wrote: >> On 5/25/23 20:22, Mark Michelson wrote: >>> The OVN team has had no concrete policy regarding when releases are >>> made for a given version. In the past, new releases have been made only >>> when something critical has been found, meaning that most bug fixes >>> applied to a given OVN version never end up in a release. >>> >>> This change proposes a monthly release per supported OVN version. >>> >>> Signed-off-by: Mark Michelson <mmichels@redhat.com> >>> --- >>> Documentation/internals/release-process.rst | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/Documentation/internals/release-process.rst >>> b/Documentation/internals/release-process.rst >>> index 1f4b90143..0287795dc 100644 >>> --- a/Documentation/internals/release-process.rst >>> +++ b/Documentation/internals/release-process.rst >>> @@ -152,6 +152,12 @@ approximate: >>> | T + 6 | Sep 1, Mar 1, ... | Release version >>> x.y.0 | >>> >>> +---------------+---------------------+--------------------------------------+ >>> +After the .0 release is created for a given OVN version, that >>> version will have >>> +releases made every month until its support lifetime has concluded. >>> If for some >>> +reason, no changes occur to a supported OVN version during a month, >>> then no >>> +release will be made that month. Therefore, there is no guarantee >>> about the >>> +exact number of releases to be expected for any given OVN version. >>> + >>> Release Calendar >>> ---------------- >>> >> >> It makes sense but (I think I may have mentioned this during an upstream >> meeting) can we automate the process? It's going to be 2 patches per >> release, 2 standard term releases + 2 LTS releases, release every month >> => 96 patches to ack throughout the year (unless my reasoning is wrong). > > The basic mechanics of a release would be easy to automate. I already > use a script provided by Ilya to create the release commits, send them > to the mailing list, and merge the commits and create the tag. The > things that currently cannot be automated are: > > 1) Acks for release patches. We currently post the patches to the > mailing list and await acks before merging/tagging. We could potentially > agree as a project that these commits could just be automatically > created and pushed/tagged without developer acks. > If the process is fully automated I think it's fine to skip acks for these patches. > 2) Signing the tag. When I create OVN releases, I sign the tag with my > GPG key. I'm not sure what a good automated substitute for this would be. > I can't think of an alternative either. Maybe we're OK with one of the maintainers running everything (a script that would live in the repo) locally like today. That person would and just push the commits and signed tags directly without waiting for ACKs. We could try to add some validation after the fact, e.g., a GitHub action that runs after a tag is pushed. I don't know if that's good enough though. > 3) Updating ovn.org. For .0 releases, I typically will go through all > the commits and keep a list of new features and performance > enhancements. I then write these up on the release page. Automating this > exact process would not be possible. However we could switch to a > changelog style where we list all the commits that went into a given > release. This would be easier to automate. For .1 releases, we shouldn't > have new features or performance improvements. We should only have bug > fixes. The changelog approach would fit for these types of releases well. > IMO that's OK. >> >> Regards, >> Dumitru >> >
diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst index 1f4b90143..0287795dc 100644 --- a/Documentation/internals/release-process.rst +++ b/Documentation/internals/release-process.rst @@ -152,6 +152,12 @@ approximate: | T + 6 | Sep 1, Mar 1, ... | Release version x.y.0 | +---------------+---------------------+--------------------------------------+ +After the .0 release is created for a given OVN version, that version will have +releases made every month until its support lifetime has concluded. If for some +reason, no changes occur to a supported OVN version during a month, then no +release will be made that month. Therefore, there is no guarantee about the +exact number of releases to be expected for any given OVN version. + Release Calendar ----------------
The OVN team has had no concrete policy regarding when releases are made for a given version. In the past, new releases have been made only when something critical has been found, meaning that most bug fixes applied to a given OVN version never end up in a release. This change proposes a monthly release per supported OVN version. Signed-off-by: Mark Michelson <mmichels@redhat.com> --- Documentation/internals/release-process.rst | 6 ++++++ 1 file changed, 6 insertions(+)