Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Jim Rollenhagen]

FYI, this work was completed. Docs are here:
http://docs.openstack.org/developer/ironic/dev/code-contribution-guide.html#adding-new-features

// jim

On Wed, Dec 09, 2015 at 01:58:34PM -0800, 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. :)
> 
> 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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Dmitry Tantsur]

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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Pavlo Shchelokovskyy]

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  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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Jim Rollenhagen]

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. :)

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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Dmitry Tantsur]

On 12/08/2015 08:12 AM, Pavlo Shchelokovskyy wrote:

Hi all,

I have a question regarding #1 (Stop using LP for blueprints):

what should we now use instead of "specifies" and "implements" Gerrit
tags in commit messages? Simple Depends-On:  should
suffice but is not visually specific enough, and only replaces
"implements" tag.


Closes-Bug for RFE bug, I guess. As a bonus point we'll distinguish 
between Partial-Bug and Closes-Bug.




Also as a side note, some gate jobs for spec repos must be modified to
accommodate for the new process - they are still requiring a LP
blueprint reference to be specified in the body of a spec
(e.g. gate-ironic-specs-python27).


No gate jobs require a blueprint reference anywhere (otherwise we would 
not be able to land bug fixes :)




Best regards,

On Mon, Dec 7, 2015 at 3:52 PM Dmitry Tantsur > wrote:

On 12/07/2015 02:42 PM, Doug Hellmann wrote:
 > Excerpts from Dmitry Tantsur's message of 2015-12-07 13:18:22 +0100:
 >> On 12/07/2015 10:48 AM, Thierry Carrez wrote:
 >>> Dmitry Tantsur wrote:
 
  2015-12-04 18:26 GMT+01:00 Doug Hellmann

  >>:
 
 >> 
 
    Please don't delete anything older than Mitaka.
 
 
  Do you have any hints how to not confuse users in this case?
 >>>
 >>> I think what Doug means is you should not delete existing closed
 >>> milestones like:
 >>> https://launchpad.net/ironic/kilo/2015.1.0
 >>> or:
 >>> https://launchpad.net/ironic/liberty/4.2.0
 >>> since we use the Launchpad pages there as the list of features
and bugs
 >>> fixed for those pre-reno releases.
 >>>
 >>> Deleting those milestones would lose useful user information for no
 >>> gain: you can't use them anymore (since they are closed) so
they are
 >>> unlikely to confuse anyone ?
 >>>
 >>
 >> I wonder how to avoid giving impression that development has
stopped on
 >> 4.2.0. E.g. Launchpad would show 4.2.0 as the last released
tarball, as
 >> we no longer push tarballs to launchpad.
 >>
 >
 > I think the fact that we'll be announcing new releases by pointing
 > to other URLs (the releases site, for example) will help avoid that
 > sort of confusion. You could also add a note to the top of the
project
 > page on launchpad.

+1

 >
 > If, over time, we see a lot of folks actually confused about the
 > move we can figure out a way to migrate the old data elsewhere so
 > it can be deleted. But that's not going to happen this cycle, so
 > please leave it intact for now.

Understood, thanks for explanation. So I withdraw suggestion #2.

 >
 > Doug
 >
 >
__
 > 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




__
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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Alan Pevec]

>>> I wonder how to avoid giving impression that development has stopped on
>>> 4.2.0. E.g. Launchpad would show 4.2.0 as the last released tarball, as
>>> we no longer push tarballs to launchpad.

.0 is clear indication that's GA tarball, but to make it clear you can
update Launchpad series summary
https://launchpad.net/ironic/liberty/+edit
to include the link to
http://docs.openstack.org/releases/releases/liberty.html#liberty-ironic

>> If, over time, we see a lot of folks actually confused about the
>> move we can figure out a way to migrate the old data elsewhere so
>> it can be deleted. But that's not going to happen this cycle, so
>> please leave it intact for now.
> Understood, thanks for explanation. So I withdraw suggestion #2.

Count me confused, when I saw Ironic 4.2.2 announcement and then 4.2.1
as latest in Launchpad.
I propose to remove https://launchpad.net/ironic/+milestone/4.2.1 - it
has no release notes and only one minor bug, so that's not much
information loss and cuts this confusing corner case.
For historical purposes, tarball is still available at
http://tarballs.openstack.org/ironic/ironic-4.2.1.tar.gz. This should
be the only non-reno Liberty release, for other projects it would be
super nice if release team could bulk add link
http://docs.openstack.org/releases/releases/liberty.html#liberty-$PROJECT
in all Liberty series summaries in Launchpad.

