Open Stack

On Fri, Jan 17, 2014 at 1:15 AM, Flavio Percoco <flavio at redhat.com> wrote:
> On 16/01/14 17:32 -0500, Doug Hellmann wrote:
>>
>> On Thu, Jan 16, 2014 at 3:19 PM, Ben Nemec <openstack at 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

Fully agree here, it's something we started in Cinder but sort of died
off and met some push-back (some of that admittedly was from myself at
the beginning).  It is something that we need to look at again though,
if nothing else to prevent falling so far behind that when we do need
a fix/update it's not a monumental undertaking to make it happen.

> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>