Re: [Savannah-hackers-public] Problems with initial load of new Git repo

[Assaf Gordon]

Hello,

> On Sep 11, 2015, at 15:40, David Hill <address@hidden> wrote:

[...]
> You mention "binary entries". Are "builds" not acceptable if they are not 
> done under GNU/Linux?

It is not that compiled binaries are "not acceptable", it is more that a git 
repository (at least on savannah, but also universally, IMHO) is not the place 
to store compiled binaries.
Git excels at storing textual files, and is meant as a version control 
mechanism primarily for textual source code files.
This is not to say some repositories don't keep small binary files in it (e.g. 
PNG/JPG files), but almost all repositories do not contain compiled binaries 
(such that users will just download and use).

Users who will use your git repository commonly expect to be able to compile 
the code by themselves (in a fashion, it is meant for advanced users).

GNU Savannah has two other mechanisms to provide downloadable files (for users 
who don't want to deal with git):

First,
The 'tarball' official releases, GPG-signed by you and uploaded to the gnu 
server at http://ftp.gnu.org contained a 'distribution ready' tarball that 
users can expect to be able to build with a simple 'configure && make && sudo 
make install'.
On the same server, some projects (e.g. emacs) also provide compiled binaries 
for some OSes which perhaps one can expect it will be complicated to build you 
project.

Emacs source-code tarballs are here: 
  http://ftp.gnu.org/gnu/emacs/
And pre-compiled binaries for windows are here:
  http://ftp.gnu.org/gnu/emacs/windows/

Second,
a less used option (at least for official GNU projects) is the 'downloads' 
feature (which you can enable on the project's savannah admin page).

I noticed there are already some files stored the downloads area:
  http://download.savannah.gnu.org/releases/gnuspeech/
And you can upload more files there with rsync:
  rsync -avhP LOCALFILE address@hidden:/releases/gnuspeech/

These two places would be much much better place to store compiled binaries 
than in a git repository.

As a side note, if you are trying to build gnuspeech for Mac OS, here are two 
pointers:
1. HomeBrew ( http://brew.sh/ ) - is a very popular package manager for Mac OS. 
They already have mechanisms to download tarballs and compile them on Mac OS X 
(example, their recipe for GNU coreutils: 
https://github.com/Homebrew/homebrew/blob/master/Library/Formula/coreutils.rb ).

2. The GNU Lilypond has extensive experience with building a complicated 
program and packaging it to Mac OS X. See here: http://lilypond.org/gub/ or 
contact the Lilypond authors ( https://savannah.gnu.org/users/dak would likely 
be able to help ).

[...]

Regarding git submodules:
> Yes, I have been having some discussion on that, and it may be that fewer 
> would suffice -- four to be precise.

We can wait with the exact details until you've experimented with the git 
repository/submodules structures.
I would ask you, though, please don't push any further changes to the current 
GIT,
so there will be no concerns about resetting it.

Simply write to the mailing list when you're ready to continue.

regards,
 - assaf