Cheers,
Alan

__
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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Thierry Carrez]

Alan Pevec wrote:
> Count me confused, when I saw Ironic 4.2.2 announcement and then 4.2.1
> as latest in Launchpad.
> I propose to remove https://launchpad.net/ironic/+milestone/4.2.1 - it
> has no release notes and only one minor bug, so that's not much
> information loss and cuts this confusing corner case.
> For historical purposes, tarball is still available at
> http://tarballs.openstack.org/ironic/ironic-4.2.1.tar.gz. This should
> be the only non-reno Liberty release,

That sounds like a reasonable compromise. Ironic 4.2.1 is the only
Liberty post-release we issued before reno was rolled out in every project.

> for other projects it would be
> super nice if release team could bulk add link
> http://docs.openstack.org/releases/releases/liberty.html#liberty-$PROJECT
> in all Liberty series summaries in Launchpad.

Agreed, I'll do that.

-- 
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Dmitry Tantsur]

On 12/08/2015 11:32 AM, Pavlo Shchelokovskyy wrote:

Hi Dmitry,

not true, the gate-ironic-specs-python27 requires that LP blueprint is
provided in a spec [0].

If we are to get away from LP blueprints and at least not register new
ones, this must be fixed. I'll test if the job accepts a link to LP RFE
bug instead of LP blueprint though.


Gotcha, sorry for confusion. Yes, in case we completely drop blueprints, 
we'll have to change it to accept bugs instead.




[0]
http://logs.openstack.org/21/254421/1/check/gate-ironic-specs-python27/ab07a3f/console.html#_2015-12-07_22_52_07_669

On Tue, Dec 8, 2015 at 11:31 AM Dmitry Tantsur > wrote:

On 12/08/2015 08:12 AM, Pavlo Shchelokovskyy wrote:
 > Hi all,
 >
 > I have a question regarding #1 (Stop using LP for blueprints):
 >
 > what should we now use instead of "specifies" and "implements" Gerrit
 > tags in commit messages? Simple Depends-On:  should
 > suffice but is not visually specific enough, and only replaces
 > "implements" tag.

Closes-Bug for RFE bug, I guess. As a bonus point we'll distinguish
between Partial-Bug and Closes-Bug.

 >
 > Also as a side note, some gate jobs for spec repos must be
modified to
 > accommodate for the new process - they are still requiring a LP
 > blueprint reference to be specified in the body of a spec
 > (e.g. gate-ironic-specs-python27).

No gate jobs require a blueprint reference anywhere (otherwise we would
not be able to land bug fixes :)

 >
 > Best regards,
 >
 > On Mon, Dec 7, 2015 at 3:52 PM Dmitry Tantsur

 > >> wrote:
 >
 > On 12/07/2015 02:42 PM, Doug Hellmann wrote:
 >  > Excerpts from Dmitry Tantsur's message of 2015-12-07
13:18:22 +0100:
 >  >> On 12/07/2015 10:48 AM, Thierry Carrez wrote:
 >  >>> Dmitry Tantsur wrote:
 >  
 >   2015-12-04 18:26 GMT+01:00 Doug Hellmann
 > 
>
 >      
 >  >> 
 >  
 >     Please don't delete anything older than Mitaka.
 >  
 >  
 >   Do you have any hints how to not confuse users in this
case?
 >  >>>
 >  >>> I think what Doug means is you should not delete
existing closed
 >  >>> milestones like:
 >  >>> https://launchpad.net/ironic/kilo/2015.1.0
 >  >>> or:
 >  >>> https://launchpad.net/ironic/liberty/4.2.0
 >  >>> since we use the Launchpad pages there as the list of
features
 > and bugs
 >  >>> fixed for those pre-reno releases.
 >  >>>
 >  >>> Deleting those milestones would lose useful user
