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, Aug 05, 2015 at 12:02:59AM -0400, Mike Frysinger wrote:
> i won't be at cauldron (out of the country)
> 
> i'm still strongly in favor of getting rid of ChangeLogs entirely.  i have
> yet to find a scenario where the git commit itself did not contain all the
> details that i needed, or that really the ChangeLog file itself provided
> literally any value at all.  in a historical context (CVS), it might have
> made more sense, but that hasn't been the case for years.
> 
> i know GNU projects tend to be set in their ways though, so even moving to
> something like other GNU projects (coreutils/etc...) where the notes are in
> the git commit message and then the ChangeLog file is autogenerated would
> be a big step forward.  relying on git-merge-changelog is pure craziness.
> 
> i don't think merge commits are needed.  they add noise and doing a rebase
> loses no real information of value (slightly adjusted commit date and the
> original parent).
> 
> 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 love all these ideas.

Rich


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