X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Mon, 24 Aug 2015 04:29:35 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] Antifork
In-Reply-To: <CAC4O8c8PyLQNgxz1SP-98ZhyH5KPDmnNpiULVvdL+TMo-DhN4w@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1508240407100.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> <CAC4O8c8PyLQNgxz1SP-98ZhyH5KPDmnNpiULVvdL+TMo-DhN4w AT mail DOT gmail DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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, 23 Aug 2015, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:

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

Unfortunately no one is as unmotivated to invest time in this as I am. 
This won't happen, sorry.

Also, I don't see the merge as a unavoidable necessity.

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

Yup, this is what I learned too. I still hope some sort of Linux/x86_64 
binary pack "that just runs" could help.

<snip>

> Regarding svn vs. git, might something like this work for you:
> https://help.github.com/articles/support-for-subversion-clients/

Thanks, but my concerns are far beyond the UI.

>
> 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? :)

Well, in my own fork I'd like to determine the defaults to my own taste, 
so it'd be --enable-opengl. Fortunately this question is irrelevant as 
long as the opengl code is not compiled at all.

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

I didn't give up on the merge: I never intended to push it in the first 
place. It's totally indifferent for me as I am not an user of the 
mainline pcb. If anyone decides to merge whichever part he likes, that's 
fine. If he has questions about why/how some parts are implemented, I'm 
happy to explain.

Forks may have different purposes. Some forks are created by the author in 
hope that he can merge it back to mainline, some are not.

Regards,

Igor2