gEDA-dev: Subject of gEDA steady developement process

[Paul Tan]

Happy New Year to All,

I fully agree and support the idea of steady gEDA/gaf
developement, as outlined by 2 previous messages from
Ales.

gEDA/gaf has come a long way to be powerful, generic
and flexible EDA system, enabled by this steady
developement process.

Idea->proposal->proof_of_concept->approval_process

(IMHO) makes gEDA/gaf powerful and uninhibiting.

Best Regards,
Paul Tan

;################################################
; Previous messages
;################################################
;To: gEDA user mailing list <geda-user at xxxxxxxxxxxxxx>
;Subject: Re: gEDA-user: Fwd: Parts DB API: the story so far
;From: Ales Hvezda <ahvezda at xxxxxxxxxxxxxx>
;Date: Tue, 01 Jan 2008 01:38:36 -0500

[snip]
> I am completely, utterly, and deadly opposed to a database, except as
> an optional plug-in -- i.e. a separate facility which the remainder of
> gEDA can run without.
[snip]

Agreed.

I'm more than willing to entertain code change proposals (no stealth
checkins of this magnitude without comments from the core developers and
my approval) that allow gEDA/gaf to use a database, but it has to be 
100%
optional and _not_ turned on by default.

-Ales
;=========================================================
;To: gEDA developer mailing list <geda-dev at xxxxxxxxxxxxxx>
;Subject: Re: gEDA-dev: Required versions of Guile & GTK+ (again)
;From: Ales Hvezda <ahvezda at xxxxxxxxxxxxxx>
;Date: Tue, 01 Jan 2008 01:51:45 -0500

[snip]
> I've found Guile features called Fluids and Dynamic Contexts.  These 
will
> allow me to put a real flexible, dynamically extensible configuration
> mechanism into gEDA that works much more cleanly than the current one 
does.

Whoa.  I'm not going to allow such a change (or any other significant
changes that might break end users) unless the changes are written up 
in a
comprehendable specification and a few of the core developers provide 
some
comments on the written proposal.  And by comprehendable specification I
mean liberal use of bulleted lists, pictures (where they makes sense),
and no dense paragraphs of text (that nobody has time to grasp; like
this one :-).

Also, silence or lack of feedback is *not* a blank check or approval for
major changes.  If the above proposal requirement slow development down
a bit, that is okay since 1) gEDA users have really really really long
upgrade cycles anyways and 2) the changes will be of higher quality and
fit better into the overall gEDA/gaf philosophy.

Anyways, if any new config mechanism comes into existence, the new
config mechanism has to coexist with the old mechanism for a while.
The old mechanism can be deprecated (then removed) at some later point,
but not until a good chunk of the user base moves forward.

I'm not going to comment on changing the guile or gtk+ minimal
requirements just yet as I haven't made up my mind yet.  However, I have
heard the request (btw, making the same request over again doesn't help
the cause).

-Ales

;################################################
; End of Previous messages
;################################################

________________________________________________________________________
More new features than ever.  Check out the new AIM(R) Mail ! - 
http://webmail.aim.com