On 12/09/2015 10:58 PM, Jim Rollenhagen wrote:
On Fri, Dec 04, 2015 at 05:38:43PM +0100, Dmitry Tantsur wrote:
Hi!
As you all probably know, we've switched to reno for managing release notes.
What it also means is that the release team has stopped managing milestones
for us. We have to manually open/close milestones in launchpad, if we feel
like. I'm a bit tired of doing it for inspector, so I'd prefer we stop it.
If we need to track release-critical patches, we usually do it in etherpad
anyway. We also have importance fields for bugs, which can be applied to
both important bugs and important features.
During a quick discussion on IRC Sam mentioned that neutron also dropped
using blueprints for tracking features. They only use bugs with RFE tag and
specs. It makes a lot of sense to me to do the same, if we stop tracking
milestones.
For both ironic and ironic-inspector I'd like to get your opinion on the
following suggestions:
1. Stop tracking milestones in launchpad
2. Drop existing milestones to avoid confusion
3. Stop using blueprints and move all active blueprints to bugs with RFE
tags; request a bug URL instead of a blueprint URL in specs.
So in the end we'll end up with bugs for tracking user requests, specs for
complex features and reno for tracking for went into a particular release.
Important note: if you vote for keeping things for ironic-inspector, I may
ask you to volunteer in helping with them ;)
We decided we're going to try this in Monday's meeting, following
roughly the same process as Neutron:
http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
Note that as the goal here is to stop managing blueprints and milestones
in launchpad, a couple of things will differ from the neutron process:
1) A matching blueprint will not be created; the tracking will only be
done in the bug.
2) A milestone will not be immediately chosen for the feature
enhancement, as we won't track milestones on launchpad.
Now, some requests for volunteers. We need:
1) Someone to document this process in our developer docs.
2) Someone to update the spec template to request a bug link, instead of
a blueprint link.
3) Someone to help move existing blueprints into RFEs.
4) Someone to point specs for incomplete work at the new RFE bugs,
instead of the existing blueprints.
I can help with some or all of these, but hope to not do all the work
myself. :)
I'll help you with as many things as my time allows. Documentation is my
week point, so I'll start with #2.
Thanks for proposing this, Dmitry!
// jim
__________________________________________________________________________
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
__________________________________________________________________________
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
