On Mon, 2015-10-26 at 16:25 +0100, Michal Privoznik wrote:
On 26.10.2015 16:03, Andrea Bolognani wrote:
Generate the HACKING file at dist time like we're already doing for NEWS, AUTHORS and ChangeLog.
The file shouldn't be tracked by git as it's not a source file but rather a generated one; because of this, it should also be generated in $(builddir) as opposed to $(top_srcdir).
Cheers.
Andrea Bolognani (4): HACKING: Generate inside the build directory HACKING: Remove generated copy HACKING: Add to ignore file HACKING: Include in EXTRA_DIST
.gitignore | 1 + HACKING | 1008 ----------------------------------------------- ------------ Makefile.am | 3 +- cfg.mk | 3 +- 4 files changed, 4 insertions(+), 1011 deletions(-) delete mode 100644 HACKING
Frankly, I'd like to keep HACKING in the git. I know it's a generated file, but the reasoning should be that a new contributor, who is about to make his first contribution will clone the repo and the first thing they should search for is Readme and HACKING files. I know that dealing with the file which is then again generated from another file, keeping them both in git may be counterintuitive, but I'd like to keep the file there.
We also have README-hacking which contains information that is arguably more vital to a first-time contributor, eg. how to bootstrap the development environment. Other possible ways to approach the problem: * include a note in README-hacking telling the user to run 'make HACKING' to build the contributor guidelines * move README-hacking to HACKING and point the user to the HTML version of the contributor guidelines, either inside the docs/ directory or available on the website I really dislike the idea of tracking a generated file in the repository, but I see the value in having directions for the first-time contributor available right after clone. Still, maybe we can work out something that makes everyone happy :) Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team