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 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
