On 21/01/14 13:14 -0500, Joe Gordon 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
       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


   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 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
   be synced).

I agree. Cherry picking a single (or even partial) commit really should be

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

While this might be true in some cases, I think we should address it
differently. Just dropping the trust on the project won't help much.

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.

But isn't this what other gates are for? I mean, when proposing an
oslo sync, each project has it's own gate plus integrated tests that
do this exact job.

Additionally, what about a periodic jenkins job that does the Oslo syncs and is
managed by the Oslo team itself?

This would be awesome. It would take the burden of doing the sync from
the project maintainers. Before doing this, though, we need to improve
the `update` script. Currently, there's no good way to generate useful
commit messages out of the sync.


Flavio Percoco

Attachment: pgpfQZZGqrqIv.pgp
Description: PGP signature

OpenStack-dev mailing list

Reply via email to