[ovs-dev] [PATCH RFC 2/2] release-process: LTS transition period and policy for unmaintained branches.

[Flavio Leitner]

On Wed, Sep 16, 2020 at 01:09:29PM +0200, Ilya Maximets wrote:
> On 9/7/20 6:27 PM, Flavio Leitner wrote:
> > On Thu, Sep 03, 2020 at 04:20:53PM +0200, Ilya Maximets wrote:
> >> On 8/28/20 3:55 PM, Flavio Leitner wrote:
> >>> On Tue, Aug 25, 2020 at 02:24:11PM +0200, Ilya Maximets wrote:
> >> Maybe something like this:
> >>
> >> """
> >> At most three release branches are formally maintained at any given time: the
> >> latest release, the latest release designed as LTS and a previous LTS release
> >> during the transition period.  An LTS release is one that the OVS project has
> >> designated as being maintained for a longer period of time.
> >> Currently, an LTS release is maintained until the next major release after the
> >> new LTS is chosen. This one release time frame is a transition period which is
> >> intended for users to upgrade from old LTS to new one.
> >> New LTS release is chosen every 2 years.  The process is that current latest
> >> stable release becomes an LTS release at the same time with the next major
> >> release.  That could change based on the current state of OVS development.  For
> >> example, we do not want to designate a new release as LTS that includes
> >> disruptive internal changes, as that may make it harder to support for a longer
> >> period of time.  Discussion about skipping designation of the next LTS release
> >> occurs on the OVS development mailing list.
> >>
> >> LTS designation schedule example (depends on current state of development):
> >>   2.14 released on Aug 2020 - new latest stable, 2.13 stable --> new LTS
> >>   2.15 released on Feb 2021 - new latest stable, 2.5     LTS --> EOL
> >>   2.16 released on Aug 2021 - new latest stable
> >>   2.17 released on Feb 2022 - new latest stable
> >>   2.18 released on Aug 2022 - new latest stable, 2.17 stable --> new LTS
> >>   2.19 released on Feb 2023 - new latest stable, 2.13    LTS --> EOL
> >>
> >> While branches other than LTS and the latest release are not formally
> >> maintained, the OVS project usually provides stable releases for these branches
> >> for at least 2 years, i.e. stable releases are provided for the last 4
> >> release branches.  However, these branches includes only bug fixes that are
> >> easy to backport, i.e. might not include all the fixes that LTS has.
> >> """
> >>
> >> The main difference here is that we're specifying that LTS nominated every 2
> >> years by default and "skipping" should be discussed on a list instead of
> >> "choosing".  And also specified the process that new LTS is a previous stable,
> >> so the branch is already maintained for 6 months before becoming an LTS and
> >> there is no unmaintained time for this branch until its EOL.
> >>
> >> What do you think?  Simon, Ian, anyone else?
> > 
> > The issue I see is that the idea of "easy to backport" is
> > subjective. If one is available to do a backport work,
> > would that be acceptable?
> 
> Yes, sure.  If one is willing to spend some time backporting certain
> fixes, that are not obvious, there is no point to reject this work.
> 
> The main point of this statement is to avoid wasting of time in case
> it's really not clear how to backport fix correctly.  Another point
> is that is the window for us to not backport OVN fixes, for example,
> once branch that has OVN inside goes out of official support. This
> is extra work for OVS maintainers with no reasonable benefit.  And
> OVN folks doesn't really willing to support OVN inside OVS 2.12, so
> this sentence allows us legitimately avoid backporting OVN patches
> if OVN folks doesn't actually work on them.

Sounds good to me.

-- 
fbl