X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Wed, 16 Apr 2014 21:17:42 -0400
Message-Id: <201404170117.s3H1HgR6027052@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <20140417010616.26473.qmail@stuge.se> (message from Peter Stuge
	on Thu, 17 Apr 2014 03:06:16 +0200)
Subject: Re: [geda-user] Freerouting finally free (GPL3)
References: <1395878918 DOT 2126 DOT 7 DOT camel AT AMD64X2 DOT fritz DOT box> <53477BD5 DOT 3070001 AT xs4all DOT nl> <1397238146 DOT 861 DOT 11 DOT camel AT AMD64X2 DOT fritz DOT box> <201404111621 DOT 02147 DOT ad252 AT freeelectron DOT net> <534BED69 DOT 4050703 AT estechnical DOT co DOT uk> <534C1B44 DOT 20401 AT xs4all DOT nl> <20140417000357 DOT 21967 DOT qmail AT stuge DOT se> <201404170012 DOT s3H0C0SU021800 AT envy DOT delorie DOT com> <20140417010616 DOT 26473 DOT qmail AT stuge DOT se>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> wanted to clarify that requesting write access to the main repo is
> absolutely not a neccessity for doing pcb development.

Sure, but saying "you don't have to ask for write access" is different
than promoting a "don't use in the main repo" strategy.

> Funny you should write that. :) It is in fact impossible NOT to make
> a copy of a git repository if you want to actually work with it.

I know how git works.  I have to use it daily.  I still hate it.

> > It would be much easier to find all gEDA-related
> > development, for example, if it happened in the gEDA repository.
> 
> A DVCS such as git allows powerful workflows where development is
> very conveniently structured.

I have to use git a lot, and I hate it, because it makes it very
difficult for me to do my daily job.  Please use the word "powerful"
more carefully ;-)

> Especially a project such as integrating freerouter into pcb would
> do well living in its own branch somewhere,

I see no reason why this is the case, nor have you offered any such
reason.  If more than one person is working on a project, there needs
to be coordination and centralization *somehow* else they're really
working on separate projects.

> It's a good thing to publish ongoing work as early as possible, it
> translates to a more efficient development effort, but on the other
> hand, early work doesn't neccessarily belong in the primary project
> repository, even if it has a branch of its own.

This does not follow.  We have plenty of temporary branches in the
main git repo.

> Publishing the commits on one hand solicits review, but at the same
> time it is also already enough for project maintainers to include the
> proposed commits into the project - and trivially so using git fetch,
> cherry-pick and am, if the commits are published using git's own
> tools.

Please use the word "trivially" more carefully.  Another sore spot
between me and git.

> Of course you are right that it's nice to make ongoing work easily
> available, but the point with a DVCS is that it does not dictate
> *how* that happens, and using the primary repo is only one of several
> useful ways.

Of course.  I just don't want to have people think they *can't* use
the repo because so many people are promoting "just fork a clone and
publish it elsewhere!".  It sends the wrong message.  We want people
to join the project, not be sent away from it.