X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) Subject: Re: [geda-user] The state of gEDA/gaf (Was gEDA/PCBs diversity, Was: Pin hole size) From: John Doty In-Reply-To: <20121028185659.GA16006@alpha2> Date: Sun, 28 Oct 2012 17:09:55 -0600 Message-Id: <04438B14-A0ED-4F92-A101-5824420C24C1@noqsi.com> References: <6BF2E986-51EB-41E9-A4AD-8071CD00B1A1 AT jump-ing DOT de> <834283D4-0891-486E-A981-2FF20B32C615 AT noqsi DOT com> <54CAA7EE-7638-4B89-8197-111D0493F859 AT noqsi DOT com> <508CE947 DOT 4050408 AT xs4all DOT nl> <508D302D DOT 1030105 AT jump-ing DOT de> <20121028164801 DOT GA4859 AT alpha2> <5FF7010F-BB82-41F2-8EBC-608E91E045F1 AT noqsi DOT com> <20121028185659 DOT GA16006 AT alpha2> To: geda-user AT delorie DOT com X-Mailer: Apple Mail (2.1085) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id q9SNA4W4014978 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 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