cloud-init team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Tue, Aug 28, 2018 at 10:03 PM Robert Schweikert <rjschwei@xxxxxxxx>
wrote:

> Hi,
>
> On 08/28/2018 09:48 PM, Scott Moser wrote:
> > Thanks for raising this.
> > This is the sort of feedback I was after.
> > I'm not immediately opposed to supporting sles 12 in the way that we
> > have centos 6 for python2.6.
> >
> > At what point do you think it would be reasonable to drop the 3.4
> > support then?
>
> 2022 or 2023, meaning there would be a frozen as in "no new features"
> cloud-init version for 1 or 2 years in SLES 12.
>
> > Am I correct that you already have the next release of
> > SLES (SLES 15) available.
>
> Yes SLES 15 was released about 6 weeks ago.
>
> > I'm guessing it has a 3.6 or greater.
>
> Yes, has Python 3.6.x
>
> >
> > Perhaps we could say 3.4 support will be held for as long as python 2?
>
> It would have to be longer. From my perspective there are no issues with
> dropping Python 2 in 2020 if Python 3.4 is supported. Then I can switch
> the cloud-init build to a Python 3 build for SLES 12 (Python 3.4 to be
> exact) and let that carry me until we no longer want to support Python
> 3.4 upstream, preferably from my perspective in 2023. So, 3 years longer
> than Python 2 support. But if we'd do 3.4 support until 2022 I can make
> that work as well.
>

While you probably have to provide bug fixes and security updates for
cloud-init in SLES 12 for its lifetime, you certainly don't have to
continue pulling back new releases.  At least my expectation was that at
some point when someone wants/needs a new feature that is not in sles 12,
but *is* in SLES 15 (that has python3.6) you say to them "Well, we have
this nice shiny release that has that and all sorts of new features, can
you try that?".  In 2020, SLES 15 will have been out for 2 years.
Essentially at some point SLES 12 stops getting new features.

There is some maintenance for a distro that is to be expected.  Bug fixes
in stable releases *always* have maintenance burden.  If upstream dropped
python 3.4 support in 2020 you would have to support backporting fixes from
master to your released version and possibly address any python 3.5+isms.
That's not any different than any other project/package.

How *would* you be supporting cloud-init in SLES 12?  Are you expecting to
take new releases back?  Bring back new features? Or just fix
critical/painful bugs?