Ideally (when we remove all the workarounds), the code should be dependent only on public APIs and oslo, but for the first few releases when some additional functionality is exposed in Nova for us to remove workarounds we might be dependent on particular releases - or if it's done via extensions or versioning and we can see what we're dealing with we also can be independent in terms of releases.

Best regards,
  Alex Levine
On 1/31/15 1:37 AM, Matt Riedemann wrote:

On 1/29/2015 5:52 AM, Alexandre Levine wrote:

I'm the lead of the team working on it.
The project is in a release-candidate state and the EC2 (non-VPC) part
is just being finished, so there are no tags or branches yet. Also we
were not sure about what should we do with it since we were told that
it'll have a chance of going as a part of nova eventually. So we've
created a spec and blueprint and only now the discussion has started.
Whatever the decisions we're ready to follow. If the first thing to get
it closer to customers is to create a package (now it can be only
installed from sources obviously) and a tag is required for it, then
that's what we should do.

So bottom line - we're not sure ourselves what the best way to move. Do
we put a tag (in what format? 1.0? m1? 2015.1.rc1?)? Or do we create a
My thinking now is to just put a tag - something like 1.0.rc1.
What do you think?

Best regards,
   Alex Levine

On 1/29/15 2:13 AM, Thomas Goirand wrote:
On 01/28/2015 08:56 PM, Sean Dague wrote:
There is a new stackforge project which is getting some activity now - The intent and hope is that is
the path forward for the portion of the community that wants this
feature, and that efforts will be focused there.
I'd be happy to provide a Debian package for this, however, there's not
even a single git tag there. That's not so nice for tracking issues.
Who's working on it?

Also, is this supposed to be branch-less? Or will it follow
juno/kilo/l... ?


Thomas Goirand (zigo)


OpenStack Development Mailing List (not for usage questions)

OpenStack Development Mailing List (not for usage questions)

How dependent is this code on current nova master? For example, is there a rebase or something that happens or things in nova on master that change which affect this repo and it has to adjust, like what happens with the nova-docker driver repo in stackforge?

If so, then I'd think it more closely aligns with the openstack release schedule and tagging/branching scheme, at least until it's completely independent.

OpenStack Development Mailing List (not for usage questions)

Reply via email to