Hi,
I'd like to revive this thread[1]. I wasn't around during the initial thread but Jiri has just pointed me to it and I read it through. I'd like to summarize (at least my take) on that thread and then list some pros and cons to stimulate a discussion.
Disclaimer: I am not an expert on anything, but I've used both Subversion (via SourceForge and Google Projects) and Git (via GitHub.com and Gitorious). Also, this is as much about not using SourceForge as it is about switching away from Subversion.
Summary from previous thread: The people in the thread who do not want to switch to Git, or those who don't seem to care either way, are those who have commit access to Subversion on SourceForge. Most (if not all) contributors to Geany are using Git (via git-svn). The workflow for those who don't have commit access on the subversion repository, when contributing to Geany is sub-optimal (to put it politely). SourceForge is painfully slow and the interface for viewing SVN source code online isn't great.
I think the reason GitHub/Gitorious is mentioned so much is not only because of the "Git" in their name, but also because it allows people who don't have commit access to actually be active members in the community, by means of having their public forked repositories, sending merge/pull requests, etc.
Cons from the previous thread: - It's more social - Not plain enough (I guess too Web 2.0/feature-full/cluttered) - Effort required to move the project - Having to learn a new VCS for those not familiar with Git
Pros from the thread: - It's more social - It's not so plain (ie. has more features which work well). - Moving the codebase and history is very easy, for example using the script from the thread or GitHub offers you to import a SVN repository through the web interface when creating a new repository. - Easier to contribute to the project for those without write access - Faster hosting and better interface. - Harder to have patches slip through the crack. - Not having to maintain/create patches as much/at all. - Public contributor repositories associated with the main one. - No need to maintain changelog and authors files - Proper attribution, blame and history for contributors and not having to put "Thanks" in all the commit messages.
Not sure if I missed any, or misconstrued them.
Here's some features of better project hosting sites. I'm listing things from GitHub because I know it better than Gitorious and others:
- Great source code viewer, branch/file browser, history/commit viewer. - Ability to link to and comment on commits and even specific lines of a commit, for code review, etc. - Nice network graph viewer to get a better idea of what everyone else is working on, needs to be commited, etc[2]. - Tracker for pull/merge requests so no need for contributors to generate/maintain patch(sets) and keep bumping ML threads so their patches don't go forgotten. - Fork queue to compare other peoples repositories' commits against your repository to cherry pick specific commits, with an indication of whether or not the commit/patch will likely cleanly apply - Good issue/bug tracker - Built-in Wiki software - Nice graphs to show languages, impact, commit activity, etc - Web hooks to notify by email/ML, IRC and other services of commits, etc.[4] - No need to create nightly tarballs separately since the server takes care of this automatically when users clicks the Download link.
Hopefully this will stir up a little discussion about actually switching because every time I use SourceForge I die a little inside :) I think switching to one of the Git project hosting sites will really help the community/contributors get involved and feel like part of the team while still making sure the official code is controlled by a great team of core developers.
Obviously I'm not suggesting that the SourceForge project page is deleted, just switching the main development activity to elsewhere. We could have a git/svn mirror over at SourceForge still, and even keep their bug/feature tracker, though I can't see why, since it's pretty lousy.
It really wouldn't be hard either, the whole "switch" be done in probably 10-15 minutes, maybe 1-2hrs to wait for the history to be imported. There's no real reason it needs to be a big deal either, we could test out another project site and keep it the way it currently is still with not much extra effort, just someone/somescript needs to push to the new project page after committing to SVN. Basically all it would take beyond that is for one of the founders/core members to take some time to setup an account and push the code.
I already have a Geany repository[5] I use over at GitHub.com if you want to play with it to test out that site. Also, Jiri has an old repository[6] on Gitorious. Neither are exactly up to date. It's fun also to see the Geany hackery already happening on these sites[7][8].
Sorry again for the long message.
Cheers, Matthew Brush
[1] http://lists.uvena.de/geany-devel/2010-June/002602.html [2] https://github.com/blog/39-say-hello-to-the-network-graph-visualizer [3] https://github.com/blog/270-the-fork-queue [4] https://github.com/github/github-services [5] https://github.com/codebrainz/geany [6] http://gitorious.org/geany/complete [7] https://github.com/search?langOverride=&q=geany&repo=&start_valu... [8] http://gitorious.org/search?q=geany
Nice summary Matthew,
As far as I remember it, seems to be accurate.
Summary from previous thread: The people in the thread who do not want to switch to Git, or those who don't seem to care either way, are those who have commit access to Subversion on SourceForge. Most (if not all) contributors to Geany are using Git (via git-svn). The workflow for those who don't have commit access on the subversion repository, when contributing to Geany is sub-optimal (to put it politely). SourceForge is painfully slow and the interface for viewing SVN source code online isn't great.
Agree with all of the above.
I think the reason GitHub/Gitorious is mentioned so much is not only because of the "Git" in their name, but also because it allows people who don't have commit access to actually be active members in the community, by means of having their public forked repositories, sending merge/pull requests, etc.
Whatever host is chosen, it must support non-project users having public forks.
Pros from the thread:
[...]
- No need to maintain changelog and authors files
Changelog and authors are still needed for tarballs, but maybe they can be automated?
- Proper attribution, blame and history for contributors and not having to
put "Thanks" in all the commit messages.
Still needed as above.
- Built-in Wiki software
That could be useful to take some load off Enrico and his servers, currently the project still depends heavily on his resources.
Obviously I'm not suggesting that the SourceForge project page is deleted, just switching the main development activity to elsewhere. We could have a git/svn mirror over at SourceForge still, and even keep their bug/feature tracker, though I can't see why, since it's pretty lousy.
It really wouldn't be hard either, the whole "switch" be done in probably 10-15 minutes, maybe 1-2hrs to wait for the history to be imported. There's no real reason it needs to be a big deal either, we could test out another project site and keep it the way it currently is still with not much extra effort, just someone/somescript needs to push to the new project page after
Does your somescript mean that both sites could work for an interim period with the old one being deprecated for later removal?
Cheers Lex
On 04/27/11 21:01, Lex Trotman wrote:
- No need to maintain changelog and authors files
Changelog and authors are still needed for tarballs, but maybe they can be automated?
Seems not too hard with git log and some shell script[1]. I think the original thread also mentions a way (or that it's possible).
- Proper attribution, blame and history for contributors and not having to
put "Thanks" in all the commit messages.
Still needed as above.
There would be no need to use "Thanks" in each commit message, since the author of the commit is the person who wrote the code in it, for example[2] where I just sent Neil a properly formatted patch of my local commit and he applied it directly, keeping the history in tact. If it needed fixing to get added into the main code, this will also be reflected in the history by the next commits to fix it (and I believe the original thread says another way to do this), so no need for "Based on patch by ..." in any commit messages either.
If you were maybe referring to the THANKS file, I would imagine that could be generated automatically as well from the log.
- Built-in Wiki software
That could be useful to take some load off Enrico and his servers, currently the project still depends heavily on his resources.
That was my thought.
Does your somescript mean that both sites could work for an interim period with the old one being deprecated for later removal?
I believe so, yes. I'm no expert on these things, but I guess there must be some way to mirror either the SVN to Git or vice versa by using some hooks or something. Another way probably is using git-svn and dcommit to SVN and then push them to Git. Google turns up this[3], amongst others.
[1] http://live.gnome.org/Git/ChangeLog [2] http://scintilla.hg.sourceforge.net/hgweb/scintilla/scintilla/rev/874b84aa77... [3] http://www.codeography.com/2010/03/17/howto-mirror-git-to-subversion.html
Cheers, Matthew Brush
Hi Matthew,
you couldn't express my feelings better.
On Thu, Apr 28, 2011 at 07:01, Matthew Brush mbrush@codebrainz.ca wrote:
On 04/27/11 21:01, Lex Trotman wrote:
- No need to maintain changelog and authors files
Changelog and authors are still needed for tarballs, but maybe they can be automated?
Seems not too hard with git log and some shell script[1]. I think the original thread also mentions a way (or that it's possible).
http://live.gnome.org/Git/ChangeLog
- Proper attribution, blame and history for contributors and not having
to put "Thanks" in all the commit messages.
Still needed as above.
There would be no need to use "Thanks" in each commit message, since the author of the commit is the person who wrote the code in it, for example[2] where I just sent Neil a properly formatted patch of my local commit and he applied it directly, keeping the history in tact. If it needed fixing to get added into the main code, this will also be reflected in the history by the next commits to fix it (and I believe the original thread says another way to do this), so no need for "Based on patch by ..." in any commit messages either.
Just for completeness, sometimes the patch needs to be modified by the maintainer but in these cases it's better to have 2 commits - one containing the original patch and one with the maintainer's changes (especially when the modification actually screws up the original patch).
If you were maybe referring to the THANKS file, I would imagine that could be generated automatically as well from the log.
From my experience this doesn't work so well because people sometimes
send patches from different email addresses. But the THANKS file update can be done just before making a release and it's not the hardest thing to do.
- Built-in Wiki software
That could be useful to take some load off Enrico and his servers, currently the project still depends heavily on his resources.
That was my thought.
Does your somescript mean that both sites could work for an interim period with the old one being deprecated for later removal?
I believe so, yes. I'm no expert on these things, but I guess there must be some way to mirror either the SVN to Git or vice versa by using some hooks or something. Another way probably is using git-svn and dcommit to SVN and then push them to Git. Google turns up this[3], amongst others.
Geany already updates its official git mirror (http://git.geany.org) from SVN so this works and synchronization between git repositories is a matter of setting up a post-receive hook.
One more idea - even if the core developers don't want the switch, at least the current geany git repository could be set up to push changes to github so people who want to use git have an up-to-date mirror from which they can clone and create their personal branches.
Cheers,
Jiri
On Thu, 28 Apr 2011 23:43:39 +0200, Jiří wrote:
One more idea - even if the core developers don't want the switch, at least the current geany git repository could be set up to push changes to github so people who want to use git have an up-to-date mirror from which they can clone and create their personal branches.
Sure. Does anyone know how to do this? Adding a hook script to "forward" the commits wouldn't be a problem, I just don't know how to do this.
Regards, Enrico
2011/4/30 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 28 Apr 2011 23:43:39 +0200, Jiří wrote:
One more idea - even if the core developers don't want the switch, at least the current geany git repository could be set up to push changes to github so people who want to use git have an up-to-date mirror from which they can clone and create their personal branches.
Sure. Does anyone know how to do this? Adding a hook script to "forward" the commits wouldn't be a problem, I just don't know how to do this.
Regards, Enrico
Sourceforge SVN seems to be limited to just the four hook scripts they provide, and non of them do this :-(
Cheers Lex
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 30 Apr 2011 19:34:51 +1000, Lex wrote:
2011/4/30 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 28 Apr 2011 23:43:39 +0200, Jiří wrote:
One more idea - even if the core developers don't want the switch, at least the current geany git repository could be set up to push changes to github so people who want to use git have an up-to-date mirror from which they can clone and create their personal branches.
Sure. Does anyone know how to do this? Adding a hook script to "forward" the commits wouldn't be a problem, I just don't know how to do this.
Sourceforge SVN seems to be limited to just the four hook scripts they provide, and non of them do this :-(
But we have git.geany.org. The mirror GIT repositories are synced from SVN and the sync is triggered by commit mails.
So, we do have a kind of our own commit hook, from SVN as well as from GIT. I just don't know what I should do in the hook :).
Regards, Enrico
2011/4/30 Enrico Tröger enrico.troeger@uvena.de:
On Sat, 30 Apr 2011 19:34:51 +1000, Lex wrote:
2011/4/30 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 28 Apr 2011 23:43:39 +0200, Jiří wrote:
One more idea - even if the core developers don't want the switch, at least the current geany git repository could be set up to push changes to github so people who want to use git have an up-to-date mirror from which they can clone and create their personal branches.
Sure. Does anyone know how to do this? Adding a hook script to "forward" the commits wouldn't be a problem, I just don't know how to do this.
Sourceforge SVN seems to be limited to just the four hook scripts they provide, and non of them do this :-(
But we have git.geany.org. The mirror GIT repositories are synced from SVN and the sync is triggered by commit mails.
So, we do have a kind of our own commit hook, from SVN as well as from GIT. I just don't know what I should do in the hook :).
Hi Enrico,
in principle you have to put something like
git push --mirror your_github_repository
under .git/hooks/post-receive (in the local geany repository). When creating the github repository, you should create a new public/private key pair and make sure that the keys are available for the user who runs the git command. If you have multiple keys or there are several users, you may use this technique:
http://stackoverflow.com/questions/3496037/how-to-specify-which-ssh-key-to-u...
(Disclaimer: I've never used it myself so I can only hope this works.)
Jiri
On Sun, 1 May 2011 17:53:21 +0200, Jiří wrote:
2011/4/30 Enrico Tröger enrico.troeger@uvena.de:
On Sat, 30 Apr 2011 19:34:51 +1000, Lex wrote:
2011/4/30 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 28 Apr 2011 23:43:39 +0200, Jiří wrote:
One more idea - even if the core developers don't want the switch, at least the current geany git repository could be set up to push changes to github so people who want to use git have an up-to-date mirror from which they can clone and create their personal branches.
Sure. Does anyone know how to do this? Adding a hook script to "forward" the commits wouldn't be a problem, I just don't know how to do this.
Sourceforge SVN seems to be limited to just the four hook scripts they provide, and non of them do this :-(
But we have git.geany.org. The mirror GIT repositories are synced from SVN and the sync is triggered by commit mails.
So, we do have a kind of our own commit hook, from SVN as well as from GIT. I just don't know what I should do in the hook :).
Hi Enrico,
in principle you have to put something like
git push --mirror your_github_repository
under .git/hooks/post-receive (in the local geany repository). When creating the github repository, you should create a new public/private key pair and make sure that the keys are available for the user who runs the git command. If you have multiple keys or there are several users, you may use this technique:
Thanks for the information. However, this sounds like more work than I can effort to do. I just don't want to start with this and then it delays to ever like many other things I started (shame on me, but working on it :D).
If anyone has time to write such a script, I'd be happy to include it as a hook script. Btw, we already have a GIT mirror at repo.or.cz: http://repo.or.cz/w/geany-mirror.git Not sure if that helps anything.
To the general GIT discussion: I don't mind whether we switch or not. It is at least initially a lot of work for the change but that might be worth in the long run, I can't judge this. If Nick, Frank and Colomban want to, then let's go. I won't vote for or against it.
Regards, Enrico
2011/5/8 Enrico Tröger enrico.troeger@uvena.de:
Hi Enrico,
in principle you have to put something like
git push --mirror your_github_repository
under .git/hooks/post-receive (in the local geany repository). When creating the github repository, you should create a new public/private key pair and make sure that the keys are available for the user who runs the git command. If you have multiple keys or there are several users, you may use this technique:
Thanks for the information. However, this sounds like more work than I can effort to do. I just don't want to start with this and then it delays to ever like many other things I started (shame on me, but working on it :D).
I can set up a repository at GitHub, test everything and describe what needs to be done in greater detail. But I'll do it only if the decision is _not_ to switch to git as a primary VCS for Geany in which case this work wouldn't be necessary.
If anyone has time to write such a script, I'd be happy to include it as a hook script. Btw, we already have a GIT mirror at repo.or.cz: http://repo.or.cz/w/geany-mirror.git Not sure if that helps anything.
Oh, I didn't know about it. How do you push commits there? It should be about the same for GitHub as well.
Cheers,
Jiri
On Mon, 9 May 2011 19:44:15 +0200, Jiří wrote:
2011/5/8 Enrico Tröger enrico.troeger@uvena.de:
Hi Enrico,
in principle you have to put something like
git push --mirror your_github_repository
under .git/hooks/post-receive (in the local geany repository). When creating the github repository, you should create a new public/private key pair and make sure that the keys are available for the user who runs the git command. If you have multiple keys or there are several users, you may use this technique:
Thanks for the information. However, this sounds like more work than I can effort to do. I just don't want to start with this and then it delays to ever like many other things I started (shame on me, but working on it :D).
I can set up a repository at GitHub, test everything and describe what needs to be done in greater detail. But I'll do it only if the decision is _not_ to switch to git as a primary VCS for Geany in which case this work wouldn't be necessary.
If anyone has time to write such a script, I'd be happy to include it as a hook script. Btw, we already have a GIT mirror at repo.or.cz: http://repo.or.cz/w/geany-mirror.git Not sure if that helps anything.
Oh, I didn't know about it. How do you push commits there? It should be about the same for GitHub as well.
Don't push at all, repo.or.cz pulls.
Regards, Enrico
Am 30.04.2011 11:52, schrieb Enrico Tröger:
But we have git.geany.org. The mirror GIT repositories are synced from SVN and the sync is triggered by commit mails.
So, we do have a kind of our own commit hook, from SVN as well as from GIT. I just don't know what I should do in the hook :).
Assuming the current git mirror does "git svn rebase" upon the hook, you could extend the script to do the git push afterwards (according to Jiri's [1] command).
You need an intermediate git mirror which does the svn rebase anyway, I don't think github can offer that, but it doesn't necessarily need to be publicly available.
[1]: is it OK if I write your name that way? I don't know how to enter the characters on the keyboard. If not, I'm sorry.
Best regards.
On 04/30/11 02:07, Enrico Tröger wrote:
On Thu, 28 Apr 2011 23:43:39 +0200, Jiří wrote:
One more idea - even if the core developers don't want the switch, at least the current geany git repository could be set up to push changes to github so people who want to use git have an up-to-date mirror from which they can clone and create their personal branches.
Sure. Does anyone know how to do this? Adding a hook script to "forward" the commits wouldn't be a problem, I just don't know how to do this.
I think the more important part is, are the core developers going to accept pull/merge requests on github/gitorious, apply commits/patches from there, etc.? If it's only going to be another read-only git mirror, it's kind of pointless. I don't mean to say that it's a bad idea to have the "official Geany source" available on various projects sites to fork/hack on and stuff, just that it doesn't address the problem being discussed at all.
Cheers, Matthew Brush
Am 30.04.2011 11:48, schrieb Matthew Brush:
I think the more important part is, are the core developers going to accept pull/merge requests on github/gitorious, apply commits/patches from there, etc.? If it's only going to be another read-only git mirror, it's kind of pointless. I don't mean to say that it's a bad idea to have the "official Geany source" available on various projects sites to fork/hack on and stuff, just that it doesn't address the problem being discussed at all.
I agree it's not as useful, but I disagree that it'd be pointless. We can still benefit from the "social coding" aspects of github, including but not limited to an overview over the forks, pull requests between forks. I would greatly love to see that, as I'm subscribed to a number forks by now :)
BTW: is there some possibility to have an svn mirror of a git repo. Perhaps if you have admin access to the bare svn repo?
Best regards.
On Sun, May 1, 2011 at 23:46, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 30.04.2011 11:48, schrieb Matthew Brush:
I think the more important part is, are the core developers going to accept pull/merge requests on github/gitorious, apply commits/patches from there, etc.? If it's only going to be another read-only git mirror, it's kind of pointless. I don't mean to say that it's a bad idea to have the "official Geany source" available on various projects sites to fork/hack on and stuff, just that it doesn't address the problem being discussed at all.
I agree it's not as useful, but I disagree that it'd be pointless. We can still benefit from the "social coding" aspects of github, including but not limited to an overview over the forks, pull requests between forks. I would greatly love to see that, as I'm subscribed to a number forks by now :)
Yes, I would also prefer if there was a proper and complete git switch (it would greatly save maintainer's work IMO) but I haven't seen much enthusiasm from the core developers for the move so it's better if people who use git have at least an up-to-date git mirror from which they can create their private branches.
BTW: is there some possibility to have an svn mirror of a git repo. Perhaps if you have admin access to the bare svn repo?
I guess you could git svn dcommit from the post-receive hook if you have access to the git repository. But I guess it works for simple commits only and not merges and so on.
(To your question regarding writing my name - I write it that way myself too because I'm lazy to switch to Czech keyboard so I guess it's OK ;-)
Jiri
Am 02.05.2011 00:18, schrieb Jiří Techet:
Yes, I would also prefer if there was a proper and complete git switch (it would greatly save maintainer's work IMO) but I haven't seen much enthusiasm from the core developers for the move so it's better if people who use git have at least an up-to-date git mirror from which they can create their private branches.
The core developers don't show very much enthusiasm since a while *in general*. Well, that's not entirely true I admit, Colomban is doing a great job and Nick has been more active recently too. But my general feeling, that the community around is more active these days, remains.
Best regards.
On Mon, May 2, 2011 at 16:33, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 02.05.2011 00:18, schrieb Jiří Techet:
Yes, I would also prefer if there was a proper and complete git switch (it would greatly save maintainer's work IMO) but I haven't seen much enthusiasm from the core developers for the move so it's better if people who use git have at least an up-to-date git mirror from which they can create their private branches.
The core developers don't show very much enthusiasm since a while *in general*. Well, that's not entirely true I admit, Colomban is doing a great job and Nick has been more active recently too. But my general feeling, that the community around is more active these days, remains.
But the question of whether to switch to git or not has to be decided by the very core developers (Enrico, Nick). Without their decision all our discussion is pointless because the switch just won't happen.
So direct question: Enrico, Nick, what's your opinion on the git switch? As Matthew said, it seems that it's possible to access a github repository both via svn and git so both the current workflow and git-based workflow should be possible. Of course I'll try to help with whatever I can during the migration.
Cheers,
Jiri
On 05/02/11 15:43, Jiří Techet wrote:
So direct question: Enrico, Nick, what's your opinion on the git switch? As Matthew said, it seems that it's possible to access a github repository both via svn and git so both the current workflow and git-based workflow should be possible. Of course I'll try to help with whatever I can during the migration.
Don't forget Colomban as well, who, AFAIK, likes/uses mostly Git.
Cheers, Matthew Brush
Le 03/05/2011 00:43, Jiří Techet a écrit :
On Mon, May 2, 2011 at 16:33, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 02.05.2011 00:18, schrieb Jiří Techet:
Yes, I would also prefer if there was a proper and complete git switch (it would greatly save maintainer's work IMO) but I haven't seen much enthusiasm from the core developers for the move so it's better if people who use git have at least an up-to-date git mirror from which they can create their private branches.
The core developers don't show very much enthusiasm since a while *in general*. Well, that's not entirely true I admit, Colomban is doing a great job and Nick has been more active recently too. But my general feeling, that the community around is more active these days, remains.
But the question of whether to switch to git or not has to be decided by the very core developers (Enrico, Nick). Without their decision all our discussion is pointless because the switch just won't happen.
So direct question: Enrico, Nick, what's your opinion on the git switch? As Matthew said, it seems that it's possible to access a github repository both via svn and git so both the current workflow and git-based workflow should be possible. Of course I'll try to help with whatever I can during the migration.
I second the Git switch, so 1/4 (and I guess Frank will second too).
Just note I have no experience using GitHub (or even no real with Gitorious) or working with pull requests and co, but I'd be happy to git it a try -- and probably adopt it.
Cheers, Colomban
On 5/9/2011 9:27 AM, Colomban Wendling wrote:
I second the Git switch, so 1/4 (and I guess Frank will second too).
Just note I have no experience using GitHub (or even no real with Gitorious) or working with pull requests and co, but I'd be happy to git it a try -- and probably adopt it.
Cheers, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
I would also like to see a switch to using git, not that my opinion is worth *that* much :-)
On 05/01/11 14:46, Thomas Martitz wrote:
Am 30.04.2011 11:48, schrieb Matthew Brush:
I think the more important part is, are the core developers going to accept pull/merge requests on github/gitorious, apply commits/patches from there, etc.? If it's only going to be another read-only git mirror, it's kind of pointless. I don't mean to say that it's a bad idea to have the "official Geany source" available on various projects sites to fork/hack on and stuff, just that it doesn't address the problem being discussed at all.
I agree it's not as useful, but I disagree that it'd be pointless. We can still benefit from the "social coding" aspects of github, including but not limited to an overview over the forks, pull requests between forks. I would greatly love to see that, as I'm subscribed to a number forks by now :)
Yeah, pointless was a poor choice of word. What I meant was that it would still require the same workflow to get changes into Geany, the history would still be broken, none of the network/other graphs would really work properly (I think) for the Geany repository, etc.
IMO, the better approach would be to move the main source tree/development to GitHub.com and then the core devs who prefer Subversion could continue to use it on the GitHub.com repository[1][2]. This would at least solve a few more of the issues, and wouldn't require much upfront effort or disruption of the core devs' workflow.
Cheers, Matthew Brush
[1] https://github.com/blog/626-announcing-svn-support [2] https://github.com/blog/644-subversion-write-support
Am 02.05.2011 03:33, schrieb Matthew Brush:
[1] https://github.com/blog/626-announcing-svn-support [2] https://github.com/blog/644-subversion-write-support
Ah, that was what I was asking for in my other mail. However, it seems not very ideal for SVN users.
Best regards.
Le 28/04/2011 23:43, Jiří Techet a écrit :
On Thu, Apr 28, 2011 at 07:01, Matthew Brush mbrush@codebrainz.ca wrote:
On 04/27/11 21:01, Lex Trotman wrote:
- No need to maintain changelog and authors files
Changelog and authors are still needed for tarballs, but maybe they can be automated?
Seems not too hard with git log and some shell script[1]. I think the original thread also mentions a way (or that it's possible).
As said in another message, our ChangeLog isn't a simple "git log" mirror. See the other mail for a few more details.
There would be no need to use "Thanks" in each commit message, since the author of the commit is the person who wrote the code in it, for example[2] where I just sent Neil a properly formatted patch of my local commit and he applied it directly, keeping the history in tact. If it needed fixing to get added into the main code, this will also be reflected in the history by the next commits to fix it (and I believe the original thread says another way to do this), so no need for "Based on patch by ..." in any commit messages either.
Just for completeness, sometimes the patch needs to be modified by the maintainer but in these cases it's better to have 2 commits - one containing the original patch and one with the maintainer's changes (especially when the modification actually screws up the original patch).
I don't like the idea of committing something I don't second, e.g. I patch I have to modify just after. For me the primary goal of a commit is to reflect a particular change, and being able to revert it/cherry-pick it, etc., so it should be a whole, no less and no more.
If I have to commit someone's patch with changes, I would tend to either leave it to him if the modifications are minimal (e.g. a few formatting issues, a missing free(), etc.) or take it to me, adding original author's mention (if the modifications are important).
Cheers, Colomban
Hey,
Sorry for the response delay, but not I answer:
Le 28/04/2011 03:36, Matthew Brush a écrit :
Summary from previous thread: The people in the thread who do not want to switch to Git, or those who don't seem to care either way, are those who have commit access to Subversion on SourceForge. Most (if not all) contributors to Geany are using Git (via git-svn). The workflow for those who don't have commit access on the subversion repository, when contributing to Geany is sub-optimal (to put it politely). SourceForge is painfully slow and the interface for viewing SVN source code online isn't great.
Agreed, mostly on the fact that SF is quite weirdly painful to use in many situations.
I think the reason GitHub/Gitorious is mentioned so much is not only because of the "Git" in their name, but also because it allows people who don't have commit access to actually be active members in the community, by means of having their public forked repositories, sending merge/pull requests, etc.
I don't know GitHub, but it looks great at first glance. The only thing I don't necessarily like is being this much depend of an external host, but it's probably the cost of not maintaining our own whole set of services and servers. And anyway we already have this with SF.
The only thing I think would be awesome and really useful would be to have the GitHub wiki on geany.org (or vice-versa). Since its seems to be an open-source Wiki software using Git, it may be doable; and that'd be awesome.
Cons from the previous thread:
- It's more social
I have some cons against social networks, but there are pros here, so...
- Not plain enough (I guess too Web 2.0/feature-full/cluttered)
I don't personally mind if it's not intrusive.
- Effort required to move the project
That's the big part!
- Having to learn a new VCS for those not familiar with Git
True. Though I think Git is quite handy for the basic features (commit/diff/log/pull/push/merges/branches/cherry-picks), probably less with more advanced ones, but they are less used, aren't they? (though I rebase almost everyday, but still :D)
Pros from the thread: [...]
- Moving the codebase and history is very easy, for example using the
script from the thread or GitHub offers you to import a SVN repository through the web interface when creating a new repository.
That's a great point for GitHub
- Easier to contribute to the project for those without write access
- Faster hosting and better interface.
Seems like I agree.
- Harder to have patches slip through the crack.
- Not having to maintain/create patches as much/at all.
That's not necessarily true, but yes, patches at least have a proper managing system.
- No need to maintain changelog and authors files
That's not true. Our ChangeLog don't contain each and every commit, nor necessarily the whole commit message.
Although I don't personally second such ChangeLog (mostly because we have to maintain it and it's the biggest source of conflicts), I understand the point of Nick and Enrico to keep it, and won't start discussion on this again.
- Proper attribution, blame and history for contributors and not having
to put "Thanks" in all the commit messages.
That's a good point, too.
Not sure if I missed any, or misconstrued them.
Here's some features of better project hosting sites. I'm listing things from GitHub because I know it better than Gitorious and others:
- Great source code viewer, branch/file browser, history/commit viewer.
- Ability to link to and comment on commits and even specific lines of a
commit, for code review, etc.
- Nice network graph viewer to get a better idea of what everyone else
is working on, needs to be commited, etc[2].
- Tracker for pull/merge requests so no need for contributors to
generate/maintain patch(sets) and keep bumping ML threads so their patches don't go forgotten.
- Fork queue to compare other peoples repositories' commits against your
repository to cherry pick specific commits, with an indication of whether or not the commit/patch will likely cleanly apply
- Good issue/bug tracker
- Built-in Wiki software
- Nice graphs to show languages, impact, commit activity, etc
- Web hooks to notify by email/ML, IRC and other services of commits,
etc.[4]
- No need to create nightly tarballs separately since the server takes
care of this automatically when users clicks the Download link.
Yeah, GitHub functionality looks great. I don't think Gitorious offers as much functionality (e.g. no bug tracker).
The one I probably misses the most on SF is automated ticked closing from a commit (e.g. the "closes #foo" stuff).
Hopefully this will stir up a little discussion about actually switching because every time I use SourceForge I die a little inside :) I think switching to one of the Git project hosting sites will really help the community/contributors get involved and feel like part of the team while still making sure the official code is controlled by a great team of core developers.
Obviously I'm not suggesting that the SourceForge project page is deleted, just switching the main development activity to elsewhere. We could have a git/svn mirror over at SourceForge still, and even keep their bug/feature tracker, though I can't see why, since it's pretty lousy.
The difficult part is moving bug tracking I guess. If we end up having 2 bug trackers it'd become quite a pain :/
It really wouldn't be hard either, the whole "switch" be done in probably 10-15 minutes, maybe 1-2hrs to wait for the history to be imported. There's no real reason it needs to be a big deal either, we could test out another project site and keep it the way it currently is still with not much extra effort, just someone/somescript needs to push to the new project page after committing to SVN. Basically all it would take beyond that is for one of the founders/core members to take some time to setup an account and push the code.
Before moving all main commiters should agree (e.g. Nick and Enrico), but I think the creating par would not be the real problem. As discussed further later in thread the problem is more setting up correct hooks to keep all repos up to date.
As a conclusion, I completely second the Git switch, and mostly the GitHub choice. I we all agree on this, we could try this "soon" (don't trust this word).
Cheers, Colomban
On Mon, May 9, 2011 at 16:16, Colomban Wendling lists.ban@herbesfolles.org wrote:
Cons from the previous thread:
- It's more social
I have some cons against social networks, but there are pros here, so...
- Not plain enough (I guess too Web 2.0/feature-full/cluttered)
I don't personally mind if it's not intrusive.
- Effort required to move the project
That's the big part!
Not that bad if you move the repository only to GitHub - see below.
- No need to maintain changelog and authors files
That's not true. Our ChangeLog don't contain each and every commit, nor necessarily the whole commit message.
Although I don't personally second such ChangeLog (mostly because we have to maintain it and it's the biggest source of conflicts), I understand the point of Nick and Enrico to keep it, and won't start discussion on this again.
Could you point me to the discussion? I've missed that one. (I too find a manual-maintained ChangeLog to be too much effort with too little gain.)
Obviously I'm not suggesting that the SourceForge project page is deleted, just switching the main development activity to elsewhere. We could have a git/svn mirror over at SourceForge still, and even keep their bug/feature tracker, though I can't see why, since it's pretty lousy.
The difficult part is moving bug tracking I guess. If we end up having 2 bug trackers it'd become quite a pain :/
I'd say that VCS migration and bug tracking system migration should be done separately and independently. Migration of the bug tracker is a lot of work while migration to git is quite easy. I'd also be rather cautious before moving the bug tracker to GitHub. At the moment they are offering hosting of open source projects for free but there's no guarantee it will be like that in the future as well. This is no problem with the git repository if they get evil - you can always upload the repository somewhere else and update a few links on the geany's home page. However with the bug tracker it would be a much more painful process.
It really wouldn't be hard either, the whole "switch" be done in probably 10-15 minutes, maybe 1-2hrs to wait for the history to be imported. There's no real reason it needs to be a big deal either, we could test out another project site and keep it the way it currently is still with not much extra effort, just someone/somescript needs to push to the new project page after committing to SVN. Basically all it would take beyond that is for one of the founders/core members to take some time to setup an account and push the code.
Before moving all main commiters should agree (e.g. Nick and Enrico),
Enrico doesn't care, you like it, so the one who will have to decide is Nick :-).
but I think the creating par would not be the real problem. As discussed further later in thread the problem is more setting up correct hooks to keep all repos up to date.
But those hooks were meant to be used to have a git mirror on GitHub if there's no VCS switch (mirroring the current git mirror of SVN). I don't see any point in having multiple git mirrors if you switch to git (well, actually everybody's personal clone would be such a mirror).
Cheers,
Jiri
Le 09/05/2011 19:35, Jiří Techet a écrit :
On Mon, May 9, 2011 at 16:16, Colomban Wendling lists.ban@herbesfolles.org wrote:
- Effort required to move the project
That's the big part!
Not that bad if you move the repository only to GitHub - see below.
Right.
- No need to maintain changelog and authors files
That's not true. Our ChangeLog don't contain each and every commit, nor necessarily the whole commit message.
Although I don't personally second such ChangeLog (mostly because we have to maintain it and it's the biggest source of conflicts), I understand the point of Nick and Enrico to keep it, and won't start discussion on this again.
Could you point me to the discussion? I've missed that one. (I too find a manual-maintained ChangeLog to be too much effort with too little gain.)
Hum, seems it actually was about Geany-Plugins ChangeLog... anyway, here's the archive: http://lists.uvena.de/pipermail/geany-devel/2010-November/003401.html
Obviously I'm not suggesting that the SourceForge project page is deleted, just switching the main development activity to elsewhere. We could have a git/svn mirror over at SourceForge still, and even keep their bug/feature tracker, though I can't see why, since it's pretty lousy.
The difficult part is moving bug tracking I guess. If we end up having 2 bug trackers it'd become quite a pain :/
I'd say that VCS migration and bug tracking system migration should be done separately and independently. Migration of the bug tracker is a lot of work while migration to git is quite easy. I'd also be rather cautious before moving the bug tracker to GitHub. At the moment they are offering hosting of open source projects for free but there's no guarantee it will be like that in the future as well. This is no problem with the git repository if they get evil - you can always upload the repository somewhere else and update a few links on the geany's home page. However with the bug tracker it would be a much more painful process.
Well... this makes sense, but having the but tracker on SF and the code on GitHub seems a bit like a suboptimal option -- though since SF don't really link bug tracker and VCS maybe it'd not really change anything.
But the point on the possible future of GitHub is important IMO. if we have no guarantee for the long-term viability -- and when I read you I read "I'd not be really surprised if it happened" --, do we really want to use this? I mean, if we need to switch to another official repo next year because GitHub decided not to continue to provide (free) hosting for us, it'd not be really good.
But yeah, switching to Git doesn't even mean going away from SF (though it couldn't be bad :D), they also offers Git repositories. Just no fancy around like merge requests, reviews & co.
I haven't either checked the other sites (Gitorious, ?) deeper, maybe they are good candidates if we don't want the BT functionality? don't know -- apart that I already have and account on Gitorious and wasn't scared by their policy.
It really wouldn't be hard either, the whole "switch" be done in probably 10-15 minutes, maybe 1-2hrs to wait for the history to be imported. There's no real reason it needs to be a big deal either, we could test out another project site and keep it the way it currently is still with not much extra effort, just someone/somescript needs to push to the new project page after committing to SVN. Basically all it would take beyond that is for one of the founders/core members to take some time to setup an account and push the code.
Before moving all main commiters should agree (e.g. Nick and Enrico),
Enrico doesn't care, you like it, so the one who will have to decide is Nick :-).
Yep ^^
but I think the creating par would not be the real problem. As discussed further later in thread the problem is more setting up correct hooks to keep all repos up to date.
But those hooks were meant to be used to have a git mirror on GitHub if there's no VCS switch (mirroring the current git mirror of SVN). I don't see any point in having multiple git mirrors if you switch to git (well, actually everybody's personal clone would be such a mirror).
I think we shouldn't drop e.g. the git.geany.org mirror if we can keep it, so we'd need a hook in the official repo to push to it or whatever.
Cheers, Colomban
But the point on the possible future of GitHub is important IMO. if we have no guarantee for the long-term viability -- and when I read you I read "I'd not be really surprised if it happened" --, do we really want to use this? I mean, if we need to switch to another official repo next year because GitHub decided not to continue to provide (free) hosting for us, it'd not be really good.
Well, that risk exists for any free hosting service, even Sourceforge could go broke, as Jiri says easy for DVCS, especially if there is an up to date mirror, hard for bugtracker.
But yeah, switching to Git doesn't even mean going away from SF (though it couldn't be bad :D), they also offers Git repositories. Just no fancy around like merge requests, reviews & co.
I didn't think they allowed anyone to create a public clone, I think that is a required feature to get more involvement, anyone can say "I'm going to try this..." and the community can see it and provide guidance and testing.
I haven't either checked the other sites (Gitorious, ?) deeper, maybe they are good candidates if we don't want the BT functionality? don't know -- apart that I already have and account on Gitorious and wasn't scared by their policy.
It really wouldn't be hard either, the whole "switch" be done in probably 10-15 minutes, maybe 1-2hrs to wait for the history to be imported. There's no real reason it needs to be a big deal either, we could test out another project site and keep it the way it currently is still with not much extra effort, just someone/somescript needs to push to the new project page after committing to SVN. Basically all it would take beyond that is for one of the founders/core members to take some time to setup an account and push the code.
Before moving all main commiters should agree (e.g. Nick and Enrico),
Enrico doesn't care, you like it, so the one who will have to decide is Nick :-).
Yep ^^
but I think the creating par would not be the real problem. As discussed further later in thread the problem is more setting up correct hooks to keep all repos up to date.
But those hooks were meant to be used to have a git mirror on GitHub if there's no VCS switch (mirroring the current git mirror of SVN). I don't see any point in having multiple git mirrors if you switch to git (well, actually everybody's personal clone would be such a mirror).
I think we shouldn't drop e.g. the git.geany.org mirror if we can keep it, so we'd need a hook in the official repo to push to it or whatever.
Cheers, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 10/05/2011 00:43, Lex Trotman a écrit :
But the point on the possible future of GitHub is important IMO. if we have no guarantee for the long-term viability -- and when I read you I read "I'd not be really surprised if it happened" --, do we really want to use this? I mean, if we need to switch to another official repo next year because GitHub decided not to continue to provide (free) hosting for us, it'd not be really good.
Well, that risk exists for any free hosting service, even Sourceforge could go broke, as Jiri says easy for DVCS, especially if there is an up to date mirror, hard for bugtracker.
Of course; DVCS are really helpful in this kind of situations (and many others :D). But if we keep the idea "everything can go by", maybe moving BT too to GitHub wouldn't be more of a problem than leaving it on SF (apart the actual move required); and I believe that having the BT integrated with the VCS provides some comfort (even just the auto-close feature).
But yeah, switching to Git doesn't even mean going away from SF (though it couldn't be bad :D), they also offers Git repositories. Just no fancy around like merge requests, reviews & co.
I didn't think they allowed anyone to create a public clone, I think that is a required feature to get more involvement, anyone can say "I'm going to try this..." and the community can see it and provide guidance and testing.
No I don't think they have any fancy around the repo; it'd just make my own life easier by using true Git :D
Cheers, Colomban
On 05/09/11 11:12, Colomban Wendling wrote:
Le 09/05/2011 19:35, Jiří Techet a écrit :
I'd say that VCS migration and bug tracking system migration should be done separately and independently. Migration of the bug tracker is a lot of work while migration to git is quite easy. I'd also be rather cautious before moving the bug tracker to GitHub. At the moment they are offering hosting of open source projects for free but there's no guarantee it will be like that in the future as well. This is no problem with the git repository if they get evil - you can always upload the repository somewhere else and update a few links on the geany's home page. However with the bug tracker it would be a much more painful process.
Well... this makes sense, but having the but tracker on SF and the code on GitHub seems a bit like a suboptimal option -- though since SF don't really link bug tracker and VCS maybe it'd not really change anything.
From what I can tell, the majority of the bugs in the SF tracker are either closed, open but will never get resolved or no longer apply to current versions, so I don't know how much of a big deal it would be to start moving away from it, of course always leaving it (possibly read-only?) for reference.
But the point on the possible future of GitHub is important IMO. if we have no guarantee for the long-term viability -- and when I read you I read "I'd not be really surprised if it happened" --, do we really want to use this? I mean, if we need to switch to another official repo next year because GitHub decided not to continue to provide (free) hosting for us, it'd not be really good.
Speculating on the future of any of the project hosting sites is just that, speculation. They have different business models, like SF with ad revenue, GitHub with private paid accounts, Gitorious with extra services (and probably $ from Nokia), and Google Projects with Google's plan for total world domination.
If I had to make a guess, I'd say it would be more likely for SF to go belly up due to lousy services, mass exodus to better project sites and it not being financially worthwhile for GeekNet.
Put simply, AFAIK, none of these projects sites offer a guarantee that they will not shutdown, go paid only, or otherwise change their services, so I don't think speculation should be a primary factor in deciding on a project site.
But yeah, switching to Git doesn't even mean going away from SF (though it couldn't be bad :D), they also offers Git repositories. Just no fancy around like merge requests, reviews& co.
Still leaves the problems of slow services (though Git would probably be faster), crappy web interface, lack of forking (and others you mentioned) and having public forks attached to the project, crappy bug tracker, etc.
I haven't either checked the other sites (Gitorious, ?) deeper, maybe they are good candidates if we don't want the BT functionality? don't know -- apart that I already have and account on Gitorious and wasn't scared by their policy.
I can't say I'm personally opposed to Gitorious, but to me it just seems like a stripped-down version of GitHub, missing lots of the cool features. Of all the project hosting sites I've used though, the only two I really dislike are SourceForge and Launchpad followed farther by Google Projects.
Cheers, Matthew Brush
Le 10/05/2011 01:34, Matthew Brush a écrit :
On 05/09/11 11:12, Colomban Wendling wrote:
Le 09/05/2011 19:35, Jiří Techet a écrit :
I'd say that VCS migration and bug tracking system migration should be done separately and independently. Migration of the bug tracker is a lot of work while migration to git is quite easy. I'd also be rather cautious before moving the bug tracker to GitHub. At the moment they are offering hosting of open source projects for free but there's no guarantee it will be like that in the future as well. This is no problem with the git repository if they get evil - you can always upload the repository somewhere else and update a few links on the geany's home page. However with the bug tracker it would be a much more painful process.
Well... this makes sense, but having the but tracker on SF and the code on GitHub seems a bit like a suboptimal option -- though since SF don't really link bug tracker and VCS maybe it'd not really change anything.
From what I can tell, the majority of the bugs in the SF tracker are either closed, open but will never get resolved or no longer apply to current versions, so I don't know how much of a big deal it would be to start moving away from it, of course always leaving it (possibly read-only?) for reference.
Maybe, need to check but might not be that painful (BTW, don't GitHub offers a SF BT import feature? :D)
But the point on the possible future of GitHub is important IMO. if we have no guarantee for the long-term viability -- and when I read you I read "I'd not be really surprised if it happened" --, do we really want to use this? I mean, if we need to switch to another official repo next year because GitHub decided not to continue to provide (free) hosting for us, it'd not be really good.
Speculating on the future of any of the project hosting sites is just that, speculation. They have different business models, like SF with ad revenue, GitHub with private paid accounts, Gitorious with extra services (and probably $ from Nokia), and Google Projects with Google's plan for total world domination.
If I had to make a guess, I'd say it would be more likely for SF to go belly up due to lousy services, mass exodus to better project sites and it not being financially worthwhile for GeekNet.
Put simply, AFAIK, none of these projects sites offer a guarantee that they will not shutdown, go paid only, or otherwise change their services, so I don't think speculation should be a primary factor in deciding on a project site.
Agreed as said in another mail, apart that I doubt SF will really die, just maybe become even more crappy by the years.
I haven't either checked the other sites (Gitorious, ?) deeper, maybe they are good candidates if we don't want the BT functionality? don't know -- apart that I already have and account on Gitorious and wasn't scared by their policy.
I can't say I'm personally opposed to Gitorious, but to me it just seems like a stripped-down version of GitHub, missing lots of the cool features. Of all the project hosting sites I've used though, the only two I really dislike are SourceForge and Launchpad followed farther by Google Projects.
Well, again, I have no real opinion on this, apart that yeah, GitHub *seems* (haven't tested it) to have more cool features. I was suggesting something else only because of the speculations about GitHub's future ;)
Anyway, I think we should wait for Nick's opinion, and probably again Enrico and Frank ones about the BT stuff.
Cheers, Colomban
On 05/09/11 17:16, Colomban Wendling wrote:
Maybe, need to check but might not be that painful (BTW, don't GitHub offers a SF BT import feature? :D)
It wouldn't surprise me if it does have such a feature (or script available somewhere). Alternatively, I could probably hack something together in Python using this[1] and this[2].
[1] https://sourceforge.net/export/sf_tracker_export.php?group_id=153444&ati... [2] http://develop.github.com/p/issues.html
Cheers, Matthew Brush
On Mon, May 9, 2011 at 20:12, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 09/05/2011 19:35, Jiří Techet a écrit :
I'd say that VCS migration and bug tracking system migration should be done separately and independently. Migration of the bug tracker is a lot of work while migration to git is quite easy. I'd also be rather cautious before moving the bug tracker to GitHub. At the moment they are offering hosting of open source projects for free but there's no guarantee it will be like that in the future as well. This is no problem with the git repository if they get evil - you can always upload the repository somewhere else and update a few links on the geany's home page. However with the bug tracker it would be a much more painful process.
Well... this makes sense, but having the but tracker on SF and the code on GitHub seems a bit like a suboptimal option -- though since SF don't really link bug tracker and VCS maybe it'd not really change anything.
But the point on the possible future of GitHub is important IMO. if we have no guarantee for the long-term viability -- and when I read you I read "I'd not be really surprised if it happened" --, do we really want to use this? I mean, if we need to switch to another official repo next year because GitHub decided not to continue to provide (free) hosting for us, it'd not be really good.
But yeah, switching to Git doesn't even mean going away from SF (though it couldn't be bad :D), they also offers Git repositories. Just no fancy around like merge requests, reviews & co.
I haven't either checked the other sites (Gitorious, ?) deeper, maybe they are good candidates if we don't want the BT functionality? don't know -- apart that I already have and account on Gitorious and wasn't scared by their policy.
I really have nothing specific against GitHub (actually from what I have seen I like it better than Gitorious) and I have no evidence they are planning to change their policy. What I wanted to say is that the selection of the right VCS hosting site is much less critical decision than hosting of the bug tracker. If you decide to change the git hosting site for some reason, there's no problem - you push your repository there, update a few links and you're done. But this is much harder to do with the bug tracker and it should be double-checked it satisfies all your needs from all possible perspectives.
Bug tracker switch and VCS switch are really two different things. Actually one possibility is to really keep the main git repository under SF and just mirror it to GitHub so people can create their personal branches. Git is a distributed VCS so it doesn't matter where the "master" repository is located.
In fact, there are three different questions:
1. Do we want to switch to git? 2. Where should we have our git repository hosted? 3. Where should we have our bug tracker hosted?
I suggest answering and implementing them one by one.
Cheers,
Jiri
On 05/10/11 14:05, Jiří Techet wrote:
I really have nothing specific against GitHub (actually from what I have seen I like it better than Gitorious) and I have no evidence they are planning to change their policy. What I wanted to say is that the selection of the right VCS hosting site is much less critical decision than hosting of the bug tracker. If you decide to change the git hosting site for some reason, there's no problem - you push your repository there, update a few links and you're done. But this is much harder to do with the bug tracker and it should be double-checked it satisfies all your needs from all possible perspectives.
Agreed, it's a separate concern to some extent, although if Geany sets up shop on GitHub, I don't know why any users would want to suffer through the miserable SourceForge interface/search misfeature/email unreporting when there's a nice working interface on GH. The one thing that could be an issue, and I've yet to confirm this, is whether the GitHub issue tracker requires users to login with a GitHub/OpenID/OAuth account or not (or whether it's optional). I think allowing anonymous bug reports is kind of important, although I'm not sure even SourceForge is allowing this now (I'm always logged in).
Actually one possibility is to really keep the main git repository under SF and just mirror it to GitHub so people can create their personal branches. Git is a distributed VCS so it doesn't matter where the "master" repository is located.
IMO, as I've said before, if it's just read-only Git mirror, it adds very little value, and only solves a small part of the problem. If a GitHub repository gets setup as a read-only repository (and by read-only I mean that none of the core devs actually use it or the features of GitHub), you're gonna end up with a tons of forks and pull requests against the main repository and none of the forks are ever gonna get merged back into the mainline rendering the whole workflow pointless, it will be the same as it currently is. There will be no code reviews, no ownership of the changes, no record of pending change requests, and so on. Instead of uniting the Geany community, I can only see this as fragmenting it and still the same problems with contributing.
In fact, there are three different questions:
- Do we want to switch to git?
- Where should we have our git repository hosted?
- Where should we have our bug tracker hosted?
I suggest answering and implementing them one by one.
I suggest merging the first two questions into one. The third of course needs more careful consideration since it's not as trivial to move the BT around, although as I said in another post, it probably wouldn't be super tough to move the BT reports from SF to GH since SF provides an export interface and GH an import interface.
My $0.02
Cheers, Matthew Brush