[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!
- Re: Opinion polls UIKit and Website..., (continued)
- Re: Opinion polls UIKit and Website..., Markus Hitter, 2013/12/20
- Re: Repositories, Dr. H. Nikolaus Schaller, 2013/12/20
- Re: Repositories, Markus Hitter, 2013/12/20
- Re: Repositories, Gregory Casamento, 2013/12/20
- Re: Repositories, Gregory Casamento, 2013/12/20
- Re: Repositories, Markus Hitter, 2013/12/20
- Re: Repositories, Gregory Casamento, 2013/12/20
- Re: Opinion polls UIKit and Website..., David Chisnall, 2013/12/21
- Re: Repos,
Dr. H. Nikolaus Schaller <=
- Re: Repos, David Chisnall, 2013/12/21
- Re: Repos, Dr. H. Nikolaus Schaller, 2013/12/21
- Re: Repos, Ivan Vučica, 2013/12/21
- Re: Opinion polls UIKit and Website..., Markus Hitter, 2013/12/21
- Re: Opinion polls UIKit and Website..., Ivan Vučica, 2013/12/21
- Re: Opinion polls UIKit and Website..., Derek Fawcus, 2013/12/21
- Re: Opinion polls UIKit and Website..., Riccardo Canalicchio, 2013/12/21
- Re: Opinion polls UIKit and Website..., Riccardo Mottola, 2013/12/20
- Re: Opinion polls UIKit and Website..., Sergei Golovin, 2013/12/20