Hello David,
On 09/18/2015 04:16 PM, David Hill wrote:
The "guix" example I wrote about - is case #2. The related guix
repositories (eg. guix/dhcp.git) are related just by being under
the "guix" directory. Users can pick-and-choose which repository
they are interested in.
Are you suggesting that we use one or more guix repositories and not
put the material on the savannah project site at all? Keeping two
different repos (savannah and guix), differently structured, would
introduce problems of synchronisation and (in my opinion) be quite
confusing, so I am not happy about having both.
"guix" is a project hosted on Savannah ( http://sv.gnu.org/p/guix ),
whose administrators requested several GIT repositories (
http://savannah.gnu.org/git/?group=guix ):
git://git.savannah.gnu.org/guix.git
git://git.savannah.gnu.org/guix/dhcp.git
git://git.savannah.gnu.org/guix/gnunet.git
git://git.savannah.gnu.org/guix/guix-artwork.git
git://git.savannah.gnu.org/guix/maintenance.git
That was just an example of how you could set your project on savannah (if you
wanted multiple git repositories).
What do you think of all this (especially the idea of simply adding
the existing history to the initial commit message)?
Starting a fresh repository is not a bad idea.
Instead of adding the previous history to a git-commit message,
I'd simply create a 'ChangeLog-OLD' file, listing the detailed changes.
For example, GNU coreutils has multiple 'changelog' files containing detailed
old changes
( http://git.savannah.gnu.org/cgit/coreutils.git/tree/ ),
Coreutils stopped updating the 'Changelog' files manually circa 2008 when git
commit history replaced it.
Then, of course, there's the release. If I were to have more than one
savannah repo, would that require having more than one tarball. I was
just about to start looking at the procedures for a first release.
Marcelo says it looks fairly complicated. I want to keep that as
straightforward as possible.
Note that you can pack multiple git repositories into one tarball
(e.g. 'make dist' for GNU coreutils includes the files from the 'gnulib'
repository).
But I won't claim that's easy to setup (will require some careful tweaking to
the 'Makefile.am' files if you're using autotools).
IMHO, preparing a release should serve two purposes (at least):
1. automate as much as possible for you (the maintainer),
so that 'make dist' will prepare everything you need
(preferably: just one tar.gz file).
2. prepare the tarball in a way that make it easy for users to
build/install/use your program,
e.g. after 'wget + configure + make + sudo make install' the program should be
ready to use,
including any data files in system-wide directories (e.g.
/usr/local/share/gnuspeech).
It's likely worth spending some time and evaluating the pros and cons of the
tarball method to see what it provides.
On the other hand, there's also "release early,release often" adage,
and you might prefer to put a new gnuspeech release out there quickly, and work
out the kinks later.
regards,
- assaf
