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