information for no
 >  >>> gain: you can't use them anymore (since they are closed) so
 > they are
 >  >>> unlikely to confuse anyone ?
 >  >>>
 >  >>
 >  >> I wonder how to avoid giving impression that development has
 > stopped on
 >  >> 4.2.0. E.g. Launchpad would show 4.2.0 as the last released
 > tarball, as
 >  >> we no longer push tarballs to launchpad.
 >  >>
 >  >
 >  > I think the fact that we'll be announcing new releases by
pointing
 >  > to other URLs (the releases site, for example) will help
avoid that
 >  > sort of confusion. You could also add a note to the top of the
 > project
 >  > page on launchpad.
 >
 > +1
 >
 >  >
 >  > If, over time, we see a lot of folks actually confused
about the
 >  > move we can figure out a way to migrate the old data
elsewhere so
 >  > it can be deleted. But that's not going to happen this
cycle, so
 >  > please leave it intact for now.
 >
 > Understood, thanks for explanation. So I withdraw suggestion #2.
 >
 >  >
 >  > Doug
 >  >
 >  >
 >
  __
 >  > 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
 >  >
 >
 >
 >
  

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Pavlo Shchelokovskyy]

Hi Dmitry,

not true, the gate-ironic-specs-python27 requires that LP blueprint is
provided in a spec [0].

If we are to get away from LP blueprints and at least not register new
ones, this must be fixed. I'll test if the job accepts a link to LP RFE bug
instead of LP blueprint though.

[0]
http://logs.openstack.org/21/254421/1/check/gate-ironic-specs-python27/ab07a3f/console.html#_2015-12-07_22_52_07_669

On Tue, Dec 8, 2015 at 11:31 AM Dmitry Tantsur  wrote:

> On 12/08/2015 08:12 AM, Pavlo Shchelokovskyy wrote:
> > Hi all,
> >
> > I have a question regarding #1 (Stop using LP for blueprints):
> >
> > what should we now use instead of "specifies" and "implements" Gerrit
> > tags in commit messages? Simple Depends-On:  should
> > suffice but is not visually specific enough, and only replaces
> > "implements" tag.
>
> Closes-Bug for RFE bug, I guess. As a bonus point we'll distinguish
> between Partial-Bug and Closes-Bug.
>
> >
> > Also as a side note, some gate jobs for spec repos must be modified to
> > accommodate for the new process - they are still requiring a LP
> > blueprint reference to be specified in the body of a spec
> > (e.g. gate-ironic-specs-python27).
>
> No gate jobs require a blueprint reference anywhere (otherwise we would
> not be able to land bug fixes :)
>
> >
> > Best regards,
> >
> > On Mon, Dec 7, 2015 at 3:52 PM Dmitry Tantsur  > > wrote:
> >
> > On 12/07/2015 02:42 PM, Doug Hellmann wrote:
> >  > Excerpts from Dmitry Tantsur's message of 2015-12-07 13:18:22
> +0100:
> >  >> On 12/07/2015 10:48 AM, Thierry Carrez wrote:
> >  >>> Dmitry Tantsur wrote:
> >  
> >   2015-12-04 18:26 GMT+01:00 Doug Hellmann
> > 
> >    >>>:
> >  
> >  >> 
> >  
> >     Please don't delete anything older than Mitaka.
> >  
> >  
> >   Do you have any hints how to not confuse users in this case?
> >  >>>
> >  >>> I think what Doug means is you should not delete existing closed
> >  >>> milestones like:
> >  >>> https://launchpad.net/ironic/kilo/2015.1.0
> >  >>> or:
> >  >>> https://launchpad.net/ironic/liberty/4.2.0
> >  >>> since we use the Launchpad pages there as the list of features
> > and bugs
> >  >>> fixed for those pre-reno releases.
> >  >>>
> >  >>> Deleting those milestones would lose useful user information
> for no
> >  >>> gain: you can't use them anymore (since they are closed) so
> > they are
> >  >>> unlikely to confuse anyone ?
> >  >>>
> >  >>
> >  >> I wonder how to avoid giving impression that development has
> > stopped on
> >  >> 4.2.0. E.g. Launchpad would show 4.2.0 as the last released
> > tarball, as
> >  >> we no longer push tarballs to launchpad.
> >  >>
> >  >
> >  > I think the fact that we'll be announcing new releases by pointing
> >  > to other URLs (the releases site, for example) will help avoid
> that
> >  > sort of confusion. You could also add a note to the top of the
> > project
> >  > page on launchpad.
> >
> > +1
> >
> >  >
> >  > If, over time, we see a lot of folks actually confused about the
> >  > move we can figure out a way to migrate the old data elsewhere so
> >  > it can be deleted. But that's not going to happen this cycle, so
> >  > please leave it intact for now.
> >
> > Understood, thanks for explanation. So I withdraw suggestion #2.
> >
> >  >
> >  > Doug
> >  >
> >  >
> >
>  __
> >  > OpenStack Development Mailing List (not for usage questions)
> >  > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://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://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
> >
>
>
> 

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Pavlo Shchelokovskyy]

