Re: [RFC] Toward a better NEWS file

[Martin Kletzander <mkletzan@xxxxxxxxxx>]

On Wed, Oct 19, 2016 at 03:59:37PM +0200, Andrea Bolognani wrote:
> On Wed, 2016-10-19 at 15:19 +0200, Martin Kletzander wrote:
> > > > Why don't we simply have a NEWS file in GIT, and require that
> > > > non-trivial commits or patch series include an update to NEWS,
> > > > so the NEWS file gets populated at time the feature/bug fix
> > > > gets merged.
> > > 
> > > I'm strongly against adding more generated files to the
> > > repository; if anything, we should have *less* of them[1].
> > > 
> > > But if we required the source file, docs/news.html.in, to
> > > be updated along with notable changes instead, I would be
> > > all for it! :)
> >  
> > I understood it like this:
> >  
> >   - stop generating NEWS file
> >   - populate NEWS file with notable features/bug-fixes along with the
> >     changes themselves
> >   - use NEWS to make nice news.html
>
> Why would we build news.html from NEWS when we already have
> a perfectly fine way to build both NEWS and news.html from
> news.html.in?

I meant news.html.in of course.  But we can be updating news.html.in and
keep all the files generated as they are now.

> > > [1] Hello, HACKING!
> >  
> > Yeah, that's a problem, we want the plain-text HACKING to be there, but
> > we want the stuff to be on the web page too.  This could be fixed by
> > making hacking.html.in generated from HACKING and changing HACKING to
> > use some kind of plaint-text friendly formatted text (org, rst, md, …)
> > in order not to lose the metadata ;)
>
> I was discussing this offline with Ján just yesterday.
> IMHO the way forward is to basically
>
>   * stop building HACKING from hacking.html.in
>   * move README-hacking to HACKING
>   * (optionally) rename hacking.html.in to
>     contributorguidelines.html.in - that's already the title
>     of the document anyway
>   * improve the contents of both HACKING and hacking.html.in
>
> I think HACKING should contain just the information required
> to get from a fresh git clone to a buildable source tree, eg.
> the extra steps you wouldn't have to take if you were building
> from a release archive. And README-hacking is basically there
> already.

OK, so you had different plans while I was just thinking how to keep the
same things in place but remove redundant duplicates from git.

> -- 
> Andrea Bolognani / Red Hat / Virtualization

Attachment: signature.asc
Description: Digital signature

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