This is the mail archive of the 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 05 Aug 2015 11:18, Joseph Myers wrote:
> 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.

i'd be fine with either approach

Attachment: signature.asc
Description: Digital signature

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