X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] Antifork
To:	geda-user AT delorie DOT com
References:	<55D8D8B8 DOT 7050907 AT jump-ing DOT de>
	<20150822230549 DOT 3750 DOT qmail AT stuge DOT se> <55D9A5AE DOT 9090604 AT jump-ing DOT de>
	<201508231647 DOT t7NGlAQ8029777 AT envy DOT delorie DOT com>
From:	"Dan McMahill (dan AT mcmahill DOT net) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID:	<55DA8038.70603@mcmahill.net>
Date:	Sun, 23 Aug 2015 22:23:52 -0400
User-Agent:	Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.2.0
MIME-Version:	1.0
In-Reply-To:	<201508231647.t7NGlAQ8029777@envy.delorie.com>
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;
	s=q20140121; t=1440383040;
	bh=AYkONQBowQiWA8mD3D7aVyiINcX+n26/5JubKy3+cBg=;
	h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version:
	Content-Type;
	b=sKe7LcSJb7zg3D+lBwOemJM7Mj7Z5ZRS4JuBo7rs8my6OTN2+KYXjzkWI1bMcEkA4
	xwOnE2zuv+AUnkmWC4DJCuA5wi/o2/SEWq5Z0F4J0Ebaw0bVCxEw6nxXP46qCuuqc8
	n4LW/iCeB08pztnplgyT+bxnypgQPCgpmT2cBr+MrN83zAHirGmtO7hEoFKLEevEGN
	zr0b8D53gBVonwuC7jMRymY+22ej25Qnqs9GtraGWTDB21a1e1P+uQBJ/p06+61QXJ
	ZHDTAPCbiQOxHl29wEv4iweLfRFZvEN53vTWMe7YHapPu24fM5/ijYJbHSk78rwDQQ
	KicOAOKLCvLuw==
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

On 8/23/2015 12:47 PM, DJ Delorie wrote:
>> Forks are the wrong way.
>
> I disagree.  Forks are a solution to a local problem, and the GPL
> allows and encourages forks.
>
> What we need to do is come up with a better way to merge forks back
> into the trunk when those forks offer some benefit to us.
>

DJ and some others know this already but PCB has sort of been here (in 
the state of different versions) before.  A long long time ago when PCB 
was Xaw only and the internal resolution was 1mil there wasn't a public 
repository and there were many different patches floating around.  I 
gathered everything onto sourceforge to try and push towards progress in 
one central location instead of there being lots of different patches 
against different versions and a fractured development.

I feel pretty good that we got a lot of mileage out of that 
consolidation and also from the main git repository after migrating away 
from cvs+sourceforge (although I can't take credit for any of the git 
stuff as other life things were taking more and more of my time and I 
was behind the VCS times).  In those years we've seen a port to GTK, a 
refactoring into HID which gave us both GTK as well as Motif GUI's and 
an easier path towards backends.  There has been massive improvement in 
file format documentation, addition of several standard footprint 
families and bug fixes in others, a plugin system, polygon slicer, trace 
optimizer, higher internal resolution which was sorely needed for more 
modern packages, more bug fixes than I can count, etc. over that time.

Looking back at news items on the web site, there have been 20 releases 
in the last 12 years and more commits than I'm going to try and add up. 
  Considering the size of the developer pool and the pool of active code 
contributors that isn't bad.

Sometimes a fork is the right answer, but in a smaller (defined by 
active developers) project it would seem to me that pooling resources 
needs to be a high priority if everyone wants it to really have a chance 
at progressing.   Of course this is easy for me to say as one who has 
not had time to contribute in several years or use the tool in even more 
years.

Perhaps this thread should be called "Antifork 2.0"?

-Dan

- Raw text -