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