RFC: GDB 10.x release target schedule

[Joel Brobecker]

Hi Simon,

> > 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.
>
> This schedule is fine with me.  It has a much bigger impact on you, as
> the release manager.

That's no problem. The day I am no longer sufficiently available
to follow the release pace that's right for GDB, we should start
looking for my replacement. I'm still happy to continue for
as long as you guys are happy with me doing it, though ;-).

> 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.

This would be absolutely brilliant.

In terms of impact, I think it might not be so much on the release
manager. The release tarball is created by running the src-release.sh
script. This seems like it might be the best place to handle
the creation of those ChangeLog files? Another argument in favor
of handling the ChangeLog files there is the fact that we have
nightly source packaging on sourceware, and the source packaging
also uses src-release.sh. So doing it there would make it work
for both nightly source packaging and the release.

One thing we might want is to have a server-side check that revision
logs are correctly formatted. I'm planning on enhancing the git-hooks
to allow that because GCC asked for the ability to perform some
GCC-specific checks on the revision log. This would be an excellent
use of this hooks for us too.

One thing we could do is perhaps consult with the binutils folks
about that. I have a feeling they'll be interested in it too, and
if we switch both GDB and binutils, we don't have to tweak the
ChangeLog entry to be be performed only for commits that change
GDB files. Nor will we have to remembe which ChangeLog files are
now deprecated vs still active...

I really look forward to that enhancement. Right now, my focus
for community contributions is more around the git-hooks for GCC,
but if there is something I can do to help, let me know!

-- 
Joel