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.
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev