delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2015/12/29/12:05:06

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: <alpine.DEB.2.00.1512290406210.9035@igor2priv>
References: <CAJXU7q_3XwthnN_8mp7B+-ShHeK+=7J=54ZavKBUG3S3bSKp2A AT mail DOT gmail DOT com>
<CANEvwqiM7CKG+WpDRpG4L=HsmSEZ32=CBDyUhuk3ks-SNedL2Q AT mail DOT gmail DOT com>
<43CC8F96-6452-40FA-9DFB-E0983721C19C AT noqsi DOT com>
<alpine DOT DEB DOT 2 DOT 00 DOT 1512290406210 DOT 9035 AT igor2priv>
Date: Tue, 29 Dec 2015 12:04:37 -0500
Message-ID: <CAM2RGhRf1tkKOMHh3a-2e4QHos0+rS6YSAPcLJOFp4Fh4S2f4w@mail.gmail.com>
Subject: Re: [geda-user] Project leadership
From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA users mailing list <geda-user AT delorie DOT com>
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

On Tue, Dec 29, 2015 at 3:29 AM,  <gedau AT igor2 DOT repo DOT hu> 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] <geda-user AT delorie DOT com> wrote:
>>

<snip>

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

<snip>

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019