As our source control system, we have been using Mercurial since a few years now and we like it. But lately we have been thinking about migrating our projects to GitHub, which would also mean a migration to git. One of the key reasons we are thinking about this is of course popularity, but also that GitHub seems to be better at handling cooperation and contributions. Our experience with GitHub is limited, but we have been using git in projects every now and then. So we would love to get some feedback on this. Even though it’s possible to push code on both (even easily between git/hg) we would like to stick with one alternative for bug tracking, milestones and such.
Loading ...
During the week we are working on preparing a new software release, at least for the pc client. A couple of things happens since last release including better log graph and altitude hold. Also the driver situation for windows will become better as we found a way to install the Crazyradio driver without restarting windows in maintenance mode. Finally we now have a mac and are planning more support for it in the future, no promises for this release though.
Some time ago we had a similar discussion at ownCloud.
Reasons for going to GitHub: everybody uses it.
Reasons against: closed source, lousy bugtracker.
The decision was not made democratically, now they use GitHub. (I say “they” because I no longer have time to participate.) From what I saw there was no difference in coding progress or code quality but we got a lot more bug reports. And duplicates ad infinitum.
My guess is that if someone really wants to help out on this project he’ll join Bitbucket if he does not already have an account.
Stay open source, use open source. Maybe gitorious?
DY
The duplicate issues is a concern. Currently we are mostly placing the issues ourselves, but having good quality issues with lots of information (and no duplicates) definitely saves time.
It’s true that people that want to contribute join BitBucket, and we think that some of our contributors might have done that. But still it might be easier for people to find the project and it lowers the threshold for contributors that are used to git/GitHub (although we could use git on BitBucket).
We’ll have a look at gitorious as well, but it doesn’t seem as mature.
I am using both platforms for open source projects.
From my perspective they are really comparable. On thing to keep in mind though is that the issue tracker at github is very minimalistic at best…
Yeah, the issue tracker seems a bit more basic. Looks like you can only set milestone and assigned, everything else is labels (like type/priority/component).
I think one appealing feature with GitHub are the metrics views. It’s easier for people to see how actively a project is being developed.
We use github a lot where I work as well as a private repo server. We find git to be far more convenient and lower-maintenance but that might just be normalcy bias. Issues on github will need curating but this is true of any publicly-writeable issue tracker. It will make the project more accessible though I believe.
Github does not offer a publicly-writable issue tracker AFAIK.
Bringing structure into the github issues can be done using Kanban boards:
https://huboard.com/
It takes some time to getting used to canban but IMO it’s good. It helps managing issues, but milestones etc. are all made by labels. It makes the bugtracker flexible but also confusing.
Short explanation to everyone who didn’t hear about canban:
http://kanbantool.com/kanban-examples
States could be
– new
– backlog
– needsinfo
– accepted
– in progress
– qa testing
– done
No, unfortunately you cannot set the attributes/labels of an issue on GitHub unless you have been added to the list of collaborators. But you can report, edit and close issues. I can see both pros and cons with this. That being said, I would have preferred to have this as an option.
Kanban looks like a good tool, but I think that it might be slightly overkill for our project. Previously we have used trackers like Trac, Redmine and various commercial solutions to do issues and tracking. If you are in a big company where you have project managers, QA testers and developers this is great. You can set up the life-cycle of an issue and as you work with the issue it progresses though the different steps and is assigned to different departments/people. Since the scale in our project is a lot smaller having a couple of states (like open/close/assigned) I think is good enough. But it’s good to know that there’s alternatives, like Kanban, that we could complement with in the future if needed. IMO the most important feature of any issue tracker is being able to export your data if you are not happy with it.
One thing that the GitHub issue tracker is missing is attributes for type/priority/component (like I wrote above). But using labels should solve this, although it might have been nicer with proper attributes. The label system seem to be good and from what I’ve seen other projects make good use of it. Like some projects setting “Easy” or “Hard” as labels to help potential contributors to select something to work on.