Re: Action: Setup working group for the GNU Toolchain proposal to migrate to LF IT managed services

[Joel Brobecker <brobecker@adacore.com>]

> Details:
> 
> - Working group will enumerate in detail the GNU Toolchain project services
>   for the projects including gcc, glibc, binutils and gdb.

Here is what Simon and I could think of for GDB:

* Git Repository
* Web-based navigation of the Git repository
  https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git
* git-hooks

* Website
    - Handwritten pages (in a CVS (!) repository)
    - scripts generating website contents (doc, ARI, etc)

* [methodology can be rediscussed, but for now, we have the following
  workflow]

  SSH access to the machine hosting the website, as the scripts above
  generating website contents are run by the release manager, after
  having ssh'ed onto sourceware.org.

* Wiki

* bug tracker (bugzilla)

* Not sure if we want to change this or not, but sourceware.org
  also offers FTP download of releases, pre-releases, and snapshots.

  Releases are made available on ftp.gnu.org as well, and I do not
  think we want to change that part.

* Some scripts spawned from the git-hooks, due to the binutils-gdb's
  git-hooks config:

  - /[...]/binutils-gdb.git/hooks-bin/commit-extra-checker.py

    Verifies that we do not have this issue:

        # With commits created using "git am" of patches sent via the gdb@ or
        # gdb-patches@ mailing list, it's possible that the author information
        # gets changed into "xxx via xxx@sourceware.org". Catch and reject those,
        # so the person doing the push can fix this before the push is allowed.

  - /sourceware/infra/bin/email-to-bugzilla

        Sends a copy of commit messages to bugzilla if commit
        has a PR number in it.

  - /git/binutils-gdb.git/hooks-bin/post-receive

        Calls the irker (IRC notification of new commits)

  We'll need a way to get those installed on the machine hosting
  the git repository, and hopefully also a convenient way for us
  to allow testing before deployment (right now, we SSH to
  sourceware.org).

* patchwork
  (https://patchwork.sourceware.org/project/gdb/list/)

  Simon reports that this instance doesn't get much use at the moment,
  because it gets filled so quickly and is impossible to keep up to date.

  I (Joel) think that the project really needs to have a proper
  review system. It's too time-consuming and ineffective to have each
  maintainer do its own tracking. So having a review system that GDB
  Maintaniers are willing to adopt is very important, IMO. Maybe
  patchwork can fit the bill, or maybe it might be another system.
  Something for Simon and I perhaps to discuss with the other GDB
  maintainers?

-- 
Joel