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