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 <dtant...@redhat.com
<mailto:dtant...@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
<dtant...@redhat.com <mailto:dtant...@redhat.com>
> <mailto:dtant...@redhat.com <mailto:dtant...@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
> <d...@doughellmann.com <mailto:d...@doughellmann.com>
<mailto:d...@doughellmann.com <mailto:d...@doughellmann.com>>
> >>>> <mailto:d...@doughellmann.com
<mailto:d...@doughellmann.com> <mailto:d...@doughellmann.com
<mailto:d...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://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://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 <http://www.mirantis.com>
>
>
>
__________________________________________________________________________
> 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
__________________________________________________________________________
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
