This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Hash out a solution for ChangeLog/NEWS at the Cauldron?


On Wed, 5 Aug 2015, Mike Frysinger wrote:

> updating the bug list in the NEWS file is annoying, and as it is written
> now, adds no value imo.  a huge list of random numbers that literally no
> one looks at is a waste of all our time.  if we could push that data into
> the bug tracker and then have a script to autogenerate the chunk for the
> NEWS file, that'd be much nicer.
> 
> a simple straw man to illustrate what i'm thinking:
> 
> * The following bugs are resolved with this release:
> 
>   [BZ #438] _POSIX2_C_VERSION got missing
>   [BZ #18007] (CVE-2014-8121) nss state sharing causes application denial of 
>   service

I support having such a more meaningful list (given a way to put a list of 
fixed versions in Bugzilla).

That would be something generated by a script and inserted into the NEWS 
file and checked in just before release.  I was imagining that the 
generated ChangeLog file would however not be checked in at all - rather, 
when a new process is adopted the existing ChangeLog would be renamed to 
ChangeLog.18 and future ChangeLogs generated only for release tarballs.  
But it would be possible to have a process where the generated ChangeLog 
does get checked in before releases (and maybe before edits fixing bad 
commit messages if that's easier than maintaining an edit list), just not 
with most commits, in which case git archive could still be used to make 
release tarballs.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]