[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is a move to github in order??

From: Dr. H. Nikolaus Schaller
Subject: Re: Is a move to github in order??
Date: Wed, 14 May 2014 10:13:39 +0200

Am 13.05.2014 um 17:17 schrieb Riccardo Mottola:

> Hi,
> Gregory Casamento wrote:
>> Hey guys,
>> With the recent move of Etoile to github I've been thinking about a similar 
>> move for gnustep.
>> There are a number of reasons for this:
>> 0)
>> ​It is possible to check out and commit to a github repository using SVN and 
>> HG.  This is #0 since it will be a primary objection to such a move.​
>> 1) GitHub is a very well known platform
>> 2) it would allow code review of patches to be done more easily
>> 3) we could host both the wiki and the website on GitHub.
>> 4) GitHub users could easily fork our repository, reuse and contribute back 
>> more easily (we would of course still need FSF papers)
>> Please give me your thoughts on this. I think it's a good idea for the 
>> technical reasons I've given above.
> My first argument is ideological: I'd rather stay, as long as possible, on a 
> free code forgesite, in free as really free, what more than FSF? Free the 
> platform as the software it runs on. GitHub is commercial, even if free for 
> open-source projects. Actually, I have advocated since quite some time to 
> move GNUstep's sources.

IMHO the most flexible approach that solves everything is:

Have a git.gnustep.org with a GitWeb daemon and people with commit access get 
ssh access. All others can (read only) clone by http: or git:

And a cron script does a "git mirror" to github (for backup and broad 

> Do we have problems with our current website and wiki?
> about 4) I am unsure, sure it eases fork, but the merge back? After all we 
> want to be sure that contributions are clean both technically as in copyright 
> and assignment.

Linux is running very well with a completely different approach. Anyone can 
propose git-format-patch on the mailing list and only people with maintainer 
status can merge them.
Still there exist thousands of "experimental" forks, but it is the 
responsibility of the author to prepare it in a clean way to be accepted in the 
official kernel.org repository.
So there is a gate-keeper.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]