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=Tje8K5Tz253d341E/DKVTPp9GZ5lNRJOph4cyekoSFk=; b=z9T7czlt7mD1D+/YOms0+6+uCuJGEtZa8x0d0AIwaFXmc41/ops0GKo35zVzSEUEU1 IWiayoeqtxuJADnpqpkC1FnlTAD/zUpCDAuGm4iON+ilpdC0Ov3oDH+fnjbYp5hccwvr 8jY3ljgOIpyXXgAOftkaol9jbR2KLg4PRkl2mlAU0bUNWuSApfAsHwi3aDp3P9Sr60X/ NQ69pMcYWh9kn3z9373YItmnVUlUQ4de3Q5s94cL4/kFMIZeE4T36wXTH3qztNlb/Qnw z1JRva0QKXtSS+2KorzbCVoQb1VqPTWriSe2zi0hwa3BNX3jJmGeNesOm5YI+tkIe/Oc RCKA== MIME-Version: 1.0 X-Received: by 10.25.157.195 with SMTP id g186mr20986107lfe.147.1451408677641; Tue, 29 Dec 2015 09:04:37 -0800 (PST) In-Reply-To: References: <43CC8F96-6452-40FA-9DFB-E0983721C19C AT noqsi DOT com> Date: Tue, 29 Dec 2015 12:04:37 -0500 Message-ID: Subject: Re: [geda-user] Project leadership From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" To: gEDA users mailing list Content-Type: text/plain; charset=UTF-8 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 Tue, Dec 29, 2015 at 3:29 AM, wrote: > > > On Mon, 28 Dec 2015, John Doty wrote: > >> >> On Dec 28, 2015, at 11:53 AM, Marvin Dickens (mpdickens AT gmail DOT com) [via >> geda-user AT delorie DOT com] wrote: >> >> with scripting. Pcb development requires a great deal of collaboration. >> Geda-gaf development mostly does not, as anybody can write and publish a >> script. No changes more involved than a script just trigger a massive backlash. > False. I am coding/maintaining pcb-rnd alone and it does work - in the sense > that I do get the features and bugfixes I wanted to have. When I did the > back annotation's gschem part, things went much slower. If i had to pick, > I'd say pcb is easier to hack alone than gschem. +1 >> There would be much less controversy if these projects were separated. >> They >> represent radically different development patterns: conflating them causes >> much confusion and strife. > > > As an user of _both_ gschem and pcb, as a programmer who has alreay hacked > both code, I beg to differ. The projects are separate enough. PCB needs better integration into the toolchain. Your work on back annotation was a good proof what that could be if people accepted it. Likewise PCB needs it's own equivalent to gnetlist. John Doty and others did a good job making gnetlist export a lot of formats but PCB only accepts one. I had another engineer from another lab try to send me a schematic + netlist. He wanted me to do a PCB layout while he was out. As it was not done in gEDA that was kind of a pain to work out. gEDA has libgeda and a lot of other tools grow around that. To me PCB needs a core library that other tools can grow off of to allow for more integration. > Admitting that a very common (if not the most common) flow is gschem->pcb is > not a bad thing. Even if you will write at least 20 mails a month about that > your flow does not include PCB. > > Having some scripts and tools for this flow is not any worse than having > tools an scripts for other flows. +10^2 > Having a common mailing list or homepage or other infrastructure is not > harmful either. Anyone can use gschem without pcb and can use pcb without > gschem. It's only you who try to change PCB-related traffic into "don't > change gschem" threads. Other than this it's usually pretty clear when we > are talking about gschem or pcb. > > About how perfect gschem is... > > My personal opinion, especially after actually hacking the code for back > annotation, is that there are design errors in the very core of gschem. A > few smallish things that makes life harder in probably most flows, makes > essential UI features impossible to implement. They are historical decisions > and are embedded so deep that it's unlikely they'd ever change. > I don't want to go into details, because this mail already can cause 30 > megabytes of flamewar. +10^6 > The well-praised sch format: it's uncomfortable to use with a text editor. > It's 1000x better than a binary format (or a hex dump), and I do have my ow > set of awk/sed scripts, and it's easy to parse by programs (but that's true > for tons of other formats too). But if i have to change the footprint of R1 > from 1206 to 0805 with a text editor, it's just a PITA. I'm not an xml > fanboy and I really don't like the overhead of JSON or the magic -- == ''' > marks of wiki/yaml... But really, any of these would have been more > text-editor-friendly. This is a question of personal preference, but just > that you repeat twice a weak that the sch format is perfect and is better > than anything else doesn't change this. I don't mind the sch format that much. The PCB format cause me to go in with a text editor more often than I want to admit. Having a set of tools instead of a single monolithic one is good. Having a better user experience where those tools integrate into a more cohesive workflow is better. Doing both of those things while having transparent interfaces between tools and well documented formats was what I thought we were here to do! I am tired. -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/ -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1 stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86 APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ 3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0 SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8 A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk 5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/ xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2 Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8 0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24 CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3 EY347EidAw== =Ta4p -----END PGP PUBLIC KEY BLOCK-----