X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <20140417025146.1321.qmail@stuge.se>
Date: Thu, 17 Apr 2014 04:51:46 +0200
From: Peter Stuge <peter AT stuge DOT se>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] Freerouting finally free (GPL3)
Mail-Followup-To: geda-user AT delorie DOT com
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> <201404170117 DOT s3H1HgR6027052 AT envy DOT delorie DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201404170117.s3H1HgR6027052@envy.delorie.com>
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

DJ Delorie wrote:
> > 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.

Not so different to me.


> 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 ;-)

I would love to learn about how it is difficult for you. I'll chat
you up on IRC some day.


> > 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.

The reason is that it's a neat work package which is likely nicely
isolated from most other concurrent work.

It's a great example of a feature branch, and maintaining it in a
branch somewhere outside of the primary repo allows more freedom in
the development.

It becomes unneccessary to constantly synchronize with whatever else
is going on, and development of the new feature can include wild
experiments across the codebase which aren't neccessarily desirable
in the primary repo just because they are part of the process for
creating the new feature.

And once the feature work has moved along further git makes it easy
to rework (rebase) the branch so that it's ready to be proposed for
inclusion into master, or maybe just moving into the primary repo.


> If more than one person is working on a project, there needs
> to be coordination and centralization *somehow*

Of course, just not neccessarily in the primary project repo. I think
it's very nice if the primary repo doesn't see the craziest parts of
new feature development.


> > early work doesn't neccessarily belong in the primary project repository
> 
> This does not follow.  We have plenty of temporary branches in the
> main git repo.

I'm not saying that it's always wrong. I'm saying it's not always right.
Sometimes it is right, sometimes wrong. When? That's up to developer
judgement.


> > 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.

I hope you'll tell me more, maybe I can help in some way.


> > 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.

Using a DVCS means that the project is greater than the primary repo.

Publishing pcb work outside the primary repo is just publishing
elsewhere, but it's still work within the project.

Personally I'm fond of the approach to have individual repositories
for active developers, hosted next to the primary repo. github does
sortof that, the (maybe only? I prefer self-hosting) nice thing about
github is that it's easy to see relationships between repos.


//Peter