Ok, let’s play the thought of moving Spark to Github. Who is doing it? Who takes care about continous integration and releases? At the current point in time I know two teams working on Spark with a focus on bug fixes and one of us is putting features in (not me). There is a simple way to get Spark to Github: Someone has to start the initiative and make that plattform working for a community development project. I am not against it, but I do not see someone moving on it.
Oh I should maybe make one point clear: I have no desire to move Spark to git, since I am in no way involved in this XMPP client. My attention is focused on Smack and Openfire. But I think every project chould benefit from a git repository.
And maybe I should elaborate what I mean when I speak of the gatekeeper modell: The idea is to put a public git repo somewhere (ideally github), which keeps track of patches that mature in their own git branches. Once the patch has achieved good quality it will be merged into the master branch. This branch is kept in sync with the current svn repository.
This means that your workflow regarding everything (CI, releasing, …) won’t change a bit. 
No objection against a copy of Spark at Github. From my point of view it is as good and actually desired as any internal copy within the companies that develop patches for Spark. The most crucial thing is the publication of patches (like the Smack-334). Patch review and integration into a release is a must that needs to be done anyway.
I agree that moving to GIT for version control is necessary. Clinging to old SVN isn’t benefiting anyone. It sets teh barrier to entry higher than it should be (no one learns SVN now-a-days unless they have to), limits how we as a community can track developer progress (branches and forks in git/github), makes partch reviewal process bigger than it should be, makes patch submitting process more cumbersome than it should be, etc…The whole point of Git/Github is decentralized development (branches and forks) that is easily controllable and maintainable and mergable back into mainline. Plus all the “social” benefits of Github for all developers (including increased discovery of igniterealtime projects.
I’m willing to setup and help maintain the Spark repo as this is the project I currently have most interest in. I’ll wok on getting the latest SVN trunk into a GitHub repo including tags, etc. (using svn2git https://github.com/nirvdrum/svn2git ).
When I have it completed I’ll need to change it’s ownership to an Organization setup as IgniteRealtime so that it is out of an individual’s ownership.
I think someone already said that Jira and the build process woudl integrate with Git or preferably Github without much issue (other than setting it all up).
Interesting video where Linus Torvalds discusses Git and why it’s better than all other VCS (in his opinion of course, having written the thing i’m sure he’s bias, but he does have a good track record 
).
EDIT2: I HIGHLY recommend everyone watch/listen to this video. It very clearly lays out how Git differs from all other VCS mainly CVS/SVN. Just put it on and minimize the tab so you can listen to the audio why working or whatever.
http://www.youtube.com/watch?v=4XpnKHJAok8
EDIT: I just want to post that I am strongly NOT in favor of runnig our own GIT installation. I think it would end up being the same as we have, only slightly improved due to it being Git. We should only be looking at options to migrate to Github for all the Git benefits as well as all the Github-only benefits.
Nice to see that there is another one who believes that git could help us in many areas.
I am not sure if git2svn should be used to create the git repos. I just use git-svn am I am happy with it: I can life without the tags in tag: If a tag is needed after some time I can easily create it manually. And the “branches are remote svn branches” behavior doesn’t matter to me too. You can also manually create a local branch with one simple command if you need to.
If they are hosted by us or github doesn’t really matter. I would start with github. If we encounter any reasons not to use github then we can also easily change the location thanks to git.
We would maybe need an internal git repo for syning git (e.g. @github) with the official svn repositories. This can be easily done with a cronjob. There are a few situations where the sync may has to be done manually because of a needed merge. But given the fact that there aren’t that many patch submissions right now I don’t think that it will be much work.
Just to be clear, I do not support having SVN at all, even for “master repos”. Git fixes just about everything wrong with version control, and it makes little sense to run both concurrently, especially if our toolchain will support Git/Github. In order to fully realize the benefits from Git/Github, we need to jump fully in, not just put our toes in the water to appease some developers, so-to-speak.
Also, having Github do the repo hosting reduces igniterealtime’s overhead in having to run servers to maintain the code repositories. I could be horribly mistaken, but currently I believe JiveSoftware has been kind enough to donate a Repo server among other things. What happens if this server fails one day? Is JiveSoftware going to dedicate resources to get it back up quickly? What happens if JiveSoftware one day decides not to support igniterealtime any longer? Do we have offsite backups somewhere other than some developers SVN Trunk pull? Github solves all of this plus more.
I realize there will be great overhead in the conversion, but this is only temporary. In the big scheme of things, it is minor, especially if we can significantly reduce the burden of the project leads (for merges, patching, etc), attrack new developers, plus more.
The saying goes “we must slow down in order to speed up”.
@Flow - svn2git is developed and maintained by the Github people, I trust it to do a proper conversion to Git, including preserving tags, etc. If we are to create new repo’s, this is surely the only proper way to go (maintain history). The linux kernel dumped their version history when switching from bitkeeper to git (and now are on github themselves), so it is possible to migrate without preserving these things. IMHO this would only make sense at a release of each poject. For example, Spark is getting ready for 2.7.0 release, once released we could do a cold turkey switch to Github and have a fresh codebase. Not as ideal i think, but could be done and that’s the logical point to do it.
I don’t think that we have the manpower to do a full switch to git. JIRA and fisheye needed to be reconfigured to use the git repo. I am not even sure if those tools support git. That’s why I am in favor of additional git repos that supply their commits back to svn. No need to change the current infrastructure.
git-svn also preserves the whole history, including tags and branches. It’s ideal if you work with an remote svn repository. svn2git seems to be the solution of choice if we wanted to do a full git switch.
if it must be done that way, then so be it. Jira will most surely support git and github, however the question would be does our version? I understand Jira to be quite expensive and JiveSoftware donated the copy we use? Current version of Jira and Fisheye support Git (and github). Looking at the addons, there is a Stash plugin that adds some more git stuff, although Im not clear on what exactly.
It’s just that having Github repos for all developers then the Project maintainers still have to diff the repo and manually merge is redundant. I guess if we were to make Github the primary and then once a month or whatever the Project maintainer pulls the entire tree and merges the entire thing into SVN then it would be less work, so essentially SVN would act as a “snapshot” of the github repos for release/pre-release builds.
My fear is fragmenting the projects if we dont’ have 100% backing and support from everyone to push forward and move into github. Using github the way you envision would mean Github repos would always be ahead of the SVN trunk, and all developers should go to github and pull/branch the current repo before starting development… committing to their own branch whenever, and eventually issuing a Pull Request to the github repo for merging back in. Then once a month or whatever, Project Maintaner pulls the entire repo and essentially replaces the SVN repo with this codebase. The use of SVN purely becomes legacy support for the build system toolchain.
lol, your documentation is a key example of soemthing that would benefit from being in github!
you could post it into the Smack repo, and someone could clone the repo to local and work on the documentation simultaneously as you do, and then issue a pull request to merge back into mainline with your document. Github would then provide a nice graphical way to see conflicting changes, etc.
in SVN, no such thing since only a select few have commit access, so right away, killed all collaboration.
Jason wrote:
I understand Jira to be quite expensive and JiveSoftware donated the copy we use?
The bottom of the website explains the license / cost situation. http://issues.igniterealtime.org/
excellent - looks like we are on a free license. Seeing it’s version 5.1, it’s fairly recent… and should support Git/Github.
Sorry Jason, but SVN is not killing the documentation. And the choosen few with commit rights is about peer review prior comiting to the product. That’s not necessarily uncommon. Look at Firefox.
Most patches provided to the open forums will be reviewed and subsequently commited. Not all patches.
Guys, hold your horses. A shut down of the SVN at Jive and a complete move to Github is not agreed and if I see that correctly no one of the current code maintainers (Guus, Robin and myself) sees this as an urgent issue. The current setup is working and prior and “close SVN” statement I rather see a new setup working. Not only on technical base but also from contributors base. And I am talking about consistent & continous contributions of quality code.
We need code and features and not a plattform discussion. aSmack shows more features/patches as Smack. Why? Because of the a=Android or because of GitHub being more “sexy”? Maybe both, but certainly not because of “SVN scared everyone…” it did not scare my team nor the one of Martin Steinmann. Both have contributed significantly to Spark.
Most commercial development organizations are on SVN and not on Git. “Git rulez” is much about the current perspective of a person. I have no objections against a GitHub hosted Spark. As said before. But I object a dismanteling of our current plattform. I am only one opinion, but the same applies to Jason.
I should rephrase since thats not what I meant.
I was giving an example of something in particular that would benefit from being in Git/Github. Documentation is that example.
Currently, someone as an individual comes up with documentation and posts it in the forum for review. Everyone hates doing documentation, and everyone hates reading documentation… so perhaps only a couple people look at it… suggest changes in the forum or make changes locally and post their version in the forum. etc… etc.
With git/github, someone could start documentation, say maybe only a rough outline and then commit it to a branch of the mainline repo. Then other devs can download the same copy of the documentation and work simultaneously on it, committing their changes to their branched repos. Then it can all be merged back together with the niceness of graphical merge conflict resolution.
Therefore, my point was that git/github encourages this type of collaboration. I know my example isn’t the strongest, but it is a good example where git/github excels over SVN.
In conclusion of my point, SVN does not allow the same type of collaboration. Currently only a select few have commit rights, and all others must rely on other methods of collaboration. This is how SVN was designed. Wtih git/github, everyone can commit and only the best commits are actually made into the mainline. So everyone can benefit from mutual collaboration simultaneously. Basically as the project maintainer, you don’t care what or how many branches or forks exist, you only care about the people issuing Pull requests to merge back to the mainline, and then it’s easier to see where conflicts will occur.
I think the primary benefit of being on github is the attention things get in github, being that you can search github for open source projects. It might get some more eyes stumbling our way; however, you are absolutely right. The source control system is not going to be the deal breaker in whether or not someone wants to contribute to this project/product.
The usefulness of the product/project and perceived value gains from doing so are going to be the motivating factors
Hello Walter,
I greatly respect your opinion.
I believe the github thing is not about it being “sexier” or not… it’s more about it being a much better tool that is more available to more people.
I think the SVN works as it is, obviously otherwise igniterealtime woudl have moved away long time ago. But I think the community must be careful to not sideline new stuff because we are comfortable, if the new stuff can have added benefits.
There’s a few people right now willing to help make it happen… but 100% support is needed.
Please watch/listen to this:
As one of the “more recent” contributors to Openfire who is also an occassional contributor to various Github projects, I’ll toss my $0.02 in as well.
I would assert that the process of contributing here (via SVN plus the Jive tools) is not particularly strenuous or complicated:
- I started with a read-only copy of the repository to learn the structure of the project and build procedures.
- After becoming familiar with certain components I started contributing patches here and there under the guidance of the core committers.
- As I became proficient with various components of the code base and more consistent with my contributions I was able to earn committer status.
No fuss, and no perceived or actual roadblocks. At this point I continue to participate as and when I can, fixing issues, answering questions, and responding to community posts where applicable.
Sure, Github has a lot to offer - including spontaneous forks from eager contributors - and I enjoy using it for other projects like Hazelcast. However, in my experience the current process here at Ignite Realtime is also working quite well given the relatively small “staff”. If the team decides to move to Github I will happily go along, but I do not think it’s required to ensure the continuing viability and success of this project.
2 Likes
just if anyone was interested… here’s an example repo i setup for Spark pulled from latest SVN trunk using svn2git.
https://github.com/SnakeDoc/Spark-Unofficial
It kept all tags and commits. Github gives some interesting stats on the repo thus far (click Graphs).
I added markdown documentation to the root to please github. I’m not committing to maintaining this repo (yet) unless there is an interest in doing so. If anyone wants to branch/fork this repo for their own use, feel free. I plan to keep the master branch in sync with the SVN repo and use alternate branches for development. Allowing a merge to the master every now and again.
Jason, your point is, that moving to Github will raise interest and we get more code contributions. No hurdles and 100 % support from me for that idea. Try it.
Any patch over there is highly welcome and we use the gatekeeper approach of Flow until we are sure that we achieve the goal of better code/features whatever.
Did they ever solve the issue with GIT where it’s easy to go back in revisions but absolutely impossible to go forward if you’ve gone back?
That was never a git issue. You can always go forward as long as you still have the commits, which is always the case as long as you don’t deleted them manually.
If that was true, then git would have been pretty useless right from the start.