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:	<alpine.DEB.2.00.1508231935040.6924@igor2priv>
References:	<55D8D8B8 DOT 7050907 AT jump-ing DOT de>
	<CAM2RGhSZ1vi_DFKqZdZYxhto4ZaXLLscBt5m5kk+PH2ZoYW_vw AT mail DOT gmail DOT com>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1508230609370 DOT 6924 AT igor2priv>
	<55D9BDC7 DOT 4000608 AT jump-ing DOT de>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1508231450350 DOT 6924 AT igor2priv>
	<CAM2RGhSC6UfCr8ixF5iuffmUhcdgVuz9nA+YjiZNk8-f7Q5r-A AT mail DOT gmail DOT com>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1508231935040 DOT 6924 AT igor2priv>
Date:	Sun, 23 Aug 2015 11:50:57 -0800
Message-ID:	<CAC4O8c8PyLQNgxz1SP-98ZhyH5KPDmnNpiULVvdL+TMo-DhN4w@mail.gmail.com>
Subject:	Re: [geda-user] Antifork
From:	"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT 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

On Sun, Aug 23, 2015 at 9:42 AM,  <gedau AT igor2 DOT repo DOT hu> 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

- Raw text -