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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]