X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Tue, 29 Dec 2015 04:29:06 +0100 (CET) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] Project leadership In-Reply-To: <43CC8F96-6452-40FA-9DFB-E0983721C19C@noqsi.com> Message-ID: References: <43CC8F96-6452-40FA-9DFB-E0983721C19C AT noqsi DOT com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 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: > > Currently, badly needed development rarely occurs because those >people who are capable do not contribute because they are put off >by a few users who want NOTHING to change because it does not >fit their personal work flow. > > >There are really two projects here: The original gEDA (now confusingly >called geda-gaf), and pcb. I think everyone agrees that pcb needs a lot of >work. On the other hand, geda-gaf is matiure, effective, and easy to extend I know this will not be productive or encouraging, but... For a long time I was hacking PCB's source and did not check geda-gaf sources. You led me believe geda-gaf sources are much better organized, and the code much better designed than PCBs. When I worked on back annotation, I finally had to add some code in gschem and libgeda. It was a big dissapointment. PCB code has its own shortcomings too, but gschem is far from being perfect either. If you ask me, _both_ need a lot of work. >with scripting. Pcb development requires a great deal of collaboration. >Geda-gaf development mostly does not, as anybody can write and publish a >script. 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. As you don't code PCB and you don't even use it, I don't think you are in a good position in comparing them like that. You can, of course, just noone should take your words seriously. >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. 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. 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. 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.