Re: [Gnucap-devel] savannah git repositories

[al davis]

Browsing http://git.savannah.gnu.org/

> 1) create seperate projects for each of them

guile does it this way

subproject names are like "guile-something.git"

> 2) register additional repositories within the gnucap
> project, 

many others, including hurd, do it this way.

subproject names are like "hurd/something.git"

On Saturday 13 September 2014, Felix Salfelder wrote:
> i would really like to not mix up different projects. for git
> experts it might only be extra hassle to make it work in a
> usual way. but i prefer accessibility and stick to some
> conventions such as
> 
> $ git clone somewhere/gnucap-whatever
> should create gnucap-whatever, which contains whatever (and
> nothing else).  and
> $ cd gnucap-whatever; git branch -a
> should list branches of whatever, no more no less.
> $ git checkout <branchname>
> doesn't do anything unexpected.

I take it that you are saying most people would checkout only 
the master branch.  Others in the same repository are variants 
of it, not something you would want in addition to.

and that what are now branches you might want in addition to 
should be separate repositories.

and this should apply to subprojects too, and this concept 
provides a fundamental guideline to determine what should have 
its own repository.


> it might make sense to merge abhinavs and rishabs work into
> one repo. maybe together with gnucap-{bm,jack} which have
> similar structure. otoh, none of them is really ready, and
> they need to be worked on individually. this is really a lot
> of work which i will not do anytime soon. gnucap-{geda,adms}
> are seperate packages. there's no way i will mix them up
> with other parts. still i think additional savannah projects
> are the wrong track.
> 
> the proposed gnucap-{bsim,jspice,ngspice,spice} should
> perhaps go into (a single branch of)
> gnucap-plugins-spice.git, if the resepective licenses are
> all sufficiently equal (i haven't checked).
> 
> so how about asking for the repositories
I'm changing "-" to "/".

> gnucap/adms.git
        gnucap port of ADMS model compiler.  ok
> gnucap/bm.git
        collection of "bm" plugins ?
        should it be gnucap/plugins-bm.git ?
> gnucap-geda.git
        geda language plugin 
        should it be gnucap/plugins-geda.git ?
> gnucap/gtk.git
        graphics plugin ..
        I think it should be gnucap/graphics.git instead
        This one starts with Abhinav's work.
        Long term, need to think gtk is not forever.
        It might be Athena, WXwidgets, QT, Motif, .....
> gnucap/jack.git
        Do you mean this jack? http://jackaudio.org/
> gnucap/rishabh.git (better, more descriprive name?)
        I think what is needed here is catchall gnucap/plugins.git
        for a big collection of small stuff
        and a place to start
> gnucap/plugins-spice.git?
        How about gnucap/plugins-models.git ?
        Split up:  gnucap/plugins-models-spice.git,
                        gnucap/plugins-models-verilog.git
        I think just gnucap/plugins-models.git
                which includes both verilog and spice models
                master gets them all
                some other branches are subsets???

A couple more I have hiding ... ibis, and modelgen-verilog.
Neither of them are plugins.

modelgen-verilog is a variant of modelgen that takes verilog 
syntax.  I started it before ADMS came along, then put it aside 
when ADMS came along, now need to bring it back because ADMS 
doesn't do it all.

ibis is a translator.  It generates a gnucap-spice format output 
from an IBIS file input.  Very bit-rotted.  Today, it should 
generate verilog instead, or maybe be a plugin.  It predated 
gnucap plugins.

I still think a middle ground between (2) and (3) is the place 
to be.  Subprojects that will always be, and always be 
subprojects should have their own.  There also needs to be a 
catchall for new ones to get started.