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] |
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 -mike
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] |