Hi all,

I have a question regarding #1 (Stop using LP for blueprints):

what should we now use instead of "specifies" and "implements" Gerrit tags
in commit messages? Simple Depends-On:  should suffice but
is not visually specific enough, and only replaces "implements" tag.

Also as a side note, some gate jobs for spec repos must be modified to
accommodate for the new process - they are still requiring a LP blueprint
reference to be specified in the body of a spec
(e.g. gate-ironic-specs-python27).

Best regards,

On Mon, Dec 7, 2015 at 3:52 PM Dmitry Tantsur  wrote:

> On 12/07/2015 02:42 PM, Doug Hellmann wrote:
> > Excerpts from Dmitry Tantsur's message of 2015-12-07 13:18:22 +0100:
> >> On 12/07/2015 10:48 AM, Thierry Carrez wrote:
> >>> Dmitry Tantsur wrote:
> 
>  2015-12-04 18:26 GMT+01:00 Doug Hellmann   >:
> 
> >> 
> 
>    Please don't delete anything older than Mitaka.
> 
> 
>  Do you have any hints how to not confuse users in this case?
> >>>
> >>> I think what Doug means is you should not delete existing closed
> >>> milestones like:
> >>> https://launchpad.net/ironic/kilo/2015.1.0
> >>> or:
> >>> https://launchpad.net/ironic/liberty/4.2.0
> >>> since we use the Launchpad pages there as the list of features and bugs
> >>> fixed for those pre-reno releases.
> >>>
> >>> Deleting those milestones would lose useful user information for no
> >>> gain: you can't use them anymore (since they are closed) so they are
> >>> unlikely to confuse anyone ?
> >>>
> >>
> >> I wonder how to avoid giving impression that development has stopped on
> >> 4.2.0. E.g. Launchpad would show 4.2.0 as the last released tarball, as
> >> we no longer push tarballs to launchpad.
> >>
> >
> > I think the fact that we'll be announcing new releases by pointing
> > to other URLs (the releases site, for example) will help avoid that
> > sort of confusion. You could also add a note to the top of the project
> > page on launchpad.
>
> +1
>
> >
> > If, over time, we see a lot of folks actually confused about the
> > move we can figure out a way to migrate the old data elsewhere so
> > it can be deleted. But that's not going to happen this cycle, so
> > please leave it intact for now.
>
> Understood, thanks for explanation. So I withdraw suggestion #2.
>
> >
> > Doug
> >
> >
> __
> > 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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2015-12-07 13:18:22 +0100:
> On 12/07/2015 10:48 AM, Thierry Carrez wrote:
> > Dmitry Tantsur wrote:
> >>
> >> 2015-12-04 18:26 GMT+01:00 Doug Hellmann  >> >:
> >>
> 
> >>
> >>  Please don't delete anything older than Mitaka.
> >>
> >>
> >> Do you have any hints how to not confuse users in this case?
> >
> > I think what Doug means is you should not delete existing closed
> > milestones like:
> > https://launchpad.net/ironic/kilo/2015.1.0
> > or:
> > https://launchpad.net/ironic/liberty/4.2.0
> > since we use the Launchpad pages there as the list of features and bugs
> > fixed for those pre-reno releases.
> >
> > Deleting those milestones would lose useful user information for no
> > gain: you can't use them anymore (since they are closed) so they are
> > unlikely to confuse anyone ?
> >
> 
> I wonder how to avoid giving impression that development has stopped on 
> 4.2.0. E.g. Launchpad would show 4.2.0 as the last released tarball, as 
> we no longer push tarballs to launchpad.
> 

I think the fact that we'll be announcing new releases by pointing
to other URLs (the releases site, for example) will help avoid that
sort of confusion. You could also add a note to the top of the project
page on launchpad.

