On Tue, Jan 21, 2014 at 11:14 AM, Joe Gordon <joe.gord...@gmail.com> wrote: > > On Jan 17, 2014 12:24 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. > > When we started Oslo incubator, we treated that code as trusted. But since > then there have been occasional issues when syncing the code. So Oslo > incubator code has lost *my* trust. Therefore I am always a hesitant to do a > full Oslo sync because I am not an expert on the Oslo code and I risk > breaking something when doing it (the issue may not appear 100% of the time > too). Syncing code in becomes the first time that code is run against > tempest, which scares me. > Understood and agreed, but frankly this defeats the intended purpose IMO. If we're going to go this route and never make them true libs commonly shared/used then we're not gaining anything at all.
We might as well go back to maintaining our own versions in each project and copying/pasting fixes around. In essence that's exactly what you end up with in this situation. > I would like to propose having a integration test job in Oslo incubator that > syncs in the code, similar to how we do global requirements. > > Additionally, what about a periodic jenkins job that does the Oslo syncs and > is managed by the Oslo team itself? Sure, that's a cool idea... once we get through an initial sync I think it's doable. As you've pointed out however there's some challenges with projects that have been doing cherry picks or just ignoring updates for any length of 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. I'd agree with this for sure >> >> 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. I agree there are challenges here, some due to being too far out of date etc. I also agree that a lot goes in to backward compat, however, I think the emphasis on this and what drives a significant number of the changes is Nova specific. I also think that's where most people's focus stops, I don't think there's significant checking or testing across other projects. To be fair we've grown to a size where this isn't necessarily feasible without automation which goes back to your earlier point. At the risk of coming across the wrong way, it seems that oslo-incubator has become something that really isn't that different or far way from the days when we all just copy/pasted code from nova. I know that's completely unfair in terms of items that have made it out and are actual libraries but I think there's some validity to the perspective. >> >> 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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev