Open Stack

On Wed, Aug 10, 2016 at 10:21 AM, Matthew Treinish <mtreinish at kortar.org>
wrote:

> But, to keep the gate running
> involves a lot of coordination between multiple projects that are tightly
> coupled. Things like an entire extra set of job definitions in zuul, a
> branch on
> global requirements, a devstack branch, extra devstack-gate logic, a bunch
> of
> extra config options for skips in tempest, extra node types, etc. Keeping
> all
> those things working together is a big part of what stable maint actually
> entails.


that actually makes more sense (sorry I missed any earlier explanation) -
I'm reading this as there is only ever one CI *system* running at a time,
and that system needs to know a bunch about how to *setup* a test job on an
old branches - not that any of the old versions of code or tests or even
the history of the CI system that existed and was able to test them at the
time is GONE - its just that the current deployed system needs to move on...


> That's why at the EOL we tag
> the branch tip and then delete it. Leaving the branch around advertises
> that
> we're in a position to accept new patches to it, which we aren't after the
> EOL.
>
>
Oh wow... so it *is* GONE ;)

And really "we can't test it so no-one can" might be a big part of the
issue that was brought up in the earlier thread.  Maybe trying to support
stable branches longer than 18 months is *not* something can to be broadly
supported inside of OpenStack (there seemed to be some interest in the
etherpad going out to 24 months some day, even though older branches would
have less and less support for new testing capabilities).  But I think the
heart of this thread is "we appreciate the complexity and effort that it
takes to deliver what we have for older branches.  [full stop]  We need a
way to extend some minimal life support into older releases in a way that
is compatible with the current policy.  [full stop] "

Would it be *too* confusing to have "End of Full OpenStack Supported
Official Testing/Life" != "End of a projects commitment to people running
clouds using our software to try and help them be successful"?  Without
having to define unilaterally for every installation that the only option
for success is upgrade to the next about to be abandoned in 6-18 mo major
release?

I think ideally we'd be looking for a way to let them have their cake
without extra work.

OTOH, forking to support old branches seems just as reasonable to me as
well (that's what we do)...

However, I fully admit, I'm probably thinking about it wrong.  :D

-Clay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160810/9a128c57/attachment.html>