Just wondering…
Could even just use GitHub since its all opensource.
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.
1 Like
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?
http://kris.me.uk/2010/10/01/svn-master-with-git-mirrors.html
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.)
-Aaron
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
- the aSmack build environment
- smack with 2 branches: ‘master’ branch with additional patches (we are currenlty in the process of submitting these patches upstram after they have been polished). And an ‘upstream’ branch with is the current svn trunk of smack.
- openfire: also with a ‘master’ branch to test new features/patches and again ‘upstream’ which is the current svn trunk of openfire.
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.
Hi Flow,
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.
daryl
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.
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 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.
I can not see any ‘anti github attitude’ and copyright concerns where never raised in this thread.
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.
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.
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).
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.
Current:
- Find out how to submit things to upstream
- Register at the community forums
- Post the modification as forum post and attach the .patch
- Smack developer downloads the patch, has to open it, apply it manually to a smack codebase to see how it’s working
- Smack developer write suggestions in the forum
- Dev sends second version of patch
- Smack developer needs to manually investige the diff between the 2 patches
Github:
- No need to register somehwere, because the dev forked on github and has therefore already an account
- Send branch pull request, enjoy “at line comments”, clustered commits, direct interaction between patch submitter and smack developers and online browsing of the commit(s)
- Have a sweet as hell, good looking, high quality patch (maybe even with testcases) after a some iterations
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.