[openstack-dev] [nova] Reminder to move implemented nova specs from mitaka

Markus Zoeller 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 
PM:

> 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 
09:49:06
> > 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' 
subdirectory
> >
> >> 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 
(with
> > spec file)? For example [1] needs additional effort during Newton to
> > finish it.
> >
> > References:
> > [1] 
https://blueprints.launchpad.net/nova/+spec/centralize-config-options
> >
> > 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.
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann

OK, a new blueprint "centralize-config-options-newton" plus a copy
of the spec (with updates according to [1]). 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!

[1] 
https://specs.openstack.org/openstack/nova-specs/readme.html#previously-approved-specifications






More information about the OpenStack-dev mailing list