-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/11/2015 12:09 AM, Sean Dague wrote:
> On 02/10/2015 05:47 PM, Ihar Hrachyshka wrote:
>> So cool! A comment inline.
>>
>> On 02/10/2015 11:26 PM, James E. Blair wrote:
>>> Hi,
>>
>>> We have added support for cross-repo dependencies (CRD) in
>>> Zuul. The important bits:
>>
>>> * To use them, include "Depends-On: <gerrit-change-id>" in the
>>> footer of your commit message. Use the full Change-ID ('I' +
>>> 40 characters).
>>
>>> * These are one-way dependencies only -- do not create a
>>> cycle.
>>
>>> * This is what all the grey dots and lines are in the check
>>> pipeline.
>>
>>> Cross-Repo Dependencies Explained
>>> =================================
>>
>>> There are two behaviors that might go by the name "cross-repo
>>> dependencies". We call them one-way and multi-way.
>>
>>> Multi-way CRD allow for bidirectional links between changes.
>>> For instance, A depends on B and B depends on A. The theory
>>> there is that both would be tested together and merged as a
>>> unit. This is _not_ what we have implemented in Zuul.
>>> Discussions over the past two years have revealed that this
>>> type of behavior could cause problems for continuous deploments
>>> as it means that two components must be upgraded
>>> simultaneously. Not supporting this behavior is a choice we
>>> have made.
>>
>> Though I understand your reasoning behind not providing atomic
>> merges of multiple commits, I want to say that the feature would
>> be very useful for projects that are not decoupled enough. F.e.
>> see neutron advanced services repos that are split out of main
>> neutron project but still use lots of code from neutron
>> namespace, making it hard to introduce changes into the main repo
>> without breaking advanced services for some time. The same is
>> true for decomposed plugins and mechanism drivers for neutron.
>
> Atomic merges across git trees is a really bad idea.
>
> If you want atomic merges, there is an easy solution, be one git
> tree.
>
> If you are allowing folks externally to consume your code directly
> via import, then that needs to be a stable interface that has
> deprecation rules associated with it. All else is craziness.
Long term, I can't agree more. Short term, while we decouple stuff and
in the middle of the process, that's too idealistic to be true.
Though we think about stabilizing API, moving it to a separate common
library, and even spinning up advanced services into separate services
with their own REST. It will just take some time.
/Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU2pUvAAoJEC5aWaUY1u57+KUH/1j3Yl4fdxGJcCIy26s3otSe
DIYopsOiQ0jb2XQ9ZlJ59Kq/KsYKUnHY46Pn6ZBH+iBBbjJke/VT8RaPZ9dJbI55
seTCi/ODEz1fYoZrhlQxRVKm7H465dBYffGKjp6eNfmL6DnIjBnvFcrL2dmKdSkV
BDGmiGBXaNJ7CDBH1PEdFoHpL7zn8ToPxgaEVEU2AH9WjIyX6gO5jYpDKvMWjvJt
O99WSY3MNVkIveFIyiISswXkJK5Bieif/DFmSlWpMKETiT/vRePjKuY0GlDKqC/r
yjKAEbC63Hu3Q0HUMJPc99XZM7TKJ5+I9krFuTw9zBy/ZfxUay5aBdgVzu65j8g=
=63NO
-----END PGP SIGNATURE-----
__________________________________________________________________________
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
