Open Stack

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 <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
> 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
>