On 25/01/18 19:08, James E. Blair wrote:
Mathieu Gagné <mga...@calavera.ca> writes:
On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec <openst...@nemebean.com> wrote:
I'm curious what this means as far as best practices for inter-patch
references. In the past my understanding was the the change id was
preferred, both because if gerrit changed its URL format the change id links
would be updated appropriately, and also because change ids can be looked up
offline in git commit messages. Would that still be the case for everything
except depends-on now?
Yes, that's a down-side of URLs. I personally think it's fine to keep
using change-ids for anything other than Depends-On, though in many of
those cases the commit sha may work as well.
That's my concern too. Also AFAIK, Change-Id is branch agnostic. This
means you can more easily cherry-pick between branches without having
to change the URL to match the new branch for your dependencies.
Yes, there is a positive and negative aspect to this issue.
On the one hand, for those times where it was convenient to say "depend
on this change in all its forms across all branches of all projects",
one must now add a URL for each.
On the other hand, with URLs, it is now possible to indicate that a
change specifically depends on another change targeted to one branch, or
targeted to several branches. Simply list each URL (or don't) as
appropriate. That wasn't possible before -- it wall all or none.
Yeah, it's definitely nice to have that flexibility. e.g. here is a
patch that wouldn't merge for 3 months because the thing it was
dependent on also got proposed as a backport:
https://review.openstack.org/#/c/514761/1
From an OpenStack perspective, it would be nice if a Gerrit ID implied
a change from the same Gerrit instance as the current repo and the same
branch as the current patch if it exists (otherwise any branch), and we
could optionally use a URL instead to select a particular change.
It's not obvious to me that that'd be the wrong thing for a tool that
works across multiple Gerrit instances and/or other backends either, but
I'm sure y'all have thought about it in more depth than I have.
cheers,
Zane.
__________________________________________________________________________
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
