On 2019-03-19 00:18, Rafal Luzynski wrote: > 16.03.2019 23:31 Aurelien Jarno wrote: > > [...] > > diff --git a/ChangeLog b/ChangeLog > > index 90558e434ce..fb88626efe1 100644 > > --- a/ChangeLog > > +++ b/ChangeLog > > @@ -1,3 +1,11 @@ > > +2019-01-31 Paul Eggert > > + > > + regex: fix read overrun [BZ #24114] > > + Problem found by AddressSanitizer, reported by Hongxu Chen in: > > + https://debbugs.gnu.org/34140 > > + * posix/regexec.c (proceed_next_node): > > + Do not read past end of input buffer. > > + > > As far as I know the date in the ChangeLog should be the date > when the change was pushed to the git repository, not when the > patch was authored. In case of the stable branches it should be > the date when it was pushed to the stable branch, not when it was > pushed to master. Shall we change this? Thanks for pointing that out. It appears we do not have a clear process about that, at least [1] doesn't say the date should be updated after a cherry-pick, and it doesn't say the contrary either. In practice looking at the glibc 2.28 branch (the 2.29 has very few commit, and most of them backported immediately after being committed to the master branch), it appears that both practices are common. I have attached a patch fixing the commit dates to give an example of the impact. I think we should just decide a rule, fix the wrong entries if needed, and apply it to new commits. On my side I am undecided what is the best option. Regards, Aurelien [1] https://sourceware.org/glibc/wiki/GlibcGit?Cherry_Pick_Changes_From_Another_Branch -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net