RFC: GDB 10.x release target schedule

[Simon Marchi]

On 2020-02-08 10:40 a.m., Joel Brobecker wrote:
> Hi everyone,
> 
> We released GDB 9.1 today (yay!), and we are shooting for 9.2
> being release 3 months from now, so around May 8th.
> 
> With that in mind, we would normally be looking at a GDB 10.x
> release about 3 months after. But given that 9.1 came out
> a little later than we had hoped, I propose we aime for 10.x
> a little earlier. Right now, the schedule page proposes May 5th
> for the gdb-10-branch creation. I propose we aim for that, which
> should allow for a release in June/July and puts us in the same
> timeframe as in previous years.
> 
> Thoughts?
> 
> Cheers!
> -- 
> Joel

Hi Joel,

This schedule is fine with me.  It has a much bigger impact on you, as the release
manager.

For the next release, could we consider using the vcs-to-changelog script [1] that
glibc are now using to generate their ChangeLog?  They are not writing ChangeLog
entries by hand, instead they run that script just before a release to generate the
entries for all the new commits included in that release.

The best way for us to get that script would be to update our gnulib import and add
vcs-to-changelog as an imported module.  I'm not sure it's fit for our use right now,
I believe if we just run it like that it will generate entries for commits that don't
affect GDB (e.g. commits in binutils).  Also, it doesn't understand the concept of
having multiple ChangeLog files and putting the entry in the closest ChangeLog file, so
it generates entries like this:

2020-02-06  Shahab Vahedi  <shahab@synopsys.com>

        COMMIT: 1d5d29e73f4b5f1af4df5b6e39ccf2fa722acead
        gdb: Catch exceptions if the source file is not found

        * gdb/source-cache.c: Modified.
        (ensure): Modified function.
        (get_line_charpos): Modified function.
        * gdb/testsuite/gdb.tui/tui-missing-src.exp: New file.
        * gdb/tui/tui-source.c: Modified.
        (set_contents): Modified function.

In other words, it assumes there is a single ChangeLog file at the top-level.

I don't think these are blockers, but if we would like to use the script for the next
release, we should start to think about it now.

Simon

[1] https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/vcs_to_changelog.py;h=bf4bc7cf64c9897e4a56758209f5821434b377c4;hb=HEAD