Migrating to a GitHub organization

[ebkalderon]

This is a big step, but I think I'm ready to migrate the Amethyst repositories away from my personal account to a GitHub organization. Before I do this, I need to confirm the following matters:

1. What are the potential consequences? I know that the Git repos and their associated metadata will be automatically redirected. But what about:
   • The Amethyst book and docs on GitHub Pages
   • The links on TWIA, Twitter, Reddit, etc.
   • The Gitter chat (some people have had issues when transferring ownership)
2. Is everyone okay with the name? I picked "amethyst" since that was what was available. Would you prefer "amethyst.rs" or something completely different?
3. We need to decide on a concrete branching model that complements our Semantic Versioning strategy. @LucioFranco suggested Git Flow on the Gitter chat. It might be overkill now, but if we continue growing it could become necessary.
4. I have registered the "amethyst.rs" domain through ISTanCo! How would you like the website to be organized? Here are my thoughts:
   • amethyst.rs: The main website
     • amethyst.rs/book: The online Amethyst book
     • amethyst.rs/doc: Rust API documentation
   • blog.amethyst.rs: Redirects to This Week in Amethyst on Wordpress (unless we successfully migrate it to gh-pages, see #26)
5. The Gitter chat is starting to get really busy. I'm considering splitting it into multiple rooms. See this GitterHQ post about Community Pages to see how it could look. Is this a good idea? If so, how should the rooms be organized?

Current Status

Here's the current status of these questions, as gathered from our collective discussion both on this issue and on Gitter:

• Eliminating possibly broken links
  • Book and documentation: I will make a pull request against master on this repo to "future-proof" these links before taking down https://ebkalderon.github.io/amethyst.
  • Links on TWIA, Twitter, Reddit, etc: For the wiki pages, I can fix broken image/file links by moving images over to the organization website repository. The WordPress blog can remain open for a little while longer to preserve old links, and I can make a post asking followers to migrate to the new site and feed.
  • Gitter: I guess we can't prevent link breakage, so I will keep the old chat open for continuity. However, everyone is urged to move to the new chat once it's deemed ready.
• Organization name choice
  • No complaints on the name yet, so I am assuming the silence == agreement. 😄
• Branching strategy
  • We will follow the Git Flow branching strategy, which is essentially equivalent to what GFX does.
• Website organization
  • Again, no complaints from anyone, so I guess we're good on this one!
• Splitting up the Gitter chat into different rooms
  • General consensus is a general channel + 1 channel for each repository. I personally want documentation to be a separate room since it crosses repository boundaries. How does this room layout look to you guys?
    • documentation: Discussions about the book and API documentation
    • engine: Development discussion about the engine
    • general: Team-wide announcements and answering general questions
    • random: Off-topic discussion and other tomfoolery
    • tools: Development discussion about the toolchain around the engine
    • website: Contributing to the website and the TWIA newsletter

[LucioFranco]

For #3 I think we should go with something similar to what gfx/gf-rs does and have a stable or master branch, it contains the current code that has been tested. We can then have branches for every 0.X release and for every 0.X.Y release we can just put those commits on top of the 0.X branch. Everything else seems good!

Edit: I forgot but we could track our minor and hotfixes via git tags.

[LucioFranco]

For #3 I think we should go with something similar to what gfx/gf-rs does and have a stable or master branch, it contains the current code that has been tested. We can then have branches for every 0.X release and for every 0.X.Y release we can just put those commits on top of the 0.X branch. Everything else seems good!

Edit: I forgot but we could track our minor and hotfixes via git tags.

[ebkalderon]

@LucioFranco I would personally prefer having a single release branch with each release version being tagged, similar to Git Flow's approach, mostly because I can see the sheer number of branches becoming overwhelming a few major versions down the line. What do you think about this?

[ebkalderon]

@LucioFranco I would personally prefer having a single release branch with each release version being tagged, similar to Git Flow's approach, mostly because I can see the sheer number of branches becoming overwhelming a few major versions down the line. What do you think about this?

[White-Oak]

@ebkalderon I'm up for this. But if, in the future, someone will request a bugfix for an older version (say, 1.5, when current is 1.7) it makes sense to branch out from tagged release and submit a bugfix.

[White-Oak]

@ebkalderon I'm up for this. But if, in the future, someone will request a bugfix for an older version (say, 1.5, when current is 1.7) it makes sense to branch out from tagged release and submit a bugfix.

[ebkalderon]

@White-Oak That is absolutely correct, yes.

[ebkalderon]

@White-Oak That is absolutely correct, yes.

[LucioFranco]

@ebkalderon Sorry for the delayed response was on vacation. I agree with your point. One thing that I want to bring up is the future support of 0.X or when time comes A.X releases. One issue with theses is that they are more likely to need long-term support. It may be nice to only create branches for very major releases. This will allow for a cleaner way of managing old releases and to easily submit bugfixes. I find that git tag is very complicated to hotfix code without added branches. So it may be worthwhile having a few branches for major releases. We can always delete old branches. Besides that, I think everything looks good!

[LucioFranco]

@ebkalderon Sorry for the delayed response was on vacation. I agree with your point. One thing that I want to bring up is the future support of 0.X or when time comes A.X releases. One issue with theses is that they are more likely to need long-term support. It may be nice to only create branches for very major releases. This will allow for a cleaner way of managing old releases and to easily submit bugfixes. I find that git tag is very complicated to hotfix code without added branches. So it may be worthwhile having a few branches for major releases. We can always delete old branches. Besides that, I think everything looks good!

[White-Oak]

@LucioFranco you can always branch out from every commit, so I don't see, why keep branches, instead of creating them when they are needed.

[White-Oak]

@LucioFranco you can always branch out from every commit, so I don't see, why keep branches, instead of creating them when they are needed.

[LucioFranco]

@White-Oak will that not add a bunch of hotfix branches that need to be added to the repo? You need to create a new branch to hotfix no matter what unless you wanna do git magic. So to me, it makes more sense to have a major branch and just add the hotfix commits on top of that. But what I am also saying is that we do not keep smaller versions for branches. If someone has an issue with 1.5 we just tell them to upgrade to the latest because it has no breaking changes instead of hotfixing 1.5. But if there is an issue with 1.3 and we are on 2.1 there would be a release-v1 branch that we can then easily hotfix. We can still use git tags for every version to keep track but going into detached head mode with git tags is not an easy thing to deal with.

[LucioFranco]

@White-Oak will that not add a bunch of hotfix branches that need to be added to the repo? You need to create a new branch to hotfix no matter what unless you wanna do git magic. So to me, it makes more sense to have a major branch and just add the hotfix commits on top of that. But what I am also saying is that we do not keep smaller versions for branches. If someone has an issue with 1.5 we just tell them to upgrade to the latest because it has no breaking changes instead of hotfixing 1.5. But if there is an issue with 1.3 and we are on 2.1 there would be a release-v1 branch that we can then easily hotfix. We can still use git tags for every version to keep track but going into detached head mode with git tags is not an easy thing to deal with.

[White-Oak]

@LucioFranco compatibility between minor versions is a myth

[White-Oak]

@LucioFranco compatibility between minor versions is a myth

[LucioFranco]

@White-Oak so what you suggest then is to just keep everything tagged with git tag and then when a hotfix is needed create a branch for it?

[LucioFranco]

@White-Oak so what you suggest then is to just keep everything tagged with git tag and then when a hotfix is needed create a branch for it?

[White-Oak]

@LucioFranco yes, why not? If a version is compatible with current one, then a separate branch is not needed, but sometimes there'll be a need.

[White-Oak]

@LucioFranco yes, why not? If a version is compatible with current one, then a separate branch is not needed, but sometimes there'll be a need.

[LucioFranco]

@White-Oak That makes sense. That means we only need extra branches for that one off occasions where someone needs an old hotfix.

[LucioFranco]

@White-Oak That makes sense. That means we only need extra branches for that one off occasions where someone needs an old hotfix.

[LucioFranco]

@ebkalderon
For the rest of the items. I think we should just split our Gitter chat into:

general
engine
documentation
render possibly

And I don't think there is a way of preserving the hyperlinks and I think it is better that we move soon rather than later to run into less of these types of issues.

[LucioFranco]

@ebkalderon
For the rest of the items. I think we should just split our Gitter chat into:

general
engine
documentation
render possibly

And I don't think there is a way of preserving the hyperlinks and I think it is better that we move soon rather than later to run into less of these types of issues.

[White-Oak]

@LucioFranco there should be a room for website

[White-Oak]

@LucioFranco there should be a room for website

[LucioFranco]

@White-Oak I was thinking of combing website into documentation. There could probably be a better name.

[LucioFranco]

@White-Oak I was thinking of combing website into documentation. There could probably be a better name.

[Aceeri]

@LucioFranco Maybe information?

[Aceeri]

@LucioFranco Maybe information?

[White-Oak]

@LucioFranco I do not really think website should be merged with documentation.

[White-Oak]

@LucioFranco I do not really think website should be merged with documentation.

[LucioFranco]

@White-Oak why is that? I think that there is not going to be much website talk so there should just be one chat for all things related to stuff on the website including the documentation.
Edit: I think we should have a general channel, and then one for each repo.

[LucioFranco]

@White-Oak why is that? I think that there is not going to be much website talk so there should just be one chat for all things related to stuff on the website including the documentation.
Edit: I think we should have a general channel, and then one for each repo.

[ebkalderon]

@LucioFranco Personally, I prefer to keep webdev and documentation separate since I consider them separate things. Our conversations about CloudFlare, domain names, and TWIA are completely separate from, for example, adding book chapters or improving misleading docs.

While the book and API docs happen to be hosted on amethyst.rs, they are stored in the amethyst repository for a reason. They are meant to be accessible locally, not just online, and should be treated separately from the website. Does this make sense?

However, I do agree with you that the overall structure should be a general channel and then one room for each repo. I just want documentation to be a separate room since it crosses repository boundaries.

[ebkalderon]

@LucioFranco Personally, I prefer to keep webdev and documentation separate since I consider them separate things. Our conversations about CloudFlare, domain names, and TWIA are completely separate from, for example, adding book chapters or improving misleading docs.

While the book and API docs happen to be hosted on amethyst.rs, they are stored in the amethyst repository for a reason. They are meant to be accessible locally, not just online, and should be treated separately from the website. Does this make sense?

However, I do agree with you that the overall structure should be a general channel and then one room for each repo. I just want documentation to be a separate room since it crosses repository boundaries.

[LucioFranco]

@ebkalderon that makes sense! I think we should go ahead with what you suggest!

[LucioFranco]

@ebkalderon that makes sense! I think we should go ahead with what you suggest!

[White-Oak]

@ebkalderon sounds reasonable.

[White-Oak]

@ebkalderon sounds reasonable.

[ebkalderon]

Okay. I've updated the top post with the candidate Gitter chat layout. Looks good?

[ebkalderon]

Okay. I've updated the top post with the candidate Gitter chat layout. Looks good?

[ebkalderon]

I think we have reached a consensus on all of the proposed issues! We are ready for the transition.

[ebkalderon]

I think we have reached a consensus on all of the proposed issues! We are ready for the transition.

[ebkalderon]

We are almost done! This is all that is left:

• Codify the branching model in either CONTRIBUTING.md or on the wiki.
• Wait for Gitter issue 1185 about improving our chat rooms to be resolved

[ebkalderon]

We are almost done! This is all that is left:

• Codify the branching model in either CONTRIBUTING.md or on the wiki.
• Wait for Gitter issue 1185 about improving our chat rooms to be resolved

[ebkalderon]

With the tasks above complete, this issue is now considered resolved.

[ebkalderon]

With the tasks above complete, this issue is now considered resolved.