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