Agones: Split up project across googleforgames organisation

[markmandel]

We now have an organisation, so we don't _have to_ be a monorepo with this project. So let's explore options for what could be split out, and the pros and cons.

Having multiple repositories is a larger logistical overhead, but has easier implications for CI/CD as the entire monolith doesn't have to be tested, depending on which area is updated, and we can have more flexibility in approval/membership levels per repository as well.

List of items we could potentially split out:

agones-community

(already exists) Would include Governance items, and community management, etc.

agones-site

The website agones.dev. This is particularly nice, as the website has its own CI tests - but does mean we will need to track PRs between feature work on the main Agones repo, and documentation work on the website, and ensure both are approved at the same time.

agones-ecosystem

We could move out all our examples into that repository, and we could incubate game server SDK's in there as well that weren't as ready for production use yet. Downside being that some of these examples are tied to our e2e tests. Will need to work that out. Could also be easier to automate building our examples as well.

Anything else I haven't thought of that might be a good candidate?

My opinion would be to start with agones-community, and then move to agones-site. Agree/Disagree?

[thisisnotapril]

Looks good to me! I would prefer calling the website repo agones-docs versus agones-site; in the name of clarity.

[markmandel]

I would prefer calling the website repo agones-docs versus agones-site; in the name of clarity.

I could probably make the argument that the site is more than docs - it's the landing page, the community links, the blog, etc.?

Does that change your opinion?

[roberthbailey]

For the website, another option is to require documentation to be merged _before_ the code lands (with the appropriate version gates). This would be a forcing function to actually write documentation and ensure that the code we are adding can be explained to end users.

[roberthbailey]

I'm not sure I see a huge benefit moving the examples out unless it's paired with the SDKs moving. Many of the examples are intended to showcase SDK integration, and they should live wherever the associated SDK is.

[roberthbailey]

My opinion would be to start with agones-community, and then move to agones-site. Agree/Disagree?

That makes the most sense to me. We can look at breaking code out later if we think it's necessary.

[thisisnotapril]

It's mainly a preference thing; I give you this one in the name of Founders Choice. 😄

[roberthbailey]

I prefer agones-site or agones-website. I think the later is the most clear and descriptive. We will still have docs for agones spread amongst various repos (right now there are readmes for building, etc along with the code and they will stay there) so I think that agones-docs is actually too broad of a name.

(aside: naming is always the hardest part)

[markmandel]

Sounds like we have concensus on doing agones-(web?)site as well, so we can move forward on that.

Either site or website works for me. I don't have a strong opinion.

Meta question: CI for the website, will that be Prow, or will we continue to use Cloud Build?

[roberthbailey]

I vote for prow!

[markmandel]

Sounds good. Are we going to maintain a similar Makefile/Docker build/test paradigm? I vote for yes, just because it should be a relatively simple lift and shift operation.

[thisisnotapril]

Voila - new repo! https://github.com/googleforgames/agones-site