Open Stack

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 <dtantsur at 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-request at 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-request at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151210/6a77db0b/attachment.html>