good idea for global requirements

Let's submit a multi-project bug on launchpad, and be serious for changing
these global requirements in following days


On Thu, Jul 11, 2013 at 7:12 PM, Mark McLoughlin <mar...@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?
>
> 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.
>
> Cheers,
> Mark.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Gareth

*Cloud Computing, OpenStack, Fitness, Basketball*
*OpenStack contributor*
*Company: UnitedStack <http://www.ustack.com>*
*My promise: if you find any spelling or grammar mistakes in my email from
Mar 1 2013, notify me *
*and I'll donate $1 or ¥1 to an open organization you specify.*
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to