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

Pavlo Shchelokovskyy pshchelokovskyy at mirantis.com
Tue Dec 8 10:32:02 UTC 2015


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 <dtantsur at redhat.com> 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: <spec-review-id> 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 <dtantsur at redhat.com
> > <mailto:dtantsur at redhat.com>> 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
> >     <doug at doughellmann.com <mailto:doug at doughellmann.com>
> >      >>>> <mailto:doug at doughellmann.com <mailto:doug at doughellmann.com
> >>>:
> >      >>>>
> >      >> <snip>
> >      >>>>
> >      >>>>       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-request at lists.openstack.org?subject:unsubscribe
> >     <
> http://OpenStack-dev-request@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://OpenStack-dev-request@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-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/20151208/9aecf47e/attachment.html>


More information about the OpenStack-dev mailing list