Hi all, Huge +1 for periodic syncs for two reasons: 1) it makes syncs smaller and thus easier 2) code in oslo-incubator often contains important bug fixes (e.g. incorrect usage of eventlet TLS we found in Nova a few months ago)
Thanks, Roman On Fri, Jan 17, 2014 at 10:15 AM, Flavio Percoco <fla...@redhat.com> wrote: > On 16/01/14 17:32 -0500, Doug Hellmann wrote: >> >> On Thu, Jan 16, 2014 at 3:19 PM, Ben Nemec <openst...@nemebean.com> wrote: >> >> On 2014-01-16 13:48, John Griffith wrote: >> >> Hey Everyone, >> >> A review came up today that cherry-picked a specific commit to OSLO >> Incubator, without updating the rest of the files in the module. I >> rejected that patch, because my philosophy has been that when you >> update/pull from oslo-incubator it should be done as a full sync of >> the entire module, not a cherry pick of the bits and pieces that >> you >> may or may not be interested in. >> >> As it turns out I've received a bit of push back on this, so it >> seems >> maybe I'm being unreasonable, or that I'm mistaken in my >> understanding >> of the process here. To me it seems like a complete and total >> waste >> to have an oslo-incubator and common libs if you're going to turn >> around and just cherry pick changes, but maybe I'm completely out >> of >> line. >> >> Thoughts?? >> >> >> I suppose there might be exceptions, but in general I'm with you. For >> one >> thing, if someone tries to pull out a specific change in the Oslo code, >> there's no guarantee that code even works. Depending on how the sync >> was >> done it's possible the code they're syncing never passed the Oslo unit >> tests in the form being synced, and since unit tests aren't synced to >> the >> target projects it's conceivable that completely broken code could get >> through Jenkins. >> >> Obviously it's possible to do a successful partial sync, but for the >> sake >> of reviewer sanity I'm -1 on partial syncs without a _very_ good reason >> (like it's blocking the gate and there's some reason the full module >> can't >> be synced). >> >> >> I agree. Cherry picking a single (or even partial) commit really should be >> avoided. >> >> The update tool does allow syncing just a single module, but that should >> be >> used very VERY carefully, especially because some of the changes we're >> making >> as we work on graduating some more libraries will include cross-dependent >> changes between oslo modules. > > > Agrred. Syncing on master should be complete synchornization from Oslo > incubator. IMHO, the only case where cherry-picking from oslo should > be allowed is when backporting patches to stable branches. Master > branches should try to keep up-to-date with Oslo and sync everything > every time. > > With that in mind, I'd like to request project's members to do > periodic syncs from Oslo incubator. Yes, it is tedious, painful and > sometimes requires more than just syncing, but we should all try to > keep up-to-date with Oslo. The main reason why I'm asking this is > precisely "stable branches". If the project stays way behind the > oslo-incubator, it'll be really painful to backport patches to stable > branches in case of failures. > > Unfortunately, there are projects that are quite behind from > oslo-incubator master. > > One last comment. FWIW, backwards compatibility is always considered > in all Oslo reviews and if there's a crazy-breaking change, it's > always notified. > > Thankfully, this all will be alleviated with the libs that are being > pulled out from the incubator. The syncs will contain fewer modules > and will be smaller. > > > I'm happy you brought this up now. I was meaning to do it. > > Cheers, > FF > > > -- > @flaper87 > Flavio Percoco > > _______________________________________________ > 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
