[openstack-dev] [OpenStack-Dev] Cherry picking commit from oslo-incubator
john.griffith at solidfire.com
Tue Jan 21 19:14:49 UTC 2014
On Tue, Jan 21, 2014 at 11:14 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> On Jan 17, 2014 12:24 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>
>>> On 2014-01-16 13:48, John Griffith wrote:
>>> Hey Everyone,
>>> A review came up today that cherry-picked a specific commit to
>>> Incubator, without updating the rest of the files in the module.
>>> rejected that patch, because my philosophy has been that when you
>>> update/pull from oslo-incubator it should be done as a full sync
>>> the entire module, not a cherry pick of the bits and pieces that
>>> may or may not be interested in.
>>> As it turns out I've received a bit of push back on this, so it
>>> maybe I'm being unreasonable, or that I'm mistaken in my
>>> of the process here. To me it seems like a complete and total
>>> 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
>>> I suppose there might be exceptions, but in general I'm with you. For
>>> thing, if someone tries to pull out a specific change in the Oslo
>>> there's no guarantee that code even works. Depending on how the sync
>>> 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
>>> 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
>>> of reviewer sanity I'm -1 on partial syncs without a _very_ good
>>> (like it's blocking the gate and there's some reason the full module
>>> be synced).
>>> I agree. Cherry picking a single (or even partial) commit really should
>>> The update tool does allow syncing just a single module, but that should
>>> used very VERY carefully, especially because some of the changes we're
>>> 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
>> 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.
>> Flavio Percoco
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev