Github transition discussion

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Github transition discussion

Rich Mattes-2
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
_______________________________________________
Playerstage-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/playerstage-developers
Reply | Threaded
Open this post in threaded view
|

Re: Github transition discussion

Geoffrey Biggs-3
On 03/09/11 05:36, Rich Mattes wrote:
> 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

An important point that has been missed is that if the goal is to get
git, rather than to specifically use github, then we can stay with
SourceForge. They provide a git service as well.

More comments below.

> 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)

I don't see any benefit other than a historical one from tying Player
and Stage together so strongly. Stage should, in my opinion, be
independent of any middleware (as it already is). If anything,
libstageplugin should be split off from Stage and stored with Player.

> * 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)

This is a git thing, not a github thing, although I don't know how well
the SF tracker supports git pull requests. The github interface is
somewhat awesome for them. :)

> * 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)

Github provides static website hosting, but it's very clunky. You have
to make a branch in your repository for it. They do provide an imitation
of dynamism though a parser called Jekyll (which they wrote themselves -
the github folks are prodigious coders). See here:

http://pages.github.com/

>    * Issues/Bugs/Patches: GitHub has an issue tracker, but it's a little
> clunkier than SourceForge's

Funny, I find it easier than SF'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?

Leaving it frozen with a note in a README seems the best approach.

> 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?

 From a developer's point of view, I see benefits in moving to git. From
a project point of view, I'm not sure moving to github is that
advantageous over sticking with SourceForge, since we would need to
maintain both accounts. There are many little things in either
direction, but no clear winner.

Geoff

------------------------------------------------------------------------------
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
_______________________________________________
Playerstage-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/playerstage-developers