If the bot did sensible things (one module at a time sync plus deps where necessary, preferably using dependant patches where possible for deps, and commit messages that list all of the individual commits that are being synced), I think this could be great. It is quite tricky to figure out the last sync point automatically in order to list all of the commits pulled in however - and some projects have (had?) local commits on top of the imports that made things even more complex...
On 4 July 2014 14:31, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi all, > at the moment we have several bot jobs that sync contents to affected > projects: > > - - translations are copied from transifex; > - - requirements are copied from global requirements repo. > > We have another source of common code - oslo-incubator, though we > still rely on people manually copying the new code from there to > affected projects. This results in old, buggy, and sometimes > completely different versions of the same code in all projects. > > I wonder why don't we set another bot to sync code from incubator? In > that way, we would: > - - reduce work to do for developers [I hope everyone knows how boring > it is to fill in commit message with all commits synchronized and > create sync requests for > 10 projects at once]; > - - make sure all projects use (almost) the same code; > - - ensure projects are notified in advance in case API changed in one > of the modules that resulted in failures in gate; > - - our LOC statistics will be a bit more fair ;) (currently, the one > who syncs a large piece of code from incubator to a project, gets all > the LOC credit at e.g. stackalytics.com). > > The changes will still be gated, so any failures and incompatibilities > will be caught. I even don't expect most of sync requests to fail at > all, meaning it will be just a matter of two +2's from cores. > > I know that Oslo team works hard to graduate lots of modules from > incubator to separate libraries with stable API. Still, I guess we'll > live with incubator at least another cycle or two. > > What are your thoughts on that? > > /Ihar > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTtqydAAoJEC5aWaUY1u579D8H/15KrB2Sqd+nul0DNPj7U1Tt > Rt7dvFzaUDXOA7qbEHvKudoJcuPQfss7etttZtlX75xMC/AQ2+bVlZBjCwy23ZaQ > OsvzbRyHIVC+2nOnU3nfwxJByRRij9DeWcEazrXX9QDCw0bq9m1BI6TXGMaROCSa > edNpp5tuwaLG8910tKqK5yB7F2i1USIWKPNa1ZBArqco350ULLPPF28z1InGgWZn > 8ipFvArbKEXyPQotQFPzH58KEsdAR/h7BMUXZ+6c0hRLFb/Vel4q85Tl8lnoB0yJ > MMXvr09DTzMkwXXr3sowqlDCpaAF0dGccBbdaLNB45NMa6Z1Gx5Gp9etWKisdOc= > =w51L > -----END PGP SIGNATURE----- > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev