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