Open Stack

Doug,

Apologies for top post – email client upgrade broke my ability to post inline (working on getting a revert or further instructions on how to re-enable proper function).

Based upon your guidance, I wanted to inform you a decision has been made on our RC2 deadline – which is October 10th-October 13th.  We do not want to take advantage of the discretion you have afforded release-trailing projects by the recent process changes in the releases repo.  If you think this is cutting it too close or have other objections, let us know and we will alter course appropriately based upon your guidance.  Note we recognize we are making a tradeoff from keeping master open for business here, but the general consensus is that the tradeoff is in the best interests of Kolla itself as well as OpenStack in general.

This is a no-feature release candidate, and we have narrowed our bug list from 107 to 93 bugs in the last day.  Once the core team wrap up with triage (Thursday 00:00 UTC is our official deadline for rc2 triage to complete), I expect this bug list to be a more manageable 40-60 bugs.  The expectation I have set with the core review team is that rc2 should be taggable as 3.0.0 without changes, although I can’t obviously guarantee this if we hit a critical issue in the one week between the release cycle trailing deadline and the rc2.  I don’t expect a critical issue to be found in rc2, but as you know anything is possible.

If you believe we are running afoul of other policies (i.e. project maturity tags) in OpenStack because of this decision, that information would be helpful as well.

Thanks!
-steve


On 9/19/16, 6:51 AM, "Doug Hellmann" <doug at doughellmann.com> wrote:

    Excerpts from Thierry Carrez's message of 2016-09-18 16:08:04 +0200:
    > Steven Dake (stdake) wrote:
    > > Release team,
    > > 
    > > At one point Doug had indicated all projects would automatically branch
    > > on tagging of rc1.  I notice in git no Kolla stable/newton branch
    > > exists. Fwiw this is actually a good thing, because 33 patches have
    > > merged since rc1 relating to things that need to go into Newton,
    > > dramatically reducing the amount of backport work we need to do.  Part
    > > of this was error on my part – not validating all FFE blueprints that
    > > were marked Implemented were actually implemented.  One related to
    > > monitoring (and part of the 33 patches since rc1) was actually “Needs
    > > Review” rather than Implemented (as it was marked).
    > > 
    > > I don’t want Kolla to be a special snowflake wrt release processes, and
    > > we can live with a branch on rc1.  A branch on rc2 would be far better
    > > for us as we have roughly 250 bugs to triage or fix.  I leave it in the
    > > release team’s capable judgement to decide best on a course of action.
    > 
    > I'm probably the one to blame for that. Kolla follows milestones but is
    > trailing the release, which makes it a bit of a release snowflake. I
    > wasn't sure we should cut the stable branch at RC1 for such a case
    > (since you're still far away from final).
    > 
    > We should discuss what to do here (branch ASAP, branch at RC2...) on
    > Monday on the release channel when Doug is around.
    
    As we discussed on IRC today, it seems reasonable to give the trailing
    projects a bit more flexibility when we get to the RC period. Let us
    know which RC should form the basis of the branch and we'll create it
    then.
    
    Doug
    
    > 
    > > I would request that the expected time of branch be communicated clearly
    > > to us for the Newton cycle.  I have been communicating with our team
    > > that rc1 is where we branch.  Folks are now asking “where is the Newton
    > > branch of Kolla?”
    > 
    > FWIW Doug has been working on a spec so that projects communicate more
    > clearly when they want the release branch to be cut. For
    > milestone-driven projects it's usually clear (we branch at RC1), but for
    > other cases (intermediary-released, trailing) options are a bit more
    > open so having a way (through the openstack/releases repo) to clearly
    > communicate "when" will definitely help.
    > 
    
    __________________________________________________________________________
    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