discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Repos


From: Dr. H. Nikolaus Schaller
Subject: Re: Repos
Date: Sat, 21 Dec 2013 11:05:49 +0100

Am 21.12.2013 um 10:53 schrieb David Chisnall:

> On 20 Dec 2013, at 16:11, Markus Hitter <mah@jump-ing.de> wrote:
> 
>> Am 20.12.2013 16:05, schrieb David Chisnall:
>>> - svn or git views of the repo, so developers can use either
>> 
>> That's possible with pure SVN repos, too. git-svn will check out a SVN
>> repo just fine and you can work with it as if it were a Git repo.
> 
> If you want to use git-svn yourself, yes.  However, you then lose all of the 
> integration with things like GitHub, where forking the repo is a one-click 
> operation.  This is a big difference, because one of the attractive things 
> about something like GitHub is that you get the distributed nature of git 
> WITHOUT the large number of forks hidden on people's laptops.  Anything 
> forked on GitHub is publicly visible (unless you pay GitHub money for it to 
> be private).  You can then do a private clone and not share things, but the 
> easiest way of working is to have everything public, which eliminates the 
> biggest downside of git (i.e. interesting work ends up on dead laptops 
> without backups).
> 
> Additionally, the GitHub svn stuff correctly handles branches and so on, so 
> people who want to have an svn workflow get to use svn as if there were not 
> git involved, people who want to have a git workflow get to use git as if 
> there were no svn involved.  
> 
> For patches, not being able to attack them is annoying, but you can still 
> post diffs inline.  That's fine for small patches, for larger ones it's 
> generally more convenient to have them in small chunks, and having them 
> broken up into smaller commits, and the GitHub workflow works very well for 
> this as you can attach multiple revisions to a bug report / pull request.  
> The nicest thing to do is branch your fork, rebase the branch on upstream, 
> and then send the resulting commits as the pull request.
> 
> Of course, for GNUstep the biggest blocker is requiring copyright 
> assignment...

Could that be addressed like in Linux? Where a "signed-off: email" message is 
treated as a permission for that specific patch.

Hm. I start to wonder why is the copyright assignment needed at all to get code 
into GNUstep?

Let's assume I write some code and publish it under GPL. Then, everybody can 
take it and modify it etc. under the GPL conditions. This includes merging with 
other GPL code.

Why can't a FSF project integrate a GPLed piece of code into a GPL project 
without asking the author for a written permission? By publishing it under GPL 
I assume that I already have given the permission.

Of course there can (and should) be an agreement to get write permission to the 
GNU hosted repository, i.e. the FSF endorsed "official" project version. But is 
it needed to create patches? IMHO no. Only for a maintainer B to integrate the 
patches written by developer A into the official repo.

So only the maintainer(s) who have write permission need such an assignment. 
All others only need to convince a person with such a permission that their 
patch should be integrated.

If that non-existent blocker is the biggest one, it follows logically that all 
other blockers are also non-existing :)

Or am I wrong?

-- hns

PS: please update the Subject if you change the topic!




reply via email to

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