I’ve established an igniterealtime organization on github, https://github.com/igniterealtime ,and am willing to help any ignite projects move there if they wish. If nothing else, I am cybersquatting on the name so it doesn’t get taken by somebody else
Personally, I would like to see all projects moved there. Our svn development and number of developers on svn is very small. I have no doubt we’ll see an increase in activity on github.
So please let me know your github account and I’ll get perms setup there for you to create repos, etc.
I have setup a Spark repo on Github under my account, and used svn2git to convert the SVN repo into a Git repo (preserving revisions, commit messages, etc).
I am unable to transfer it to the igniterealtime organization until I am added. My account is: SnakeDoc
Once the repo is moved to under the igniterealtime organization, I will setup a cron on one of our servers over here to sync the SVN and Git repo’s together, using the SVN as the master for now. I’ll set it to run at GMT midnight since we have a pretty international community, hopefully that is convinient for everyone.
I figure we will have some transition period where we are still using both repos. Having the Git repo sync from the SVN repo for at least a few months may be good for this reason. This should give some time for people to transition to the new Git repo at their own pace.
Git repo structures are usually slightly different than the normal SVN repo... such as we will probably want to move or copy the README and LICENSE docs out of the documentation directory and instead have them sit in the root directory. I'll convert the HTML docs to Markdown docs for the root directory, this way Github displays some nice info when you land on the repo's page.
Once the repo is moved to under the igniterealtime organization, I will setup a cron on one of our servers over here to sync the SVN and Git repo’s together, using the SVN as the master for now. I’ll set it to run at GMT midnight since we have a pretty international community, hopefully that is convinient for everyone.
Mirroring svn ↔ git is usually not an good idea. It just adds unneeded addtional complexity. The best approach is to set the svn repo read-only and start using git. But I am not a Spark developer, that this is not really something that concerns me.
I figure we will have some transition period where we are still using both repos.
I don’t see a reason why we should have such a transition period. It only allows people to delay the unavaoidable, which will only cause us more work in the end.
Git repo structures are usually slightly different than the normal SVN repo
Correct, but the changes are trival. The biggest difference is that git doesn’t keep tags and branches in special directories. Instead, branches and tags are pointers to commit SHA1s. Simply as that.
For every new (or experienced) git user, I really recommend reading “Pro Git” by Scott Chacon, which is freely available under Git - Book
Please wait for my posting regarding VCS in the next couple of days before making any “official” repos on Github. I want to start a serious dialog on this topic with feedback from contributors and leads on all the projects.
@Daryl - Thanks for adding me. I believe Walter is currently listed as lead. I have just transfered the Spark repo to under the organization.
@rcollier, @Flow - I think we should have a discussion on this, since this time we seem to be making more traction than in previous conversations.
We need to come to a consensus of how to manage the repos, since there are multiple ways to do so.
I propose we create a Team on github (under the igniterealtime organization) for each project, and interested parties can be added under that Team. (an individual can belong to multiple teams) This limits the scope of who can commit to what repo unless that project’s lead adds you (assumably after some trust has been established). For non-trusted contributors, I propose they Fork the repo, work locally, then issue a Pull Request to merge back into the main repo. This allows for a more traditional Gatekeeper approach. The current Team setup on the organization is only the “Owners” Team, which has full control over all repos under the organization. This should be reserved for the main community members who have the most trust.
For repo branching, I propose the following: Master branch is for currently deployed/released version of whatever project and is always successfully buildable by the CI. Development branch is for all new changes going into the next release. Contributors Fork the repo and work from Development branch. When they finish their work, they issue a Pull Request to merge into the Development branch. After the Gatekeeper(s) review, they allow the Merge and the Pull Request get’s auto-closed, or reject and the person re-works the crappy code or whatever – This keeps a similar work-flow to what we have now.
Guessing wait till we get an official response from Guus, yourself and the rest of the dev crew before we push anything. I don’t want to jump the gun (too much ) but would love to be able to commit some of my Maven built plugins if possible.
I think one of the first commits ought to be the maven-openfire-plugin project which Stefan so kindly wrote. It’s already hosted on github, so not sure if we simply reference it or ask Stefan if it’s OK to import it into the Ignite repo: