Open Stack

Ian Cordasco wrote:
>
> On 7/10/15, 03:44, "Thierry Carrez"<thierry at openstack.org>  wrote:
>
>> Joshua Harlow wrote:
>>> Hi all,
>>>
>>> I was thinking about those who are packaging with venvs (and using the
>>> version of a project in the venv file name); like what anvil[1] is now
>>> capable of (and does this in the gate now[2]) or packaging via rpms
>>> (which anvil also does) and they are going to be affected by the version
>>> shrinkage that just recently happened this cycle.
>>>
>>> Soooooo that got me around to thinking, why aren't all the projects
>>> setting an epoch[3] in there setup.cfg (for the ones that had a version
>>> shrinkage from 201X.Y to something small) to make it less painful for
>>> all these people (and to make it obvious to those reading setup.cfg and
>>> looking at the version number that a epoch change just happened)...
>>>
>>> So I proposed https://review.openstack.org/#/c/200187/ (to cinder) but
>>> didn't want to push something similar out everywhere before getting more
>>> input, is there any reason we should not do that? Is there a better way
>>> to do that? (Or something else I am missing?)
>> As Robert posted on the review:
>>
>> a) pbr doesn't support epochs [yet]
>
> Is there a bug for this? I'll be happy to tackle it.
>
>> b) the release team specifically decided not to epoch things.
>>
>> Also you'll find that the various distros use different epoch values for
>> the same software, because epoch are also used to cover local blunders
>> in packaging and historical artifacts. That is why epochs should be
>> local to each packaging system and specifying it upstream is imho
>> counter-productive.
>
> So, unpopular opinion time, but I think we restrict ourselves way too much
> based on a false notion that the only people who consume OpenStack are
> consuming it via downstream packages. Joshua has pointed out a very real
> use case (deploying inside a virtual environment) and there are also cases
> where people build from source and will be (attempting) to upgrade from
> 2015.1.x to 11.0.0 or 8.0.0. Even if people only use PyPI as a way of
> determining version order, using epochs will be significantly better for
> them. Perhaps I'm too late to the discussion, but it also appears no other
> opinions were solicited for it, especially not from users or operators.
>

Not IMHO unpopular, in fact I agree with it (but maybe that means I'm 
unpopular to, ha). IMHO the epoch values 'reasons' as Thierry specified 
are exactly what we are trying to do, openstack had a 'cover local 
blunders in packaging and historical artifacts' *moment* by having date 
based versions and changing it 4+ years into the game and now it needs 
to correctly handle that 'blunder'.

> Specifically, I'd like to understand why using a feature of PEP 440 to
> explicitly indicate a shift in version numbering is "counter-productive".
> It seems like it would be very productive for people who aren't tightly
> integrated into the development process.
>

I'd like to know that to; and it IMHO raises another question, why did 
we go about changing all the versions without epoch support in the first 
place? Shouldn't we make sure PBR (or other tool) has epoch support, 
then change the version numbers, not the other way around?  (I do not 
question the reasoning to change the version numbers themselves, I get 
that, just the ordering of how it was done...)

> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev