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