gEDA-dev: libgeda library version & stable branch

Steve Meier smeier at alchemyresearch.com
Sat Jun 2 11:30:56 EDT 2007


"That is the stupidest idea I've heard since I started hacking on gEDA.  Go clean 
your mouth out with soap."




Peter TB Brett wrote:
> 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
>
>   
> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> geda-dev mailing list
> geda-dev at moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
>   



More information about the geda-dev mailing list