Hi all, fix for tests in #2 is on review, https://review.openstack.org/#/c/255811/
cheers, On Thu, Dec 10, 2015 at 1:15 PM Dmitry Tantsur <dtant...@redhat.com> wrote: > 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 > -- Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com
__________________________________________________________________________ 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