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