[libvirt] [PATCH 0/4] HACKING: Improve handling

[Ján Tomko]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20151027/4abdcb25/attachment-0001.sig>