Mail Archives: geda-user/2015/12/22/11:20:54
Last year, I felt that EdaCore was a great idea - but it was a little
too nebulous (and probably too widely scoped). I guess what I'm
proposing also sounds pretty nebulous at the moment too - since I've
deliberately tried to resist the strong temptation to start designing
it before sitting down with people. FWIW, my working title is
"OpenEDA".
I have spent some time talking with Javier at CERN (who has driven
their backing of Open-source EDA), and I believe he has correctly
assessed that there just isn't enough developer time being put into
open-source EDA for us all to do optimally well as a fragmented
separated set of tools. My takeaway from Javier, was that he thought
all those interested in open-source EDA should collaborate on one
project - (e.g. KiCAD, perhaps something new), and drive that to be
successful.
I take the pragmatic opinion that competition in a space is good, can
foster friendly rivalry and help encourage development via "keeping
up" with each-other. I also see no way that the developers of either
project (and this was counting roughly 0 people in the gEDA camp at
this time last year) would choose to abandon their project and go work
on the other.
Perhaps it has come time for both projects to have a big shake up and
re-write (which could be done collectively as one new project) - but
I'm sceptical we could even agree what that ought to look like (let
alone whether it should be C or C++, or whether either EMACS or VI
users should be banned from contributing on grounds of religious
hatred). In short - both projects take different approaches, and
probably can't (shouldn't) be forced together.
All this said - fundamentally, the design inputs, and PCB outputs
(focusing on that case for now), are more similar than they are
different... and we _could _ be sharing more.
So - what to do.. options:
1) Remain as separate projects, where gEDA guys (I've seen it) grumble
about KiCAD, and how unfair it is that CERN supported them. (Not
cool).
2) Abandon one or both projects to die, as a bit-rotting legacy (this
seemed to be the gEDA strategy last year - in the absence of any
developer time, or perceived set of goals).
3) Start something new
4) Try to foster a collaboration, reduce duplication of effort where
possible - and work together on solving some of the harder technical
challenges.
(e.g. Aside from possible licensing issues - the push+shove
auto-router CERN developed inside KiCAD was designed so it could be
used in gEDA too if we wanted).
I favour option 4, and would like to see both projects contribute to a
design of underlying code which could effectively form an abstracted
core of a potentially new EDA system. This core would support a
flexible data-model, _possibly_ (but not by any means necessarily),
have a native file-format, and would (I think), be designed to
implement native file loader/saver's on top of.
Slowly - both (and other) projects could port to using this new core,
and should unit-test to ensure no functionality is broken in the
process.
Voila - a quality controlled, 2nd generation core package which
consists of the re-write gEDA probably needs by now (and KiCAD might -
if they didn't already do it).
Both packages can build on top of it, keeping their existing UI
paradigms as they wish - yet with FAR greater internal compatibility.
An alternative - both projects continue to be completely
code-separate, but collaborate in design discussions to choose similar
internal representation decisions (where possible / applicable), such
that translators are easier to produce.
Enough for this email.. another coming up on a slightly different topic...
Peter
On 22 December 2015 at 15:41, <gedau AT igor2 DOT repo DOT hu> wrote:
>
>
> On Tue, 22 Dec 2015, Peter Clifton (petercjclifton AT googlemail DOT com) [via
> geda-user AT delorie DOT com] wrote:
>
> <snip>
>
>> If we want to achieve a common data-model, we must arrange to meet, sit
>> with, and effectively develop our own open EDA standard, which all
>> involved
>> projects would make a commitment to further and implement.
>
>
> I fully agree with your conclusion (although I am not fully convinced in the
> "different programs should have different format/model and we should have
> converters" vs. "one common format for all" question). If I remember
> correctly, this conclusion has been reached after last year's FOSDEM too
> (but http://edacore.org seems to be down).
>
>>
>> Step one is reaching out to the other projects. Don't expect to design
>> something and then expect others to adopt it after the fact.
>
>
> I think this was the idea last year too.
>
> So the quesiton is, if this didn't happen since last year, or edacore didn't
> make remarkable progress in this (did it?), then what should be done
> differently this time?
>
> I like your idea about central coordination of such project, but do we have
> enough manpower for that? I mean if you make a committee of people who do
> not code but tell every project what to code, I don't think it would work.
> Rather a group who develop patches for all projects, and this is where the
> lack of manpower worries me.
>
> Regards,
>
> Igor2
- Raw text -