Re: [Gnucap-devel] savannah git repositories

[Felix Salfelder]

On Sat, Sep 13, 2014 at 10:45:52PM -0400, al davis wrote:
> [..]
> subproject names are like "guile-something.git"

indeed. the guile subprojects however have clearly distinct
memberlists. maybe access control is an issue on here? i do not see how
this is necessary for gnucap. or i just do not like it very much. i
understand that you don't prefer this option either, so lets discard it
for now.

> [..]
> subproject names are like "hurd/something.git"

this looks useful.

> 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.

yes. in fact i have never encountered a multiple-project
single-repository before in the wild. i considered what happened so far
as a workaround. also, i somehow expected that the extra branches were
intended to be merged into master finally (and i now learned that this
is probably wrong).

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

yes. a repository is a logical unit of code that belongs together in
some sense. usually 'some sense' means that it corresponds to a package
with the same name as the repository.

(imo) the least surprising way do do things is either
- put things into the "main" (gnucap) repository if it is meant to end
  up in the gnucap tarball
- put it into a different repo if it is not, like in one of the other
  tarballs [1].

> I'm changing "-" to "/".

that's what hurd does. maybe it's not too bad.

> > gnucap/adms.git
>       gnucap port of ADMS model compiler.  ok
> > gnucap/bm.git
>       collection of "bm" plugins ?
>       should it be gnucap/plugins-bm.git ?
plugins-bm.git is fine. eventually, a subdirectory in plugins.git might
fit. but not yet.

> > gnucap-geda.git
>       geda language plugin 
>       should it be gnucap/plugins-geda.git ?
ok.

> > 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, .....
agreed. how about "gui"?

> > gnucap/jack.git
>       Do you mean this jack? http://jackaudio.org/
yes. plugins-jackaudio.git maybe?

> > 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
yes, lets put these (as subdirectories) into (a branch of)
gnucap/plugins.git and merge when they are ready/useful.

> > gnucap/plugins-spice.git?
>       How about gnucap/plugins-models.git ?
>       Split up:  gnucap/plugins-models-spice.git,
>                       gnucap/plugins-models-verilog.git
this sounds reasonable. the four parts of plugins-models-spice look
related. there are no models-verilog that i know of.

>       I think just gnucap/plugins-models.git
>               which includes both verilog and spice models
>               master gets them all
>               some other branches are subsets???

i would not mix *-verilog with *-spice. branches are there to
develop topics, not to seperate packages. but ymmv.

> 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'd start off with seperate repos. a merge is an easy thing to do. how
about simply gnucap/ibis.git and gnucap/modelgen-verilog.git? there's
already plain modelgen which is part of the main tree. many options
evolve here. decide later ...

> 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.

gnucap/plugins.git could serve as a catchall for plugins. most things
are plugins, so this might work. lets rethink after it has stopped
working :)

cheers
felix

[1] http://www.gnucap.org/devel/