gEDA-dev: libgeda library version & stable branch

Peter TB Brett peter at peter-b.co.uk
Sat Jun 2 11:26:47 EDT 2007


On Saturday 02 June 2007 14:16:31 Steve Meier wrote:
> I would like a development branch that is willing to do more then take
> "baby steps" my vote is yes.

Just to clarify, that wasn't what I was suggesting.  The pace of development 
*has* picked up recently (almost entirely Ivan's commendable effort) but I 
still think that including catastrophically colossal changes like yours in 
any way *not* slow, cautious and very carefully staged would not only 
alienate users, but developers as well.  I speak only for myself, as one of 
said users and developers.

The stable branch I am proposing would be just that -- *stable* -- 
and "normal" gEDA development would continue in the unstable branch just as 
it has for the last 9-and-a-bit years.

Ales is still in charge of gEDA development.  If you don't like that, the 
nature of Free software means that you're more than welcome to do what you 
like with the code, including forking *and* distributing your fork.  This 
isn't necessarily a bad thing: ECGS was forked from GCC by a bunch of people 
who thought GCC development wasn't going anywhere.

This is not to say that I think your changes aren't without merit -- I'm sure 
they are -- and it is entirely possible that the changes or some subset 
thereof can be incorporated into upstream gEDA without too many regressions 
or aggravated developers.  However, until I see (1) source code more than 
context-less snippets in e-mails, (2) detailed documentation of (a) the 
specific changes and (b) how they make things better and (3) some sort of 
proposed schedule for merging cleanly, I'll maintain a healthy scepticism.

However, I really, really want the ideas you've had to be incorporated into 
the design of "libgeda3" & the associated frontends, although I know that the 
process has slipped by the wayside in the last couple of months.  Part of 
what Peter Clifton and I were trying to achieve was to design a set of 
datastructures that would allow gEDA to do what it already does -- schematic 
capture to netlist & BOM -- better, faster, more flexibly and more 
maintainably.  Although your response to these design efforts has mostly 
been, "But I've already done this, use mine!" it seems to me that you've only 
addressed one or possibly two of those aims.

Regards,

Peter

-- 
Fisher Society                              http://tinyurl.com/o39w2
CU Small-Bore Club                          http://tinyurl.com/mwrc9

      09f911029d74e35bd84156c5635688c0            peter-b.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.seul.org/pipermail/geda-dev/attachments/20070602/711de7d0/attachment.pgp 


More information about the geda-dev mailing list