Move Google to a separate Gem

[icco]

I imagine this process will be talked about a little at the summit, but I'd love to do this this summer.

I'd be curious about your thoughts on doing this @geemus.

Questions that have popped in my head:

• Should the gem be owned by the fog organization or Google Cloud?
• Testing policies?
• Licensing?
• Switch to semantic versioning?

etc.

[geemus]

Yeah, we'll definitely discuss this. I think fog org should continue to hold the extra repos. Testing can probably be up to the individual repos, though we want to try and move toward better shared testing infrastructure to help with this. You can kind of see some of the testing ideas in fog-core. I'd prefer to keep things as MIT licensed as things are presently to simplify (instead of having different licenses all over the place). More semantic versioning would be nice, but we probably will need to sync with fog/fog-core to some extent, this remains as one of the more painful/unknown parts of the equation.

@tokengeek - could you chime in with what you've found and what you are thinking so far with your brightbox work?

[tokengeek]

Yeah.

It's been mentioned before about a generator / templates for providers which I think is probably the next best step before people start hand rolling new modules.

For testing I was thinking something following these lines... http://wojtekmach.pl/blog/2012/07/17/liskov-principle-and-minitest/ so fog-core would include testing/specification classes that fog-provider would subclass in their tests and should pass.

The Github repo, for better or worse seems to be the most useful division. Most of the Ruby tooling (Bundler) and online services (Travis, CodeClimate) work better when the repo covers the module. It means confirming a simple change doesn't take 40minutes to run everything and application developers can target modules directly.

Repo ownership should end up as fog for officially supported (by core team) gems. The Github permissions need shuffling so that a new core team can then help out in any place.

Licensing - I'd stick with the same to keep things easier. Anything not using MIT should NOT be referenced by the fog meta gem.

Nightmare situation would be customer's apps using fog, fog picks up fog-example and we spend far too long arguing if that means every customer's closed source code need to be released because the "ABC" licence makes all dependant code subject to its terms. (Or even discussing that some backend provider's SDK under Licence ABC affects everyone else, gem dependencies and licences etc. etc.)

We probably need a licence review and document rules as well just in case we missed something added in good faith.

Semantic versioning - we should be using semantic versioning anyway in both fog and submodules.

Where this may catch people is if fog-provider makes a major (backwards incompatible) change and wants that referenced by the meta gem. That effectively forces a major update to fog

So I think we need to discuss major release schedules so we know it happens every x months and lock down fog dependencies to pessimistic providers.

Being aware of this I've been working to keep fog-brightbox compatible so require "fog" and require "fog/brightbox" should be the same major API.

[frodenas]

@icco what's the status of this? I'd like to see a separate google fog gem, so if you need help on splitting it, let me know as I can contribute.

[plribeiro3000]

👍 Just let me know how i can contribute on this as well. =)

[geemus]

I'm happy to do the repo/org side of the setup, just let me know when you need it.

[icco]

It was unclear to me at the end of the summit which direction we were going. I'm fine either way.

[geemus]

I think it was unclear to everybody. Since then we have been moving more and more toward split though. Both have issues, but it seems like the issues are less in the split (or at least MY issues are less as it makes it easier for me to distribute ownership/responsibility). There is the dependency-hell threat, but outside of that it seems to be going pretty well so far.

[plribeiro3000]

@geemus I'm glad i'm being part of this. 👍

[icco]

Ok, I've got a coworker who wants this split to happen for the GOOG. @geemus, could you create a fog-google repo?

[plribeiro3000]

@icco ❤️ 👏

[geemus]

Created. It has an admin-priv group called fog-google that you are a member of also (and can add the coworker if you think that makes sense). When it is further along I'll just ask for gem privileges as well. Otherwise, we've been through it a few times now, so just let us know if you have any questions or concerns along the way. Thanks!

[icco]

Cool, thanks!

[ikehz]

Per fog/fog-google#3, we are reconsidering whether or not we want to make the switch to a separate fog-google repo immediately.

Initially, it was thought that the codebase was stable and that porting could happen; however, although while fog support for Google is currently functional, the tests do not give us an accurate picture of what's broken and what's not, (i.e. the mocks don't accurately represent the real service, so tests may be erroneously passing or failing; see #1266 and #1252, among others). So, better to stabilize those tests, make sure that they accurately represent reality, then port over.

@geemus @tokengeek how would you all feel about us writing (new) minitest tests in this repo (fog/fog) before porting over to the fog-google repo? I see that minitest is already a development dependency, but currently there is no provider coverage in minitest-land.

[plribeiro3000]

@ihmccreery What about feature freeze, extract the codebase, remove the code from fog and then work on top of the extracted code?

As i can see the codebase is large and make it read can take months. These would also help us with the roadmap. somehow.

EDIT: I think that write tests in minitest is also g2g.

[ikehz]

@plribeiro3000 Thanks for the comment. If I understand you correctly, that was our original intention. The trouble is, we're not confident enough in our test suite to be sure that the extraction isn't breaking code in ways we don't know about.

[plribeiro3000]

Got it. The thing is that if you do not depend on any code outside the google folder it should be a smooth migration. When extracting you can keep the original structure in all points without changing the requires for google in fog and it will work as it was before.

I can give it a tackle and do a clean extraction so you guys can work on top of it if you want. With all the providers i´ve extracted it was as simple as that. After the removal of fog i could work to improve them without issues.

[geemus]

Let me know if any help is needed here. The extractions so far have been pretty non-transformative, so I don't think we've had any cases of it introducing errors that didn't already exist. I think it should likely be pretty safe, but certainly understand your hesitation.

[ikehz]

If you all think this is the best move, I definitely defer to your (much more experienced) opinions.

I'm mostly concerned about the state we're currently in, where the google directory structure is duplicated between fog and fog-google, and neither references the other.

@plribeiro3000 If you're willing to do a clean extraction for us, that would be awesome. (I've talked with @danbroudy, and he's good with blowing away what's currently in fog-google.) We're happy to put in engineering time fixing tests and whatnot, but we'd like to get everything in one place before putting in serious time. If you've already extracted other providers, and you're confident, please, please go ahead with it.

[plribeiro3000]

Sure. I will do it asap. Can i just dump the current repo?

[danbroudy]

Yes please and thanks! Feel free to dump the current repo.

[ikehz]

@plribeiro3000 When you do dump the current repo, please be sure to keep @icco and @erjohnso as committers.

And, just to get a sense so we can plan accordingly, what's a rough timeline we can expect this in? Sometime today? The next few days? Longer?

And definitely let me know what I can do to help out.

[plribeiro3000]

@ihmccreery Its almost done. it should be ready today. Could you give me access to the repo?
Currently i don't have and @geemus is not online.

Thanks!

[plribeiro3000]

@tokengeek Can you give me access to the repo?

[ikehz]

@erjohnso or @icco should be able to do so as well, (I can't).

[erjohnso]

Added @plribeiro3000 - thanks!!!

[plribeiro3000]

@erjohnso Thanks!

[geemus]

Thanks!