Migrating to a GitHub organization

[amethyst]

Migrating to a GitHub organization

[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 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]

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]

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

[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.

[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.

[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.

[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

[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.

[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.

[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.

[Aceeri]

@LucioFranco Maybe information?

[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]

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

[White-Oak]

@ebkalderon sounds reasonable.

[ebkalderon]

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