Re: [Gnucap-devel] savannah git repositories

[Felix Salfelder]

On Mon, Sep 15, 2014 at 01:17:48PM -0400, al davis wrote:
> It's hard to know up front what will eventually be merged into 
> master.

agreed.

> gnucap/adms
>       Never. [..]
yes.

> gnucap/gui
>       At this point it needs to be separate because of the 
> dependency on a specific graphics library.
that's not valid reason. libreadline is optional as well. but the
separation still makes sense, as the development/shipment is independent
of gnucap.

> gnucap/plugins-models
>       This changes faster than master and always will.  It may 
> make sense to separate spice (the past) from verilog (the 
> future).
i think it does. the spice models integrate very specific 3rd party
code. it should be totally optional and not mixed up with different
approaches.

> Almost all new work in modeling is done in verilog-ams.
i'm curious whether a verilog-ams model will replace the gnucap-bsim
package anytime soon. (but i'm looking forward to that.)

> gnucap/bm
>       I think this is a dead-end.
currently, the ELEMENT+BM architecture is extremely versatile and handy.
i'm waiting for other modelling stuff making this obsolete. sometimes i
cannot wait ...

> gnucap/modelgen-verilog
>       I think this will eventually replace the old modelgen, 
> maybe even ADMS.
this is likely to replace adms.

> gnucap/plugins.git
>       The catchall for new stuff, mostly small.  This one could 
> be an exception to the usual master, but maybe not.  How about 
> ... non-master branches are specific, not forks of master but 
> rather forks of nothing.   Then master is a merge of all of 
> them.  There could be several master-like branches, something 
> like "stable", "testing" and "unstable".

i don't like forks of nothing (and what happens if somebody does not
know how to create a new empty branch). but in the end i care less, as
long as additions to plugins are meant to end up as plugins.

and while we're at it: plugins sometimes require changes to
gnucap/master. currently everybody needs to put together his own gnucap
from various README files in order to play with plugins worked on by
someone else. this is bad. an "unstable" branch would be a good place
for stuff like WAVE copy constructors ... (if you agree, please rename
"fixup" to "unstable").

cheers
felix