On 2015-07-29 10:53:38 +0200 (+0200), Yanis Guenane wrote: > On 07/28/2015 07:13 PM, Andreas Jaeger wrote: [...] > > * If there is a proposed change already for a project, reuse that one > > instead of creating a new one? > > I don't have the answer for that I'd have to look. But this should never > happen as the goal here is to enforce a process where a change to a > shared file can only be done via the modulesync repository.
The question comes from experience preforming similar synchronization proposals for requirements lists, translations, data file normalization, et cetera. Specifically, if you update the msync repo and that triggers change proposals for all your module repos, but then core reviewers don't get around to approving at least some of those before the next change merges to the msync repo (especially possible if you approve two msync changes at roughly the same time), will it properly update the existing but not-yet-merged changes it previously proposed rather than creating new changes? > > * Will msync check out the git repositories itself? > > Yes, msync checks out the repositories listed in managed_modules.yml, > loop on them, clone them, apply the templates and submit the review. Also, does msync know to take advantage of the on-disk cache of git repositories on our job workers, or does it clone them all over the network every time it runs? The latter can lead to additional fragility. -- Jeremy Stanley __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
