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 <alev...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev