X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VoYzolrk0KFMUJ4Amfme2zfhMSSQDiaQtYEdtX6WRME=; b=RQyJ3pPRt8zNE46yfvifb1rU1PZbvqtTwY3Kv3Y2pnaB6SRBZqCmiWu8EsHr0aGzVn d1o34s40dYWz87lQtd4RcFnSu6PJuNRMrULXfLRwBPrsOG/6l6mUTn0T/Z8B8xFGHP9Q ox/XnUvdD4pWMqgGDKv7+iJFdF11IY1O/W9uXvA/Ruf3gXEIW+LvykULZA1jj7+vMLmr p15hAY2Ny9s7uNIXKG0CsFhjvTqb0/Xz4aAsekPFFzGVXjUb8dP5BTLVk9I8JcMrsSd9 u8hbqH8rR44o0vNk6wdBPlwbVarMZNISbUPdlsPLeW2ZUvxm5+pY6j+My8RPDARS9Ocm m/fA== MIME-Version: 1.0 X-Received: by 10.180.109.231 with SMTP id hv7mr23206114wib.7.1440359458139; Sun, 23 Aug 2015 12:50:58 -0700 (PDT) In-Reply-To: References: <55D8D8B8 DOT 7050907 AT jump-ing DOT de> <55D9BDC7 DOT 4000608 AT jump-ing DOT de> Date: Sun, 23 Aug 2015 11:50:57 -0800 Message-ID: Subject: Re: [geda-user] Antifork From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: text/plain; charset=UTF-8 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 Sun, Aug 23, 2015 at 9:42 AM, wrote: > > > On Sun, 23 Aug 2015, Evan Foss (evanfoss AT gmail DOT com) [via > geda-user AT delorie DOT com] wrote: > >>> >>> >>> What exactly does make you think that? >> >> >> Igor2 the only alternative (which I am no opposed to) is that we drop >> the current mainline and use pcb-rnd going forward. > > > I still don't see why we need to drop either of them. Do we drop pcb and go > for kicad? Or do we drop kicad and go for pcb? Or rather both pcb and kicad > exist and will go on existing... > > We have a mainline with all the opengl support which seems to be very > popular, and pcb-rnd with scripting. You can even combine them: do your > design in pcb and load it in pcb-rnd when you want to run interactive > scripts on it. > > It's like that use case reported some weeks ago: use the gtk HID for most > edits and use the lesstif HID for whatever feature that works better there. > > >>>> >>>> With this attitude it's clearly subject to bit rotting. If OpenGL >>>> doesn't >>>> work well it needs fixing, not abandoning. >> >> >> That is what worries me. > > > I really can't do more than offer commit rights in the repo so you can get > it to work. If everyone needs it but noone does it, it just won't happen. Unfortunately no one is going to be nearly so well positioned to merge your stuff as you are. Relatively, it will be painfully inefficient for them and they will feel it as they work. Regarding number of users, I think your experience shows more how much people are deterred by even slightly eccentric find/download/install procedures, rather than user count or interest. No regular pcb user is going to be uninterested in the prospect of multi-language scripting. But you're right that most people will never try it if it's on a fork. Forks are only one thing which make gEDA forbidding. The fact that the instructions are scattered everywhere is probably the single most debilitating problem. Additional forks with separate docs make this problem worse, however. I use gEDA daily for years and I have to admit that as of this instant I don't know the official repo URL. Of course I could go find out again, but I also don't even know which web page to go to to do that. With successful projects there's a single point from which you start, and relatively uniformity down to the information you want. Of course this is not a big issue... in theory. In practice its just its enough of a pain that people don't bother. Regarding autotools vs. scons, so far as I'm concerned the whole project could just switch, but Peter is right and it would be hugely worthwhile to support the most common parts of the autoconf interface (--prefix is 90% of it really :). And is there some way to make it tell you when it gets an unknown option? But really, the point is to agree on a build system, so this peripheral issue doesn't block collaboration. Regarding svn vs. git, might something like this work for you: https://help.github.com/articles/support-for-subversion-clients/ Regarding OpenGL, would it be bad to go back to having it enabled by default and you can just use --disable-opengl in your build? :) The reason everyone is so worked up about this particular fork is that it has the most interesting new features in a long time. I'll take another run at testing it soon. But I agree with others that to give up on merging it is very sad, especially when the problems are things like VCS and build system, that don't even have anything to do with the core functionality. Britton