On Mon, Oct 26, 2015 at 05:05:49PM +0100, Andrea Bolognani wrote: > 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. > Successfully building libvirt (which should generate HACKING) is a prerequisite for making any changes to it anyway (except for translations). A large part of 'HACKING' is currently dealing with whitespace and brace rules, which are enforced by syntax-check. Moving them to a separate file (CodingStyle) or deleting them completely and pointing new contributors to running 'make syntax-check' with cppi installed would reduce the length of the file, thus making it more likely to be read completely. > 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 > I vote for this option. Let's keep the essential information in README-hacking, and the information needed for larger patches and second-time contributors in HACKING. Jan
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list