[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] git repo proposal
From: |
Felix Salfelder |
Subject: |
Re: [Gnucap-devel] git repo proposal |
Date: |
Sun, 26 May 2013 09:24:49 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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
- Re: [Gnucap-devel] git repo proposal, Felix Salfelder, 2013/05/02
- Re: [Gnucap-devel] git repo proposal, al davis, 2013/05/26
- Re: [Gnucap-devel] git repo proposal,
Felix Salfelder <=
- Re: [Gnucap-devel] git repo proposal, al davis, 2013/05/26
- Re: [Gnucap-devel] git repo proposal, al davis, 2013/05/26
- Re: [Gnucap-devel] git repo proposal, al davis, 2013/05/26
- Re: [Gnucap-devel] git repo proposal, Felix Salfelder, 2013/05/26
- Re: [Gnucap-devel] git repo proposal, Kevin Zheng, 2013/05/26
- Re: [Gnucap-devel] git repo proposal, Felix Salfelder, 2013/05/26
- Re: [Gnucap-devel] git repo proposal, al davis, 2013/05/26
Re: [Gnucap-devel] git repo proposal, Felix Salfelder, 2013/05/26