Open Stack

Zane Bitter <zbitter at redhat.com> writes:

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

Yeah, that's reasonable, and it is similar to things Zuul does in other
areas, but I think one of the thing we want to do with Depends-On is
consider that Zuul isn't the only audience.  It's there just as much for
the reviewers, and other folks.  So when it comes to Gerrit change ids,
I feel we had to constrain it to Gerrit's own behavior.  When you click
on one of those in Gerrit, it shows you all of the changes across all of
the repos and branches with that change-id.  So that result list is what
Zuul should work with.  Otherwise there's a discontinuity between what a
user sees when they click the hyperlink under the change-id and what
Zuul does.

Similarly, in the new system, you click the URL and you see what Zuul is
going to use.

And that leads into the reason we want to drop the old syntax: to make
it seamless for a GitHub user to know how to Depends-On a Gerrit change,
and vice versa, with neither requiring domain-specific knowledge about
the system.

-Jim