Open Stack

It is, but it's an important conversation we should have.

I'd love to start if off by suggesting that "I hate the..." might be 
less helpful than describing what you don't like about it. Finding sets 
of usecases and requirements is kind-of the first step to fixing something.

There is a bug in version detection logic that some debian packaging 
work pointed out. Code pulled from tarballs or whatnot should actually 
NOT be dependent on access to the git repositories, and there is 
machinery to that effect, but it checks for existence of some things in 
the wrong order. Sorry about that. I hope to have that bug fixed RSN.

We're all pretty reasonable people - if you have issues with something 
or if it's causing you problems, say something, I betcha someone can 
find a fix that might work for everybody.

Monty

On 11/26/2012 12:06 PM, Matt Joyce wrote:
> For the record, I hate the current over all version scheme of
> OpenStack.  The complexities generated by making the code reliant on
> access to the git repository it came from is problematic for many
> packaging scenarios.  And the cost to benefit seems unfairly biased
> towards code maintainers at the moment.
>
> But that's a different discussion.
>
> On Mon, Nov 26, 2012 at 7:21 AM, Monty Taylor <mordred at inaugust.com
> <mailto:mordred at inaugust.com>> wrote:
>
>
>
>     On 11/26/2012 06:38 AM, Doug Hellmann wrote:
>
>              I can picture one option where we would version oslo libraries
>              separately, based on classic major.minor.patch format. We
>         could make
>              "stable branches" based off major versions. That would be
>         separate from
>              the common development cycles and milestones, even if for
>         planning (and
>              summit) reasons you would still talk about "grizzly development
>              timeframe", and try to slow down towards the end of the
>         cycle. We can
>              push all versions to PyPI and use ">=1.2.1 <2" style to
>         solve the
>              dependency specification... and push to Launchpad in
>         parallel to provide
>              a sane, series-oriented view of the same deliverables.
>
>              How does that sound ?
>
>
>     I agree with this. I am not worried about presenting multiple
>     'potentially confusing' versions of the oslo libraries on PyPI in
>     the same way I am with client libraries, so I think this will work
>     just fine.
>
>     BTW - how's that upload-to-pypi jenkins job builder template coming
>     along? :)
>
>     Monty
>
>
>     _________________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.__org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>