[openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)
tony at bakeyournoodle.com
Thu Sep 28 00:37:42 UTC 2017
On Wed, Sep 27, 2017 at 10:39:13AM -0600, Alex Schultz wrote:
> One idea would be to allow trailing projects additional trailing on
> the phases as well. Honestly 2 weeks for trailing for just GA is hard
> enough. Let alone the fact that the actual end-users are 18+ months
> behind. For some deployment project like tripleo, there are sections
> that should probably follow stable-policy as it exists today but
> elements where there's 3rd party integration or upgrade implications
> (in the case of tripleo, THT/puppet-tripleo) and they need to be more
> flexible to modify things as necessary. The word 'feature' isn't
> necessarily the same for these projects than something like
There are 2 separate aspects here:
1) What changes are appropriate on stable/* branches ; and
2) How long to stable/* stay around for.
Looking at 1. I totally get that deployment projects have a different
threshold on the bugfix/feature line. That's actually the easy part to
fix. The point of the stable policy is to give users some assurance
that moving from version x.y.z -> x.Y.Z will be a smooth process. We
just need to capture that intent in a policy that works in the context
of a deployment project.
Looking at 2. The stable policy doesn't say you *need* to EOL on
Oct-11th by default any project that asserts that tag is included but
you're also free to opt out as long as there is a good story around CI
and impact on human and machine resources. We re-evaluate that from
time to time. As an example, group-based-policy otpted out of the
kilo?, liberty and mitaka EOLs, recently dropped everything before
mitaka. I get that GBP has a different footprint in CI than tripleo
does but it illustrates that there is scope to support your users within
the current policy.
I'm still advocating for crafting a more appropriate policy for
> >> What proposing Giulio probably comes from the real world, the field,
> >> who actually manage OpenStack at scale and on real environments (not
> >> in devstack from master). If we can't have this code in-tree, we'll
> >> probably carry this patch downstream (which is IMHO bad because of
> >> maintenance and lack of CI). In that case, I'll vote to give up
> >> stable:follows-policy so we can do what we need.
> > Rather than give up on the stable:follows policy tag it is possibly
> > worth looking at which portions of tripleo make that assertion.
> > In this specific case, there isn't anything in the bug that indicates
> > it comes from a user report which is all the stable team has to go on
> > when making these types of decisions.
> We'll need to re-evaulate what stable-policy means for tripleo. We
> don't want to allow the world for backporting but we also want to
> reduce the patches carried downstream for specific use cases. I think
> in the case of 3rd party integrations we need a better definition of
> what that means and perhaps creating a new repository like THT-extras
> that doesn't follow stable-policy while the main one does.
Right, I don't pretend to understand the ins-and-outs of tripleo but yes
I think we're mostly agreeing on that point.
https://review.openstack.org/#/c/507924/ buys everyone the space to make
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: not available
More information about the OpenStack-dev