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