Open Stack

On 02/15/2016 03:59 AM, Steven Hardy wrote:
> On Wed, Feb 10, 2016 at 07:05:41PM +0100, James Slagle wrote:
>>    On Wed, Feb 10, 2016 at 4:57 PM, Steven Hardy <shardy at redhat.com> wrote:
>>
>>      Hi all,
>>
>>      We discussed this in our meeting[1] this week, and agreed a ML
>>      discussion
>>      to gain consensus and give folks visibility of the outcome would be a
>>      good
>>      idea.
>>
>>      In summary, we adopted a more permissive "release branch" policy[2] for
>>      our
>>      stable/liberty branches, where feature backports would be allowed,
>>      provided
>>      they worked with liberty and didn't break backwards compatibility.
>>
>>      The original idea was really to provide a mechanism to "catch up" where
>>      features are added e.g to liberty OpenStack components late in the cycle
>>      and TripleO requires changes to integrate with them.
>>
>>      However, the reality has been that the permissive backport policy has
>>      been
>>      somewhat abused (IMHO) with a large number of major features being
>>      proposed
>>      for backport, and in a few cases this has broken downstream (RDO)
>>      consumers
>>      of TripleO.
>>
>>      Thus, I would propose that from Mitaka, we revise our backport policy to
>>      simply align with the standard stable branch model observed by all
>>      projects[3].
>>
>>      Hopefully this will allow us to retain the benefits of the stable branch
>>      process, but provide better stability for downstream consumers of these
>>      branches, and minimise confusion regarding what is a permissable
>>      backport.
>>
>>      If we do this, only backports that can reasonably be considered
>>      "Appropriate fixes"[4] will be valid backports - in the majority of
>>      cases
>>      this will mean bugfixes only, and large features where the risk of
>>      regression is significant will not be allowed.
>>
>>      What are peoples thoughts on this?
>>
>>    â**I'm in agreement. I think this change is needed and will help set
>>    better expectations around what will be included in which release.
>>
>>    If we adopt this as the new policy, then the immediate followup is to set
>>    and communicate when we'll be cutting the stable branches, so that it's
>>    understood when the features have to be done/committed. I'd suggest that
>>    we more or less completely adopt the integrated release schedule[1]. Which
>>    I believe means the week of RC1 for cutting the stable/mitaka branches,
>>    which is March 14th-18th.
>>
>>    It seems to follow logically then that we'd then want to also be more
>>    aggresively aligned with other integrated release events such as the
>>    feature freeze date, Feb 29th - March 4th.
> 
> Yes, agreeing a backport policy is the first step, and aligning all our
> release policies with the rest of OpenStack is the logical next step.
> 
>>    An alternative to strictly following the schedule, would be to say that
>>    TripleO lags the integrated release dates by some number of weeks (1 or 2
>>    I'd think), to allow for some "catchup" time since TripleO is often
>>    consuming features from projects part of the integrated release.
> 
> The risk with this approach is there remains some confusion about our
> deadlines, and there is an increased risk that our 1-2 weeks window slips
> and we end up with a similar problem to that which we have now.
> 
>From a packaging POV, I am also -1 on lagging the integrated release.
This creates a situation where TripleO can not be used as the method to
test the integrated release packaging. This means relying on other
installers (Packstack), which means less use of TripleO in the RDO
community.

Any big feature that needs support in TripleO, that is in the integrated
release, would have a spec landed in advance. So, I do not think it is
all that burdensome to land TripleO support for the features on the same
schedule.

> I'd propose we align with whatever schedule the puppet community observes,
> given that (with out current implementation at least), it's unlikely we can
> land any features actually related to new-feature-in-$service type patches
> without that feature already having support in the puppet modules?
> 

+1 to following puppet module lead. It seems like any new feature type
patch we wanted to support in TripleO should be implemented very close
to the patch in the puppet module which enables it. Ideally, we could
land TripleO support at the same time as the feature is enabled in
puppet using depends on.

> Perhaps we can seek out some guidance from Emilien, as I'm not 100% sure of
> the release model observed for the puppet modules?
> 
> If you look at the features we're backporting, most of them aren't related
> to features requiring "catchup", e.g IPv6, SSL, Upgrades - these are all
> cross-project TripleO features and there are very few (if any?) "catchup"
> type requirements AFAICT.
> 
> Also, if you look at other projects, such as Heat and Mistral, which
> interact with many other services, they observe the same schedule as all
> other projects - so if you want $new_feature for some project integrated
> there, you have to get your patches for that integration posted before
> feature freeze.  I'm thinking there is less room for confusion and deadline
> abuse if we just say TripleO is the same?
> 
> Steve
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>