> --nodeps will only sync the modules specified on the command line: > https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator
Heh, whoops. Must have missed that. Is it in the README/info at the top of the update.py script? > That said, it's not always safe to do that. You might sync a change in > one module that depends on a change in another module and end up > breaking something. It might not be caught in the sync either because > the Oslo unit tests don't get synced across. Hmm... I suppose this is why we have libraries with dependencies (not meant to sound snarky). Although in the case of updating a library that you wrote, it's less likely to break things. Best Regards, Solly Ross ----- Original Message ----- From: "Ben Nemec" <openst...@nemebean.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Cc: "Solly Ross" <sr...@redhat.com> Sent: Friday, March 14, 2014 4:36:03 PM Subject: Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py On 2014-03-14 14:49, Solly Ross wrote: > It would also be great if there was a way to only sync one package. There is. :-) --nodeps will only sync the modules specified on the command line: https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator That said, it's not always safe to do that. You might sync a change in one module that depends on a change in another module and end up breaking something. It might not be caught in the sync either because the Oslo unit tests don't get synced across. > When adding a new library > to a project (e.g. openstack.common.report to Nova), one would want to > only sync the openstack.common.report > parts, and not the any changes from the rest of openstack.common. My > process has been > > 1. Edit openstack-common.conf to only contain the packages I want > 2. Run the update > 3. Make sure there wasn't code that didn't get changed from > 'openstack.common.xyz' to 'nova.openstack.common.xyz' (hint: this > happens some times) > 4. git checkout openstack-common.conf to revert the changes to > openstack-common.conf > > IMHO, update.py needs a bit of work (well, I think the whole code > copying thing needs a bit of work, but that's a different story). > > Best Regards, > Solly Ross > > ----- Original Message ----- > From: "Jay S Bryant" <jsbry...@us.ibm.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Sent: Friday, March 14, 2014 3:36:49 PM > Subject: Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py > > > > > From: Brant Knudson <b...@acm.org> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org>, > Date: 03/14/2014 02:21 PM > Subject: Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py > > > > > > > > On Fri, Mar 14, 2014 at 2:05 PM, Jay S Bryant < jsbry...@us.ibm.com > > wrote: > > It would be great if we could get the process for this automated. In > the > mean time, those of us doing the syncs will just have to slog through > the > process. > > Jay > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > What's the process? How do I generate the list of changes? > > Brant > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > Brant, > > My process thus far has been the following: > > > 1. Do the sync to see what files are changed. > 2. Take a look at the last commit sync'd to what is currently in > master for a file. > 3. Document all the commits that have come in on that file since. > 4. Repeat process for all the relevant files if there is more than > one. > 5. If are multiples files I organize the commits with a list of > the files touched by that commit. > 6. Document the master level of Oslo when the sync was done for > reference. > > Process may not be perfect, but it gets the job done. Here is an > example of the format I use: https://review.openstack.org/#/c/75740/ > > Jay > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
