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

[Simon Marchi <simon.marchi@efficios.com>]

Here's a revised list for GDB, I added some user-facing / functional
requirements I would think of.  It's probably still lacking some of the
implementation details that you are looking for, but I probably don't
know them, and it's hard to know what you don't know.

* Git Repository
  * Need push access
  * Ability for project maintainers to request push access for new
    contributors (or to do it themselves)
  * Ability for users to create user-branches (e.g. users/simark/foo),
    which will be ignored by the notification-sending script.

* git hooks
  * Need to be able to manage git hooks (https://github.com/AdaCore/git-hooks) on
    the server (right now, ssh to sourceware.org)
  * 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.

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

        Calls the irker (IRC notification of new commits)

  * Something sends emails about commits to the gdb-cvs mailing list

* Web-based navigation of the Git repository
  * Need to be able to browse the git repository online
  * https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git
  * If it exists, a more featureful git web frontends would be nice, one
    that allows searching files by name for instance.

* email-to-bugzilla script
  * The goal is that when a commit is pushed to the git repository, we
    check for any mention of a Bugzilla bugs, and post a message to those
    bugs
  * It accesses the Bugzilla database directly to check if a given bug
    number exists (could easily be changed to use some HTTP request)
  * It posts to bugzilla by sending an email to a local email account

* mailing lists
  * Those I know for sure are used / useful:
    * gdb@
    * gdb-announce@
    * gdb-cvs@ (now misnaed, but can be used to follow commits to the repo)
    * gdb-patches@
    * gdb-prs@
    * gdb-testers@
  * Not sure about these:
    * gdbadmin@: seems useful for whoever is responsible for snapshot
      generation or other GDB-related automated task.  It seems a bit
      spammy to send an email every day when the task succeeds.

      The daily commits in binutils-gdb that bump the date are made using
      this email address as the From, not sure if it matters
  * Pretty sure we can ignore these:
    * gdb-testresults@
    * gdb-patches-prs@:
    * gdb-webpages-cvs@

  * We also have a "global maintainers" list hosted at AdaCore.  It could
    make sense to move it to the main infrastructure.  Maybe Joel knows if
    there's a reason it's separate.

* Mailing list web interface
  * The original one, which I find not so useful now that we have
    public-inbox: https://sourceware.org/pipermail/gdb-patches/
  * However, old links need to keep working
  * public-inbox or something equivalent is necessary:
    * have a way to browse easily message threads that span multiple
      months / years
    * have a way to download raw messages, to apply patches locally

* daily snapshot generation
  * We have a script that generates daily tarballs (I don't know where
    or how)

* daily bump
  * We have a script that does a daily commit in the binutils-gdb repo
    to update a date (I don't know where or how)

* Website
  * Handwritten pages (in a CVS (!) repository)
  * scripts generating website contents (doc, ARI, etc)
  * SSH access to the machine hosting the website is used, as the scripts
    above generating website contents are run by the release manager, after
    having ssh'ed onto sourceware.org.

* Wiki
  * Currently, anyone with write access can give someone else write access.
  * At the very least, we need a way for project maintainers to request
    write access for a new member, or do it themselves

* bug tracker (bugzilla)
  * Sends notifications of new bugs and comments to gdb-prs
  * Sends notifications of comments on a big to users who are watching
    that bug
  * Accepts replies by email, both from users and from the
    email-to-bugzilla script.

* Release hosting
  * Releases, the release manager must be able to upload there
    * ftp://sourceware.org/pub/gdb/releases/
    * http://sourceware.org/pub/gdb/releases/
  * Snapshots, the daily script needs to be able to upload there
    * https://sourceware.org/pub/gdb/snapshots/

* patchwork (https://patchwork.sourceware.org/project/gdb/list/)
  * It receives emails from the gdb-patches mailing list
  * This instance doesn't get much use at the moment, because it gets
    filled so quickly and is impossible to keep up to date.

Simon