Open Stack

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
> nova/neutron/etc.

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
deployment projects.
 
> >> 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
that evaluation.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170928/34b9b517/attachment.sig>