X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on fly.srk.fer.hr
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=6.3 tests=ALL_TRUSTED
	autolearn=disabled version=3.3.1
Date: Sun, 28 Oct 2012 19:56:59 +0100
From: Ivan Stankovic <pokemon AT fly DOT srk DOT fer DOT hr>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] The state of gEDA/gaf (Was gEDA/PCBs diversity, Was:
 Pin hole size)
Message-ID: <20121028185659.GA16006@alpha2>
References: <6BF2E986-51EB-41E9-A4AD-8071CD00B1A1 AT jump-ing DOT de>
 <834283D4-0891-486E-A981-2FF20B32C615 AT noqsi DOT com>
 <C3C35AF4-24D1-4977-9134-2C0B13473D01 AT jump-ing DOT de>
 <54CAA7EE-7638-4B89-8197-111D0493F859 AT noqsi DOT com>
 <D59D8F6D-0436-4A8D-AFC0-5124BD3031D6 AT jump-ing DOT de>
 <508CE947 DOT 4050408 AT xs4all DOT nl>
 <508D302D DOT 1030105 AT jump-ing DOT de>
 <D04117DE-615E-412A-833E-4ED0F1B9A620 AT noqsi DOT com>
 <20121028164801 DOT GA4859 AT alpha2>
 <5FF7010F-BB82-41F2-8EBC-608E91E045F1 AT noqsi DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5FF7010F-BB82-41F2-8EBC-608E91E045F1@noqsi.com>
X-Operating-System: GNU/Linux
User-Agent: Mutt/1.5.21 (2010-09-15)
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, Oct 28, 2012 at 11:21:58AM -0600, John Doty wrote:
> On Oct 28, 2012, at 10:48 AM, Ivan Stankovic wrote:
> 
> > Sarcasm aside, John, I've always appreciated your position and statements about
> > the power and flexibility of gEDA over the years, but I think the above is a
> > bit too much.  Could you please choose a friendlier wording and specify
> > what concrete plans are you worried about and why?
> 
> Well, of course, I didn't know to worry specifically that somebody would
> change the default attribute promotion strategy until I'd been burned by it.

That was discussed on the list and one could have well imagined the consequences.
Surely any such changes (if such changes are needed at all) will be discussed
at length before being implemented.

So, what plans do you worry about and why?

> There are really two things here: gEDA and pcb. They have separate source
> trees and separate development histories. They have been independent
> projects: pcb is the older. As I have said for years, including pcb in the
> gEDA project has been a major mistake. 

Why? Certainly I haven't noticed anything bad...

> These are both worthy projects, but
> neither should be dependent on the other. 

Agreed and I don't think they depend on each other.

> They deserve a clean interface, but
> they should not be influencing each other's development.

Hmm... why?  If something in gschem would require a pcb plugin (or the other
way around), why would it be a good thing to prevent two groups of developers
from collaborating?

> One consequence of this unfortunate marriage is that this mailing list is
> dominated not by gEDA issues, but by pcb issues. That demonstrates that gEDA
> is a mature product, while pcb is not.

Sorry, I fail to see the implication.  I could suggest any number of reasons as
to why pcb themes dominate the list.  For example, most people here are
concerned with making PCBs and in their workflows schematic capture might be
optional, but layout is essential.  Also, most people would rather suffer bugs
during schematic capture than layout because bugs in the latter can often be
harder to find and more expensive to fix.  Some of the problem may be due to
the fact that pcb is a smaller project, with (arguably) a more clearly defined
vision and an implementation that is not as hard to approach.  I've also seen a
drop in the number of useful gEDA discussions since Peter B and Peter C left
the scene (I do hope they intend to get back!). Etc.

IMHO, you'd need some serious effort to prove that gEDA is a mature product,
while pcb is not.

> I suggest that those who propose a change to gEDA consider whether the change
> would be beneficial if pcb did not exist. If not, then the change is probably
> not a good idea. 

Once again, you're speaking too broadly. What do you mean by "gEDA"?
Because, the above does not make sense until you start talking about the file
format, libgeda, gschem, gnetlist, architecture, OBJECTs, TOPLEVELs etc.

I'll be more concrete and say that e.g. changing fundamental objects and
interfaces in libgeda only to accomodate pcb-specific workflow is probably
something that should be rethought. We should strive to design as generic
mechanisms as possible, and then use those mechanisms to implement
tool-specific workflows.

-- 
Ivan Stankovic, pokemon AT fly DOT srk DOT fer DOT hr

"Protect your digital freedom and privacy, eliminate DRM, 
learn more at http://www.defectivebydesign.org/what_is_drm"