geda-developers team mailing list archive

[Vladimir Zhbanov <vzhbanov@xxxxxxxxx>]

On Sat, Sep 19, 2015 at 01:51:51AM +0000, Evan Foss wrote:
...
> Things have been so flamewar heavy lately that I was hoping no one would notice
> 1. that you included me by name in the voting process with the other
> people on geda-developers
> 2. that i really did not belong there
What does the list mean then:
  https://launchpad.net/~geda-developers/+members
I had seen you there before I was invited myself.

...
> gEDA has always assumed everything is a tool.
> * Originally libgeda, gschem, gattrib and etc were all packaged
> separately because it was thought people will want to use our file
> format or some other part of code and might just want that part of the
> tool chain. Our current packaging system was picked specifically so
> that we could transition back to that if we ever choose too. It also
> makes it easier on people who are trying to do a recompile on just one
> of the sub tools.
I don't think so. Gattrib is separate just because the piece of code it
was based on was to difficult to merge into gschem. Libgeda is not
mature enough to absorb all functions it needs and throw out unnecessary
stuff. Some work on this has been made so, for example, we have
libgedacairo now.

> * This was taken so seriously that practically all notions of nets as
> larger constructs than just a series of lines was kept out of libgeda
> and in gnetlist only. The idea being that it was against the projects
> philosophy to blur netlisting into gschem and etc. So gEDA has always
> resisted integration with in itself. This is one of many reasons why
> making back annotation/notation is so complex. We kind of need some
> notion of nets to make gschem provide a meaningful display of the flow
> back from pcb. Doty and I have gone back and forth debating this.
> Please do *not* unstabilize this it is really hard to get to this
> point and I think he might actually help code it when we get to that
> stage. We should probably talk off list about it.
I don't think so, either. Nothing prevents gnetlist to be a module / a
plugin which functions could be invoked within gschem, and
simultaneously have a binary for it which could work separately.

> * I asked Doty as a joke about how it was that gschem is able to
> export images and print schematics. He replied seriously saying it was
> a compromise. Seriously purist.
Gschem menu system allows to keep different goodies in separate menus.
> 
> gEDA puts a lot of effort into making sure everything is pure to it's
> in keeping with this design philosophy. As you might have noticed John
> Doty kind of considers himself to be the keeping of this concern. I
> agree with him most of the time by the way. The code style is very
> consistent.
> 
> PCB integrates things a lot.
> * Look at the exporters if that was done by the geda crowd then it
> would be done via some external pcbexporter that would have flags for
> --gerber, --gcode, --bom, and etc*  * As DJ has said people write code
> and if it is good enough it is included. So a lot of features that the
> geda crowd would have made separate functions were built into pcb.
The gaf utility works almost the same way. It resembles the git command.

...
> >> It is frustrating that they are all ignoring this. I guess we could
> >> import the people we were talking about adding and then put it to
> >> another vote but that feels electioneering or rigging the ballot box.
> >>
> >> I think we should just adopt the plan and move forward.
> >
> > Agreed. That might be a document we could refer to if we had some moot
> > points.
> 
> Include a link at the end as a footnote to the email you suggested this plan in.

Sorry, I thought about a new plan we could work out and refer then.

Thanks,
  Vladimir