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]" 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> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 Precedence: bulk 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