geda-developers team mailing list archive
-
geda-developers team
-
Mailing list archive
-
Message #00119
Re: Future (was: [RFC] libgeda data structures and algorithms)
On Mon, Dec 17, 2012 at 01:45:47PM +0000, Peter TB Brett wrote:
> On Monday 17 December 2012 13:45:21 Ivan Stankovic wrote:
> Well, to summarize the important points:
>
> 1) We're pretty close to the point at which we need to decide whether we
> bite the bullet and carry out a major rewrite of gschem, or give up; the
> sort of problems that I'm running up against while trying to develop
> gEDA/gaf further seem to be pretty fundamental.
I think we can all testify to that.
> 2) If we (i.e. the gEDA/gaf dev team) decide on the "rewrite" option,
> then it's only going to happen if we work as a team to *make* it happen,
> without getting disheartened or sidetracked by bikeshedding or negative
> attitude from others. Honestly, do we have the team for it?
I don't know about others, but I am definitely here to help. This is not
doable by one man alone, not in any reasonable amount of time.
Also, if we can agree on this, I'd like to emphasize the part where you
said "disheartened or sidetracked by bikeshedding or negative attitude
from others". It is *critical* that we avoid exactly that. I won't even
bother to count the number of times I gave up on something gEDA-related
just because of it and I'm certainly not alone in this respect. With
that in mind, may I propose that we involve geda-user only minimally,
if at all?
> > Right, and this is why I tried to not go too far from the original
> > libgeda design when I started on libeda, but that has its downsides.
> > In the end, I'm not sure whether it's worth the trouble.
>
> Is it indeed?
It's a tough question to answer, but may not be all that relevant. Purely from
the lines of code standpoint, the task we're talking about is huge, regardless
of the details of implementation.
> Our options seem to be:
>
> 1) Acknowledge that gEDA/gaf is at the "mature" and/or "in decline"
> stage of the product lifecycle and that we don't have the
> manpower/energy for gEDA/gaf "2.0"
>
> 2) Get our heads down and crank out a revamped library, schematic
> editor, netlister, and maybe an updated file format to go with it
>
> So what's the plan, folks?
I'm willing to help with 2, as that is really the only sane option
if we want the project to be relevant.
--
Ivan Stankovic, pokemon@xxxxxxxxxxxxxx
"Protect your digital freedom and privacy, eliminate DRM,
learn more at http://www.defectivebydesign.org/what_is_drm"
References