Mail Archives: geda-user/2012/10/28/19:10:08
On Oct 28, 2012, at 12:56 PM, Ivan Stankovic wrote:
>>
>> 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.
I don't recall that discussion. Maybe I lost it in all the noise generated by pcb problems. In any case, I'm hardly smart enough to foresee all consequences of every change.
>> 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...
Pcb issues dominate this mailing list, which *ought* to be about gEDA. It's impossible to rationally discuss what's good for gEDA here.
>
>> 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 shouldn't, but that requires keeping them separate, with a clean interface.
>
>> 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?
gEDA's application space is enormous. Changes to gEDA should serve that space. Pcb's special needs should be the pcb developers' responsibility.
>
>> 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.
Well, it's pretty obvious to me. In any case, all the pcb noise is detrimental to discussions of gEDA. Some of the discussions remind me of this famous illustration: http://www.saulsteinbergfoundation.org/gallery_24_viewofworld.html
gEDA supports much more than pcb.
>
>> 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.
>
The two projects have completely separate source trees and versioning. By gEDA I mean the contents of the "gEDA/gaf" tree. By pcb, I mean the contents of the "PCB" tree.
> 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.
Yes!
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -