Open Stack

On 07/11/2013 09:36 AM, Dolph Mathews wrote:
>
> On Thu, Jul 11, 2013 at 6:12 AM, Mark McLoughlin <markmc at redhat.com
> <mailto:markmc at redhat.com>> wrote:
>
>     On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote:
>      > On Wednesday, July 10, 2013, Sean Dague wrote:
>      >
>      > > Yesterday in the very exciting run around to figure out why the
>     gate was
>      > > broken, we realized something interesting. Because of the way
>     the gate
>      > > process pip requirements (one project at a time), on a current
>     gate run we
>      > > actually install and uninstall python-keystoneclient 4 times in
>     a normal
>      > > run, flipping back and forth from HEAD to 0.2.5.
>      > >
>      > >
>     http://paste.openstack.org/**show/39880/<http://paste.openstack.org/show/39880/>-
>     shows what's going on
>      > >
>      > > The net of this means that if any of the projects specify a
>     capped client,
>      > > it has the potential for preventing that client from being
>     tested in the
>      > > gate. This is very possibly part of the reason we ended up with
>     a broken
>      > > python-keystoneclient 0.3.0 released.
>      >
>      >
>      > > I think we need to get strict on projects and prevent them from
>     capping
>      > > their client requirements. That will also put burden on clients
>     that they
>      > > don't break backwards compatibility (which I think was a goal
>     regardless).
>      > > However there is probably going to be a bit of pain getting
>     from where we
>      > > are today, to this world.
>      >
>      >
>      > Thanks for investigating the underlying issue! I think the same
>      > policy should apply a bit further to any code we develop and consume
>      > ourselves as a community (oslo.config, etc). I have no doubt
>     that's the
>      > standard we strive for, but it's all too easy to throw a cap into a
>      > requirements file and forget about it.
>
>     I don't think we've ever capped oslo.config anywhere. Got a pointer to
>     what triggered that concern?
>
>
> No no, I didn't mean to call you out... just using oslo.config as a
> prime example of a non-client project that should (and from my
> perspective: does) abide by the same policy.
>
>
>     We should/could be capping oslo.config like this:
>
>        oslo.config>=1.1.0,<2.0
>
>     because the API stability commitment is that we won't break the API
>     without bumping the release number to 2.0. I don't anticipate doing 2.0
>     soon/ever, so I've never pushed ahead with that capping.
>
>
> I think that capping on the major version number is acceptable, as long
> as we require major version bumps to break backwards compatibility...
> and don't do major version bumps on a regular basis.

The problem is, the gate has not good way to navigate this ATM. So the 
moment someone caps major versions of a client don't get tested.

So let's go with complete uncapping for now, and only deal with the 
major version issue if it actually comes up.

	-Sean

-- 
Sean Dague
http://dague.net