SourceForge has lost a lot of face in the open-source community in the last few years, from hijacking migrated projects to placing ads and grayware/malware in installers.
It has reached to the point where the local university has blocked SourceForge-hosted installers on their network. Some browser extensions also block SourceForge installers due to their recent actions.
Personally, I wonder why we still use them. If at all possible, I'd prefer to dissociate with SourceForge due to the shenanigans they have pulled.
As a test, I migrated one of my personal projects from SourceForge to GitHub. GitHub has an import tool that allows for easy import of a codebase. It wasn't perfect; the issues (tickets) did not import, but I only had one issue in the project and migrated it manually. Other than that, the commits and releases/tags worked fine.
Should there be a good way to get those tickets exported to another code hosting platform, I would recommend migrating to a different host. I think other options include GitLab, Bitbucket, Launchpad, GNU Savannah, Gna!, CloudForge, as well as the aforementioned GitHub.
Some investigation would need to be done to see which (if any) of these would meet the needs of the project, but I feel its something worth looking into.
Migrating from SourceForge
Moderator: Board moderators
-
SilverNexus
- Junior member
- Posts: 165
- Joined: Mon Jun 25, 2012 5:33 pm
- Location: Planet Earth
Migrating from SourceForge
That SilverNexus guy? You needn't worry about him.
He is level negative 4 in oratory, and his singing is worse.
He is level negative 4 in oratory, and his singing is worse.
When sourceforge was first chosen, it didn't have any of the issues you describe. Of course that was many years ago. And any replacement chosen may have similar issues years down the road.
Likely the main reason a migration hasn't been done fall into these reasons:
1) sourceforge fundamentally works. For what crossfire is doing, the SVN access, tickets, mailing lists, etc, all work. If sourceforge had lots of outages or those things did not work, there might be more a push to move.
2) As you note, the migration involves some amount of work, though it sounds like github makes it easy, but if the tickets don't migrate, it could be a bit of work to migrate those manually. If a migration is going to be done, it would seem to be an all or nothing - not sure what would be gained by migrating svn but leaving tickets/mailing lists behind.
3) Given crossfire is a public project, lots of notifications are needed. Anyone with svn checkouts would need to know the new location. Users who file bugs would need to know where to file those, people would have to update mailing information, etc.
Note that the above doesn't necessarily mean that a move shouldn't happen. That is just answering the question of why it hasn't happened yet. Inertia (laziness) is a powerful force.
It is also easy for something that would seem fairly simple to also grow in scope. If the hosting location is going to move, would it make sense to switch to something other than SVN for source control? Would it make sense to change how ticket tracking is done, etc.
I think a plan would be needed, which covers what would and would not be done. I also suspect the mailing lists are better places to discuss this, as I'm not sure how many people who would be affect read the forums.
Likely the main reason a migration hasn't been done fall into these reasons:
1) sourceforge fundamentally works. For what crossfire is doing, the SVN access, tickets, mailing lists, etc, all work. If sourceforge had lots of outages or those things did not work, there might be more a push to move.
2) As you note, the migration involves some amount of work, though it sounds like github makes it easy, but if the tickets don't migrate, it could be a bit of work to migrate those manually. If a migration is going to be done, it would seem to be an all or nothing - not sure what would be gained by migrating svn but leaving tickets/mailing lists behind.
3) Given crossfire is a public project, lots of notifications are needed. Anyone with svn checkouts would need to know the new location. Users who file bugs would need to know where to file those, people would have to update mailing information, etc.
Note that the above doesn't necessarily mean that a move shouldn't happen. That is just answering the question of why it hasn't happened yet. Inertia (laziness) is a powerful force.
It is also easy for something that would seem fairly simple to also grow in scope. If the hosting location is going to move, would it make sense to switch to something other than SVN for source control? Would it make sense to change how ticket tracking is done, etc.
I think a plan would be needed, which covers what would and would not be done. I also suspect the mailing lists are better places to discuss this, as I'm not sure how many people who would be affect read the forums.