Re: git repo proposal

Hi Al.

On Sun, May 26, 2013 at 02:35:35AM -0400, al davis wrote:
> Thanks ...  this is now the official repository.

> When doing a commit, even in a WIP branch, change the string in 
> "patchlev.h" to indicate that.  For the "master", the "RCS"  
> minor number should be incremented with every commit.  The major 
> number should be incremented and minor number reset when a 
> stable release is made.  This is the convention I have used 
> since the first RCS checkin.

the WIP branches are intended to stage work in progress that is not even
final. i use this tag to indicate, that
a) i am working on it
b) i am waiting for comments/acceptance or merge requests
c) i might rebase/nuke the whole thing at any time
its definitely overkill to tamper with patchlev.h in WIP branches, but i
agree that patchlev should be increased during merge into master. how
about a more automatic approach?

> For WIP branches, add to that string what branch it is.

before i merge a branch into master i'll definitely remove the -WIP
suffix (no more editing possible). how about fetching the branchname
into patchlev.h via configure (unless its "master")?

> I wonder, looking forward, what will happen when there are 
> hundreds of WIP branches, in various states.

its up to you, to give feedback and/or ask for merge. the following
might happen once you agree with the autotools-WIP patch series:
- autotools-WIP will be renamed to autotools
- autotools will be merged into master
- optional (if the case is closed) autotools will be deleted
all branches (but master,release) are intended to be removed finally,
not deleting them is just possible, not mandatory.

> Now that we have the mechanism, I have a few myself ....  multi-
> processor support, a modelgen branch with Verilog syntax.

better don't use the -WIP suffix for these branches, as probably none of
your commits will have to await review/acceptance.

> Also, we need to include the plugin tarballs, and set up a way 
> for anyone to have a space for their work on plugins.

the plugin tarballs (are you talking about gnucap-bsim, gnucap-spice
etc?) are _packages_, also, they are licensed differently from gnucap.
it's pretty much better to NOT include them into the gnucap repo. how
about including them into the dist-tarball (optionally, of course)?

to be more verbose:
./configure; make dist # create standalone dist tarball (as before)
./configure --enable-externals; make dist # create dist tarball
                                            including extra stuff.

here, externals could be a fixed list, or just the set of directories
within an "externals" directory. what do you think?

regards
felix