If, over time, we see a lot of folks actually confused about the
move we can figure out a way to migrate the old data elsewhere so
it can be deleted. But that's not going to happen this cycle, so
please leave it intact for now.

Doug

__
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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Dmitry Tantsur]

On 12/07/2015 02:42 PM, Doug Hellmann wrote:

Excerpts from Dmitry Tantsur's message of 2015-12-07 13:18:22 +0100:

On 12/07/2015 10:48 AM, Thierry Carrez wrote:

Dmitry Tantsur wrote:


2015-12-04 18:26 GMT+01:00 Doug Hellmann >:





  Please don't delete anything older than Mitaka.


Do you have any hints how to not confuse users in this case?


I think what Doug means is you should not delete existing closed
milestones like:
https://launchpad.net/ironic/kilo/2015.1.0
or:
https://launchpad.net/ironic/liberty/4.2.0
since we use the Launchpad pages there as the list of features and bugs
fixed for those pre-reno releases.

Deleting those milestones would lose useful user information for no
gain: you can't use them anymore (since they are closed) so they are
unlikely to confuse anyone ?



I wonder how to avoid giving impression that development has stopped on
4.2.0. E.g. Launchpad would show 4.2.0 as the last released tarball, as
we no longer push tarballs to launchpad.



I think the fact that we'll be announcing new releases by pointing
to other URLs (the releases site, for example) will help avoid that
sort of confusion. You could also add a note to the top of the project
page on launchpad.


+1



If, over time, we see a lot of folks actually confused about the
move we can figure out a way to migrate the old data elsewhere so
it can be deleted. But that's not going to happen this cycle, so
please leave it intact for now.


Understood, thanks for explanation. So I withdraw suggestion #2.



Doug

__
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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Thierry Carrez]

Dmitry Tantsur wrote:
> 
> 2015-12-04 18:26 GMT+01:00 Doug Hellmann  >:
> 
> Excerpts from Dmitry Tantsur's message of 2015-12-04 17:38:43 +0100:
> > 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
> 
> Please don't delete anything older than Mitaka.
> 
> 
> Do you have any hints how to not confuse users in this case?

I think what Doug means is you should not delete existing closed
milestones like:
https://launchpad.net/ironic/kilo/2015.1.0
or:
https://launchpad.net/ironic/liberty/4.2.0
since we use the Launchpad pages there as the list of features and bugs
fixed for those pre-reno releases.

Deleting those milestones would lose useful user information for no
gain: you can't use them anymore (since they are closed) so they are
unlikely to confuse anyone ?

-- 
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Dmitry Tantsur]

On 12/07/2015 10:48 AM, Thierry Carrez wrote:

Dmitry Tantsur wrote:


2015-12-04 18:26 GMT+01:00 Doug Hellmann >:





 Please don't delete anything older than Mitaka.


Do you have any hints how to not confuse users in this case?


I think what Doug means is you should not delete existing closed
milestones like:
https://launchpad.net/ironic/kilo/2015.1.0
or:
https://launchpad.net/ironic/liberty/4.2.0
since we use the Launchpad pages there as the list of features and bugs
fixed for those pre-reno releases.

Deleting those milestones would lose useful user information for no
gain: you can't use them anymore (since they are closed) so they are
unlikely to confuse anyone ?



I wonder how to avoid giving impression that development has stopped on 
4.2.0. E.g. Launchpad would show 4.2.0 as the last released tarball, as 
we no longer push tarballs to launchpad.


__
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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Dmitry Tantsur]

2015-12-04 18:26 GMT+01:00 Doug Hellmann :

> Excerpts from Dmitry Tantsur's message of 2015-12-04 17:38:43 +0100:
> > 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
>
> Please don't delete anything older than Mitaka.
>

Do you have any hints how to not confuse users in this case?


>
> Doug
>
> > 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 ;)
> >
> > Dmitry.
> >
>
> __
> 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
>



-- 
--
-- Dmitry Tantsur
--
__
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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2015-12-04 17:38:43 +0100:
> 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

Please don't delete anything older than Mitaka.

Doug

> 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 ;)
> 
> Dmitry.
> 

__
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-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Dmitry Tantsur]

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 ;)


Dmitry.

__
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