Gophercloud 0.2.0 Vision (and some rambling brain-dumps)

[Samuel Falvo II]

First, I'd like to say thank you again for all your help. I could not
have reached the 0.1.0 milestone without it. (Or, at least, if I did,
it'd look very, very different!) But, my job isn't over, and I'm
still open to assistance getting Gophercloud's APIs off the ground.
If you or someone you know is willing to help, I'd welcome them with
open arms!

A quick update from my development efforts -- I'm hoping this is the
last time I have to spend any significant amount of time retracing my
steps. I never want to have to rewrite the Nova API again.
Gophercloud is seriously behind in support for cloud files and DNS,
both of which I'd hoped to have a head-start on by now. No, we're not
under any particular deadlines (anymore, I think), but still, I'm
getting cabin-fever spending all my time with Nova. And, I suspect
Packer and Nebula are getting impatient with my progress, though they
haven't said anything yet. I think they're just being polite.

My goal for 0.2.0 is to attain feature parity with 0.1.0, but using
the new API. I'm adding tickets to the 0.2.0 milestone to reflect
that fact. I need to finish the cloud servers actions endpoints, and
re-implement automatic re-auth again. Then, it'll be time to port
over the various extensions that have been implemented in 0.1.0 since
I started working on 0.2.0. It's like I'm playing catch-up to a
moving train, but as of the release of 0.1.0, I'm putting on the
brakes.

If any additional APIs or extensions are required, we can add them in
subsequent milestones -- the 0.2.1 milestone has already been created,
for example.

As many of you know, v0.2.0 has its own topic branch. All of my
contemporary work happens here. If I can implore, I'd like all new
feature development to occur relative to the v0.2.0 branch, at least
untill we merge to master. I'm not going to delete the v0.1.0
software, but it should be considered "sunset" code at this time. We
should support it only insofar as bugs and security issues require us
to support it. I'd love your feedback on how long to keep it in the
repo.

If keeping development work in the v0.2.0 branch instead of master
proves too inconvenient, we can review how best to address this
problem going forward for the v0.2.1 release. Ideally, I'd like to be
able to estimate when we can release the next version, or how many
features it takes to constitute a next version, etc. Unfortunately,
my ticket-keeping skills have been lacking between 0.0.0 and 0.1.0, so
it's difficult for me to say _exactly_ when work started on 0.1.0. It
was a pretty organic out-growth of the 0.0.0 release as I recall. So,
sans data, I can't even give you an overall velocity measurement for
the project.

It's pretty slow though. I can say that much. Hopefully work on
0.2.0 will yield better data and, qualitatively, improved velocity.

Please let me know if you have any questions. I'm happy to answer
where I can; however, I'm also hoping the code that exists is fairly
self-evident. (One complaint I often received on IRC was that 0.1.0
code doesn't "feel" like idiomatic Go.) If it's not, let me know, so
that I can either explain or fix it. :)

--
Samuel A. Falvo II

[Alexander Scammon]

Sam, thanks for all your efforts!

-Alex

>--
>You received this message because you are subscribed to the Google Groups
>"gophercloud-dev" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to gophercloud-d...@googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.