Re: [savannah-help-public] Gnuspeech - git repository

[Assaf Gordon]

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