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