On Tue, Aug 9, 2016 at 11:54 AM, Hayes, Graham wrote:
>
> It might not make a difference to deployers / packagers who only deploy
> one project from OpenStack, but they are in the minority - having a
> known good minimum for requirements helps deployers who have multiple
> services to deploy.
>
-Original Message-
From: Chris Friesen
Reply: OpenStack Development Mailing List (not for usage questions)
Date: August 10, 2016 at 11:50:48
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [requirements] History lesson please
> On 08/10/2016 04:51 AM, Erno Kuv
On 08/10/2016 04:51 AM, Erno Kuvaja wrote:
On Wed, Aug 10, 2016 at 9:27 AM, Thomas Goirand wrote:
Not necessarily. Take for example Swift. It has lower requirements than
other projects in OpenStack. Yet, Swift is fully co-installable with all
other OpenStack projects. They just support lower
On 08/10/2016 07:30 AM, Ian Cordasco wrote:
> To be clear, I think the requirements work Tony is doing has the potential to
> make things worse for some subset of deployers/operators.
>
> --
> Ian Cordasco
Any change we make has the potential to make things worse for some subset :P
--
-- Mat
-Original Message-
From: Erno Kuvaja
Reply: OpenStack Development Mailing List (not for usage questions)
Date: August 10, 2016 at 05:53:14
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [requirements] History lesson please
> On
: August 9, 2016 at 13:17:08
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [requirements] History lesson please
>>
>>> I'd like to advocate for *not* raising minimum versions very often. Every
>>> time some OpenStack
>>> pro
On 08/09/2016 09:09 PM, Doug Hellmann wrote:
> We've tried to be consistent in telling packagers to use the
> versions listed in upper-constraints.txt unless there is an absolute
> need to use something else. Those are the versions we test, and
> therefore the versions we claim to support right now
On 08/09/2016 08:54 PM, Hayes, Graham wrote:
> But then packagers are going to have to do the work anyway, as it will
> have in effect raised the minimum version of routes for Glance, and thus
> need a new package.
Which isn't a problem. It's perfectly ok to upload a new upstream
release of a pack
ubject: Re: [openstack-dev] [requirements] History lesson please
>
>> I'd like to advocate for *not* raising minimum versions very often. Every
>> time some OpenStack
>> project raises minimum versions, this change is propagated to all projects,
>> and that
>
On 08/09/2016 08:25 PM, Julien Danjou wrote:
> On Tue, Aug 09 2016, John Dickinson wrote:
>
>> I'd like to advocate for *not* raising minimum versions very often. Every
>> time
>> some OpenStack project raises minimum versions, this change is propagated to
>> all projects, and that puts extra bur
On Tue, Aug 09, 2016 at 03:14:43PM -0400, Davanum Srinivas wrote:
> +1 for volunteers to step up.
I'll do it and I have a *very* basic prototype done. It wont be in Newton
though. Having said that if there is another volenteer I'm happy to work with
them or free up time :)
Yours Tony.
PS: Repl
ync the patches created by the bot.
>
> Doug
>
>>
>> On 9 Aug 2016, at 9:24, Ian Cordasco wrote:
>>
>> >
>> >
>> > -Original Message-
>> > From: Sean Dague
>> > Reply: OpenStack Development Mailing List (not for usa
n Dickinson
> >> Reply: OpenStack Development Mailing List (not for usage questions)
> >>
> >> Date: August 9, 2016 at 13:17:08
> >> To: OpenStack Development Mailing List
> >> Subject: Re: [openstack-dev] [requirements] History lesson pleas
> > Reply: OpenStack Development Mailing List (not for usage questions)
> >
> > Date: August 9, 2016 at 11:21:47
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [requirements] History lesson please
> >
> >> On 08/09
On 08/09/2016 01:37 PM, John Dickinson wrote:
> In that case, they are still co-installable, because the nova minimum
> satisfies both.
The requirements project currently advocates the use of
upper-requirements.txt as what is targeted for packagers. This is
what's tested.
--
-- Matthew Thode (
ugust 9, 2016 at 13:17:08
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [requirements] History lesson please
>>
>>> I'd like to advocate for *not* raising minimum versions very often. Every
>>> time some OpenStack
>>>
ubject: Re: [openstack-dev] [requirements] History lesson please
>
>> I'd like to advocate for *not* raising minimum versions very often. Every
>> time some OpenStack
>> project raises minimum versions, this change is propagated to all projects,
>> and that
>> puts ex
-Original Message-
From: John Dickinson
Reply: OpenStack Development Mailing List (not for usage questions)
Date: August 9, 2016 at 13:17:08
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [requirements] History lesson please
> I'd like to advocate
fyi, Just so you all know. It's upper-constraints.txt. Note the word "upper" :)
-- Dims
On Tue, Aug 9, 2016 at 2:25 PM, Julien Danjou wrote:
> On Tue, Aug 09 2016, John Dickinson wrote:
>
>> I'd like to advocate for *not* raising minimum versions very often. Every
>> time
>> some OpenStack proj
On Tue, Aug 09 2016, John Dickinson wrote:
> I'd like to advocate for *not* raising minimum versions very often. Every time
> some OpenStack project raises minimum versions, this change is propagated to
> all projects, and that puts extra burden on anyone who is maintaining packages
> and dependen
ailing List (not for usage questions)
>
> Date: August 9, 2016 at 11:21:47
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [requirements] History lesson please
>
>> On 08/09/2016 11:25 AM, Matthew Thode wrote:
>>> On 08/09/2016 10:22 AM
-Original Message-
From: Sean Dague
Reply: OpenStack Development Mailing List (not for usage questions)
Date: August 9, 2016 at 11:21:47
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [requirements] History lesson please
> On 08/09/2016 11:25 AM, Matthew Th
Date: August 9, 2016 at 09:53:53
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [requirements] History lesson please
>>
>>> One of the things on our todo list is to test the 'lower-constraints' to
>>> make sure they still wo
k.org
> Subject: Re: [openstack-dev] [requirements] History lesson please
>
>> One of the things on our todo list is to test the 'lower-constraints' to
>> make sure they still work with the head of branch.
>
> That's not sufficient. You need to find versions in
-Original Message-
From: Matthew Thode
Reply: prometheanf...@gentoo.org , OpenStack
Development Mailing List (not for usage questions)
Date: August 9, 2016 at 09:53:53
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [requirements] History lesson please
> One
Excerpts from Tony Breeds's message of 2016-08-09 16:38:35 +1000:
> Hi all,
> I guess this is aimed at the long term requirements team members.
>
> The current policy for approving requirements[1] bumps contains the following
> text:
>
> Changes to update the minimum version of a library
On 08/09/2016 09:25 AM, Ian Cordasco wrote:
>
>
> -Original Message-
> From: Sean Dague
> Reply: OpenStack Development Mailing List (not for usage questions)
>
> Date: August 9, 2016 at 05:44:55
> To: openstack-dev@lists.openstack.org
> Subject: Re: [o
-Original Message-
From: Sean Dague
Reply: OpenStack Development Mailing List (not for usage questions)
Date: August 9, 2016 at 05:44:55
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [requirements] History lesson please
> On 08/09/2016 02:38 AM, Tony Bre
On 08/09/2016 02:38 AM, Tony Breeds wrote:
> Hi all,
> I guess this is aimed at the long term requirements team members.
>
> The current policy for approving requirements[1] bumps contains the following
> text:
>
> Changes to update the minimum version of a library developed by the
>
Hi all,
I guess this is aimed at the long term requirements team members.
The current policy for approving requirements[1] bumps contains the following
text:
Changes to update the minimum version of a library developed by the
OpenStack community can be approved by one reviewer, as lo
30 matches
Mail list logo
