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 _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
