Could even just use GitHub since its all opensource.
If we would choose the gatekeeper model, then no infrastructure changes would be needed. We still could use the svn as central repository. I don't think that Atlassian-Jive is 'old schoold' or should be replaced. We are not discussing the bug trackier, CI system nor the build system. It's just about using git as VCS. It just would be easier for active smack users to suggest improvements and to review them.
Also there is no relation between the used VCS and the efficiency of the CI system or the quality of the documentation.
You are right that most patches that come from the community are of a low quality. But nobody is talking about merging every crappy patch on github into the trunk. It's a normal procedure that patches need to get reviewed and rewritten, often multiple times, to enter the master branch/trunk. The Linux kernel as sole reason that git exists uses that approach successfully, and provides a great example how git could help us to improve the development @ ignite.
Git would not have helped with file transfer bugs? Let me prove that you are wrong: Take SMACK-334 for example: That was fixed in aSmack on 2011/02/28: https://github.com/Flowdalic/smack/commit/71a651785165ae8d46567f3c0e29304257b07c e3, a hole month before the patch hit the smack trunk: http://fisheye.igniterealtime.org/changelog/smack?cs=12212
Ok, Robin wrote a unit test for it. But that could also be suggested on reviewing the patch, sparing Robin the work.
And yes, I was the one wo reported SMACK-334 at that time in the forum. But what if I hadn't cared, because the problem was solved for me? The work to find out the current way to report upstream smack bugs is enourmous compared to a simple pull request on github. Third party devs don't even need to submit pull request, we could easily follow their forks and see their modifications to smack and then decide if they are worthy to be cherry-picked/merged.
And don't think that everyone that uses Smack is reporting bugs upstream. I had to motivate some developers to report his smack modifications upstream. Not sure why they didn't do it in the first place. I can only guess that they had no need to because the problem was fixed for them (and smack is apache licensed).
Moving to Git or GitHub would cuae significant administrative effort. If we would have several people to do this, it might be a good idea. I would rather spend some more effort in testing/coding for Openfire instead spending some admin effort.
I've noticed a lot of open source projects jumping ship off of SVN to github. 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? (due to the use of hashes vs. version no.s)
Git has done an amazing job at making the transfer over easy though, however with a repository that has been touched by so many people it might be a major hassle to make sure all of the commits / tags / branches make it over with the proper history.
I've never had issues getting tags / trunk into git - i have had issues with getting branches over, I think it has to do with how git works with branches off the origin, but i'm not too sure to be honest.
Why not Subversion Master With Git Mirrors?
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.
I had the same though when I saw that openfire/smack/etc was still managed with svn. But given the fact that development is somehow stalled because there are very few maintainers, svn is absolute sufficient. Also projects on github tend to ignore QA, but, on the other hand, are more feature rich.
Therefore it seems to be the best to stay on svn. Given the open source nature of the projects here, everyone is free to fork the code and add new features. In fact, this has already happend for smack (as base for aSmack): Some Android App developers (including me) have created an smack community fork. We have added many new features and bugfixes to smack, most - if not all - are tracked by the offical JIRA tracker, but won't get merged because the smack development here seems to be very cautious about code changes.
I think jive would see a different change if they hosted their projects on github and used git over svn.
As an OpenSource developer there are a lot of benefits with managing pull requests through github and using git branching/forking over svn.
Also speaking from experience with giving patches it'll take a HUGE load off the maintener of this project.
PLEASE PLEASE host Spark on github. I'd love to commit to this project once again, but am afraid to do so due to previous communication problems and changes jive had.
(Sorry to bring back an old topic, but I think this would make a big different for Spark.)
Second attempt so solve this, since I also think github may improve development by attracting new developers and making patch reviewing and submission easier.
As you prably don't know I am involved in aSmack. That is the Android port of Smack. I have 3 repos on github
Since I do some openfire and smack development, I am willing to review pull request send by github and or other patches that arrive via git. I think acting as gatekeeper to the svn trunk is a good idea, reviewing patches often reveales one ore more things that could be improved.
So the question is: Should we make an annoucement that there is an somewhat official repo on github that can be used for merge requests/patch submission?
If more ignite developers are present on github, it may be a good idea to create 'Ignite Organisation'. But if not, then I would like to keep the git repos where there are in order to avoid changes on my workflow.
I am not in favour of officially or semi-officially moving to github. The added confusion/complexity in infrastructure does not outweigh any potiential benefits.
What individual developers choose to use is entirely up to them. If you're happy using Git, Stash, Mercurial, or any other VCS privately, by all means, keep using that. However: publicly, I see benefit of having just one piece of infrastructure in place that is the official repository for our projects source code.
My unoffifical policy is to not stop people when they volunteer for doing work. I would like to see ignite repos moved off svn to git, be it github or running a git server ourselves. I do think we would get more contributions if we were on github and I believe our tools (Jira, bamboo, fisheye) support repos served there as well.
I would be in favour of creating an Igniterealtime organization at github and if nothing else, sitting on it for the time being. If you wanted to do the work of keeping the upstream svn insync with github, that would be fine by me.
We don't really have a formal voting procedure or governance. I did ask Jive if they were okay with us moving code to github and they did not have a problem with it.
I share Walter's view about time being very precious to all of us and being better spent on fixing things rather than administrative tasks, but if we could spend less time with more hands and better tools, then moving from SVN to Git is a good idea.
I also share Guus's view not to move to github.com and keep everything here in one place at igniterealtime.org. I see the benefits of Git, but can't see the greener grass at github.com
Could we spend effort on a having a Git repository here rather than moving to github.com and keeping both in sync.
One thing of github which we wouldn't have if we host the repos with plain git and gitweb is the nice code review/commenting feature.
E.g. I can make comments, suggestings improvements on https://github.com/ge0rg/smack/commit/291a63902a2bb3d62585a7f838112d90ab456d94
and of course on any other commit hosted on github. But if we had the same possibility if the repos were hosted at ignite (maybe fisheye supports it) then I we could host it here too. But please don't forget and underestimate the momentum you get with the easy way to fork a project on github and to create merge requests. This is an github exclusive feature.
I can only share my experience with smack but in the last 3 years many patches have been collected on various git forks of smack (e.g. http://repo.or.cz/w/Smack.git and there are a few more git repos). It's a real pitty not to use them. All of them got unoticed by smack development. Alone the number of patches the buddycloud project discovered when they started aSmack is something about 20. Or the various memory leaks a-iv discovered when working with aSmack for xabber. As I said before, we are currently polishing those patches and prepare them for smack submission. Many of them are already in trunk, mostly the smaller ones.
IMHO we don't have to move the main repos to git. But giving developers a possibility to submit patches with git would be a good idea. Therefore I suggested the gatekeeper model, because most patches have (minor) problems that need to be fixed bevore they are integrated in the trunk.
But making a full git transation is also a good option. The gatekeeper modell works with git too.
I would like to make a rather long winded entry into this discussion. I will start though by saying that the personal insults and condescending remarks add nothing to the discussion. They are not helpful and simply set up an adversarial situation which negatively impacts any further discussion.
There are a few ideas being thrown around here when it comes to using Git, such aa the svn mirror and gatekeeper model. I think what may be being missed with these suggestions is that they actually feed into the problem that is being brought up by several of the actual contributors. They make the infrastructure MORE complex, thus increasing administrative overhead. I can understand that both of these models can and do work for many organizations, but they require resources that we simply do not have. Kudos to Flow for vounteering to be the gatekeeper, but that is simply creates a single point of failure in the whole process.
The other problem I have with this approach is it creates a fragmented environment for would be developers. I would rather see a single consistent means of contributing. Your current example of your Smack fork, in my opinion, is more of a problem than help. It can easily lead potential contributors to simply think that "hey, how come my code hasn't been adopted yet" when in fact they have not actually made a "formal" contribution at all. It would have been much better if they had simply contributed a patch file that could have been logged and attached in Jira, like many other contributors do. I am sure this could have been accomplished in Git as well (generating a patch).
OK, so I know at this point, you are all thinking I am against moving to Git, I am not. I am not yet convinced that the grass is so much greener on the other side, it is after all just a tool, not your "deity of choices" gift to development. It's time will pass as well, just like SCCS, RCS, CVS, ... and the list goes on. What I need to be convinced is not knowing how great Git is (I have actually used it), but how well it can be integrated with Jira and the igniterealtime site as a whole. I suspect that this is all very doable, as it is being done by projects like Spring and Jenkins and the like already, but the fact is I don't actually know for sure (these projects also have many more resources than we do). I do believe though that if this is the route we choose to go, then Github would seem to be the logical route. I don't see why we would want to host and administer our own instance of Git. This just adds to our own administrative overhead, which is what we specifically want to avoid, unless there is some downside to using Github that I am not aware of (a very real possibility). I know we don't have too much admin responsibility in this area right now, but we do have to get someone from Jive to add new users and the like (I think that is still the case).
I would certainly prefer to see a consistent means of administering the code base in all the projects, but I don't think that it is absolutely necessary. It would be a hell of a lot more convenient though as several developers, like myself, contribute to more than one project. So I would certainly prefer the consistency. I think this also makes the whole community more cohesive. That being said, we could also take the approach of migrating one project as a test, but I fear that that would be very difficult to undo if it doesn't work out (putting the genie back in the bottle and all that). The natural choice for this would be Smack, as there is obviously some traction in this regard already.
In any case, I would prefer to see this discussion continue in a private forum amongst the current active contributors, leads and admins. Other interested parties can obviously continue to add there comments, suggestions and the like here, but I would like to have a frank discussion with all the parties that would be most affected by this decision, and I think that would be better accomplished in private. I know that may annoy a few external interested parties, but I believe it will lead to more progress on this issue.
It wouldn't create a single point of failure if there wasn't only one person who had control over the "staging" git repos. I find reviewing patches as plain '.patch' files not ideal.
But sure, yes, it adds a bit of extra infrastructure. The real question is: Is it worth it? And I tend to say "yes".
I don't think that a fragmented development environment causes any problems. If someone really wants to get things upstream he should also be able to read the documentation on how to send patches. But that alone is a long-going discussion when it comes to VCS vs DVCS, which has taken place in the linux kernel and on a dozen other projects.
I still think official git repos would be a good idea, be it as sole VCS instance or as gatekeeper for the svn (which would mean no changes to the current infrastructure setup btw).
But in the end I am happy with the situation as it is now.
If you use github, you get rapid easy forking with pull request managment and a network view o get all together in mind. Very valuable !!!!
Why not use git on own server (if you are afraid your code can get lost/robbed on github - however how is that possible with OS and complety cloned repos on many developers disks?) and have a mirror on github also. Mirrors are easy possible, see here: https://www.chiliproject.org/projects/chiliproject/wiki/HowTo_mirror_your_git_re pository_on_Github
Then community can easily fork there and branch, pull ... and ur super geek priviledged chief coder can merge that stauff into the "official" igniterealtime.org repo (btw. i would be mor afaraid what this small company or some maintainer will decide tommorow than on github).
Community on github has much moch focre and wight than on igniterealtime.org, i am pretty sure. Where are the real concers? Isn't openfire Opensource, what right shall be concerned? What really behind this anti github attidude. Sounds like primnal fear of lost of control of code of "some coders baby".
I can not see any 'anti github attitude' and copyright concerns where never raised in this thread.
Just thought I'd toss my 2 cents in...
Github (and git) attract a lot of newer developers (think fresh blood!). Github is all the craze these days and if your a developer and don't have a github account with some projects, then you're a "nobody" essentially (as seen by other newer devs). In school we were taught how to use git, and no other way of version control I have friends that have similar experiences.
Having the project on Github also makes discoverability greatly enhanced. Github is super easy to use and comes with GUI tools for free so that people who are intimidated by the cmd line or fear screwing something up have a way to still contibute easily.
Also, branching on Github allows any developer to create a branch of the trunk and work on it to their hearts content, and eventually issue a Pull request to merge back to thte mainline -- all from the webgui or gui tools. This would allow any dev to create a branch and work on it, committing to their branch as often as they want, then issue a Pull request for review. If the Pull is accepted, then it can be merged back to mainline, otherwise it could be rejected and the dev can continue work. very easy and very simple. Also, on Github other developers can see all branches from the project, meaning you can check out what another dev is working on and possibly even contribute to his/her patch to help out.
Github keeps track of number of commits by individual, and a lot of other statistics. So you can quickly see who's the most active, who is contributing the most/least, how the project is growing over time, etc. Your project can be "followed" by others and you can follow other projects... so there is a huge social aspect to using Github as a community. To Github frequenters, these stats are almost a status thing, like achivements.
I think github would increase project awareness, discoverabilty, attract new developers and interest, simplify patching, etc. I think the benefits outweigh the cons... even though there might be an awkward transition period.
EDIT: branch is not the same as forking the project. Forking could happen too... and the fork could contribute back to the upstream (mainline in this case)... and Github keeps track of all forks as well. The branching is just a way for many devs to work on teh same codebase at once, all committing to their branch and it is all logged to the Repo under their branch, so anyone can see a snapshot of whats being worked on when... etc.
Getting fresh developers into the equation is certainly something we would need, but...
We have very few ressources. Moving to Git will require dedicated work for several weeks. An we will loose the tight dev environment of Bamboo-Fisheye-Jira. One might argue that the used Atlassian-Jive stack is "old school" but it works and has caring hands. Who is building such a tight environment for Smack or Spark on Github. If I look at Spectrum.im that is on Git, there is nothing even close to the level of documentation&continous build as we have with Spark.
I would also state that Robin and my team have worked a lot on the "patches" that come out of the community. Those are not necessarily always right. Robin is keeping Smack very thight and I think he is right by being careful and restricitive. Too many projects use it.
Quality coding does not depend on Git, SVN or such. It needs continous integration/JUnit tests and deep understanding of the code. We spends weeks to understand nasty file transfer bugs in Spark/Smack and fix them. Git would not have helped. JUnit test cases and a good documentation would have.
Git does also not help to release a software. Getting the next Spark out is about testing, multi plattform and documentation. It takes 5-10 days to do so and I simply do not have dev ressources at hand to do so.
Sigh, this is the biggest problem with every patch I see. Everyone wants to write code to fix something (OK, not really everyone), but noone wants to write tests to actually prove it fixed it, and more importantly, prove it didn't break something else. You would be hard pressed to find a patch contribution anywhere on this site that actually includes test cases, but I digress.
I also think that git(hub) would be benefical here. Compare the current patch submission workflow with how it could be:
Imaging a dev who made a modification to smack. He is happy because it now works for him. He is also motivated and kind enough to share his modification with us.
I think it's no wonder that no patch submitter writes test cases for smack: There is a lack of good documentation on how to write good test cases for smack. Unit tests are easy, integration tests are slightly more complicated. And the mocked connections are currently are black box for me. And this would be the test case type thats most important.
We should start a "How To" as document, giving tips on how to start, point to some simple smack test cases that make it clear how they work as code examples, what should be tested, how it should be tested, what can be tested, etc. Including "leassons learned" and "best practices" for the test cases.
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.
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.
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.
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 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 ;-P ).
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.
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.
Jason wrote: I understand Jira to be quite expensive and JiveSoftware donated the copy we use?
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.
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 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
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:
just if anyone was interested... here's an example repo i setup for Spark pulled from latest SVN trunk using svn2git.
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.
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:
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.
Retrieving data ...