Open Stack

I could see the real issue here is the maintainers for EC2 API code.
If this is the case - create a sub-group with core members in it, who
will be responsible to maintain this code like other projects.

On Sat, Jan 31, 2015 at 2:54 PM, Alexandre Levine
<alevine at cloudscaling.com> wrote:
> Matt,
>
> 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:
>>>
>>> Thomas,
>>>
>>> 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
>>> branch?
>>> 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 -
>>>>> https://github.com/stackforge/ec2-api. 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... ?
>>>>
>>>> Cheers,
>>>>
>>>> Thomas Goirand (zigo)
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>>
>>>> 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
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>
>> 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)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev