Open Stack

Mathieu Gagné <mgagne at calavera.ca> writes:

> On Thu, Jan 25, 2018 at 7:08 PM, James E. Blair <corvus at inaugust.com> wrote:
>> Mathieu Gagné <mgagne at calavera.ca> writes:
>>
>>> On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec <openstack at 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.
>>
>> -Jim
>>
>
>> The old syntax will continue to work for a while
>
> I still believe Change-Id should be supported and not removed as
> suggested. The use of URL assumes you have access to Gerrit to fetch
> more information about the change.
> This might not always be true or possible, especially when Gerrit is
> kept private and only the git repository is replicated publicly and
> you which to cherry-pick something (and its dependencies) from it.

Perhaps a method of automatically noting the dependencies in git notes
could help with that case?  Or maybe use a different way of
communicating that information -- even with change-ids, there's still a
lot of missing information in that scenario (for instance, which changes
still haven't merged).

-Jim