Github transition discussion

"Rich Mattes" <[email protected]>
Newsgroups gmane.science.robotics.playerstage
Message-ID <001501cc69b0$05e9a2e0$11bce8a0$@com>
Hi all,

A thread came up over on the -users list concerning a possible transition of
the Player source to GitHub.  I think this is a discussion worth having, so
I'd like to identify some of the pros, cons, and possible ways forward for
such a transition

Pros:
* The Player and Stage source once again reside at the same place
  * These could be consolidated into the same group - GitHub supports
"organizations" of people; we could set up
github.com/ThePlayerProject/player and github.com/ThePlayerProject/Stage,
and more easily manage developer membership and commit access.  We can also
create www and papers repositories (and gazebo, but it looks like they've
already set up shop at ROS's kforge site)
* Easier collaboration: The GitHub fork/pull request model is much less
clunky than the current svn/patch submission model we're using (though
nothing is stopping anyone from going the git/patch submission route if they
don't want to deal with pull requests)
* git-svn can conserve the complete history of the Player codebase should we
go to github, including all of the release tags and branches. 

Cons:
* Fragmentation with existing SourceForge services
  * MediaWiki instance: Would need to stay on SourceForge or moved to a new
hosting provider
  * HTML websites: can be hosted on GitHub, but would require a rework of
links/hostname forwarding (there's also the question of whether or not we
need our html site: the wiki + generated documentation might be fine)
  * Issues/Bugs/Patches: GitHub has an issue tracker, but it's a little
clunkier than SourceForge's
    * Some googling shows that SourceForge issues may be able to be migrated
to GitHub's issue tracker.
  * Mailing Lists: Like MediaWiki, would need to stay on sourceforge or move
to a new hosting provider.  Staying with the sourceforge lists is best for
obvious reasons.
* What to do with current SVN repo.  Is it better to leave them out there in
their current state once everything has been copied out?  Should we turn
them off in SourceForge?  Leave them frozen in their current state, but move
all of the code to a subfolder and have the root directory contain a README
with the new location of the source?

So it looks like the main issues to resolve should we move will be things
like the project's webhosting situation (for MediaWiki, as well as the rest
of the site.)  For now it's probably better to leave everything on
SourceForge, with the exception of maybe keeping the latest doxygen manuals
in the github hosted page like Stage is doing now.  The other thing to
consider is whether or not we should consolidate both Player and Stage under
a new organization, or just put Player under the organization and leave
Stage as it is.  Any thoughts?

Rich 


------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.