[Freedombox-discuss] Need some help on UI - was: What Do You want to use the FreedomBox for?

[Mark Lawrence]

Hello list,

Long-timer lurker, first-time post.

On Mon Jul 09, 2012 at 12:54:01AM -0500, Nick M. Daly wrote:
> On Tue, 3 Jul 2012 18:28:03 +0200, Mathieu Jourdan wrote:
> > >     https://github.com/NickDaly/plinth
> >
> > By fork, do you suggest to create one more account then a third Plinth
> > repository on github? Isn't it preferable to push to existing
> > repositories, avoiding confusion to new contributors? By confusion, I
> > mean it's not easy to get a clear picture on what has been done if one
> > has to browse multiple repositories for the same piece of software.
> 
> That's how distributed revision control systems work: each copy of a
> repository is its own repository.  By making forking technically
> required, it becomes a social, not technological, issue.  Projects as a
> whole move forward when multiple forks are rolled up into a parent
> branch.  Child branches that don't amount to anything are ignored, along
> with parent branches that don't accept changes.

That's not how all Distributed Version Control Systems (DVCS from here
on) _have_ to work, that's just is how github chose to implement their
model of a DVCS for "social coding" purposes. Github threw away the
single-hub-and-spokes model and replaced it with multiple-
hubs-and-spokes. In order to publish even the tiniest single-line patch
to a repository, users are required to fork the *entire* project. I
agree with Mathieu that this leads to confusion: "where is the primary
source for this project??"

I have also forked projects and then forgotten to set up the remote
back to the original repo and then wondered why "pull" wasn't getting
external updates.

They could have chosen instead to keep the idea of a single
synchronisation repository with multiple branches (named
"fork/username/*" perhaps?) and used fine-grained permissions[1] to
allow anyone to create a new branch under the "fork/username"
namespace, and only those who the project decides could commit above
that. The issue tracking system could also be smart and attach issues
to commits (which would allow for per-branch issues that migrate
easily)

If this were the model then the difference between a "code fork" and a
"project fork" would be much more obvious than they are on Github.
Unfortunately it seems Gitorious went down the same path. Just because
DVCS allows some things to be distributed doesn't mean they all should
be, but that's the model followed so far.  Sorry for pushing this
thread further off-topic and not having anything more constructive to
add.

[1] See http://sitaramc.github.com/gitolite/master-toc.html for how
fine-grained permissions can be done.

Mark.
-- 
Mark Lawrence
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20120710/99fa555c/attachment.pgp>