[openstack-dev] [nova] Reminder to move implemented nova specs from mitaka
mzoeller at de.ibm.com
Fri Mar 18 15:56:57 UTC 2016
Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote on 03/18/2016 03:20:23
> From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> To: openstack-dev at lists.openstack.org
> Date: 03/18/2016 03:22 PM
> Subject: Re: [openstack-dev] [nova] Reminder to move implemented nova
> specs from mitaka
> On 3/18/2016 5:46 AM, Markus Zoeller wrote:
> > Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote on 03/16/2016
> > PM:
> >> From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >> <openstack-dev at lists.openstack.org>
> >> Date: 03/16/2016 09:50 PM
> >> Subject: [openstack-dev] [nova] Reminder to move implemented nova
> >> specs from mitaka
> >> Specs are proposed to the 'approved' subdirectory and when they are
> >> completely implemented in launchpad (the blueprint status is
> >> 'Implemented'), we should move the spec from the 'approved'
> >> to the 'implemented' subdirectory in the nova-specs repo.
> >> For example:
> >> https://review.openstack.org/#/c/248142/
> >> These are the mitaka series blueprints from launchpad:
> >> https://blueprints.launchpad.net/nova/mitaka
> >> If anyone is really daring they could go through and move all of the
> >> implemented ones in a single change.
> >> --
> >> Thanks,
> >> Matt Riedemann
> > Is there a best practice how to handle a partially implemented bp
> > spec file)? For example  needs additional effort during Newton to
> > finish it.
> > References:
> > 
> > Regards, Markus Zoeller (markus_z)
> > 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
> John was just telling me about this yesterday. I guess one thing we can
> do is add a "(partial)" suffix to the title and mark the blueprint
> complete for mitaka, and then the idea is to create a new blueprint for
> newton for continuing the work, e.g. centralize-config-options-newton.
> The idea being we show that something was completed in mitaka when
> you're looking at blueprints in launchpad for mitaka.
> I'm generally OK with that approach, the thing I don't really like is
> when we have to re-propose specs and/or if there are dependent
> blueprints in launchpad. Because creating the new blueprint means you
> have to update the link in the spec when re-proposing it and you need to
> update all of the dependent specs in launchpad for the new newton spec.
> Maybe it's not a big deal, I can see benefits to either approach.
> Personally I don't like to consider a blueprint complete until it's
> actually complete, like has been the case with some of the cells v2
> blueprints we've re-proposed for newton.
> With long cleanup efforts like objects and config options though, I can
> see how having release-specific blueprints is good.
> Markus, so to answer your original question, :), I'd probably mark the
> existing bp as complete for mitaka and create a new
> centralize-config-options-newton blueprint.
> Matt Riedemann
OK, a new blueprint "centralize-config-options-newton" plus a copy
of the spec (with updates according to ). The already pushed changes
need to be updated then. As many of them need to be rebased anyway, that
should be fine I think. I'm going to communicate that. Thanks Matt!
More information about the OpenStack-dev