path: root/source/projects/enum.rst

CY23: Service enumeration
=========================

The following is the completed service enumeration for gcc, binutils, glibc and gdb.

GNU Compiler Collection
-----------------------

* git:

  * Three repositories.

    * /git/gcc.git (main GCC repository)

      * AdaCore git hooks.

        * Older (Python 2) version of those hooks,
          commit `1f9082567e82788e4da748fe13ddd0b230166faf`. 
          Should move to current Python 3 version, but will require careful
          review of hook configuration to update for any incompatible changes
          since the version currently used.

        * See refs/meta/config:project.config for hook configuration.

        * Hooks generate commit emails, 524288 byte size limit.
          Various custom configuration for the contents of those
          emails.  Emails are not sent for commits already in the
          repository being merged to certain development branches.

        * Merge commits rejected on master (including the trunk
          symbolic-ref) and release branches.

        * Commits referencing Bugzilla bugs update Bugzilla
          automatically.

        * Custom refs/users/ and refs/vendors/ namespaces for
          user/vendor branches and tags.

        * Branch deletion and non-fast-forward merges rejected, with
          custom message, outside the refs/users/ and refs/vendors/
          namespaces.

        * Hooks use scripts in ~gccadmin/hooks-bin.

          * commit_checker makes various checks.  Author email as
            mailing list address disallowed (to avoid problems with
            "git am" when the email address was changed automatically
            for DKIM purposes).  Subject must not look like a
            ChangeLog header, or be a single word.  Commit message
            must not contain a From-SVN: line that could confuse it
            with commits actually converted from SVN.  Commits
            disallowed to closed release branches.  ChangeLog format
            checked (with code from the main GCC repository) for
            commits to master / trunk and release branches.

          * commit_email_formatter does various custom formatting of
            commit emails.

          * email-to-bugzilla-filtered sends messages to
            /sourceware/infra/bin/email-to-bugzilla for master / trunk
            and release branch commits.  Note that latter script
            currently relies on direct SQL access to the Bugzilla
            database.

          * email_to.py determines which mailing lists to send commit
            emails to: gcc-cvs, possibly together with libstdc++-cvs.

          * style_checker does nothing.

          * update_hook disallows creating or updating refs to be
            based on the old git-svn history and branch creation
            outside the expected branch namespaces.

      * /git/gcc.git/config has custom [pack] configuration to use
        delta islands, to avoid inefficiency on default clones that
        don't fetch many of the over 6000 refs in the repository.  It
        also has repack.writeBitmaps = true.

      * On occasion, there may be changes to refs done manually on the
        server that aren't permitted by the hooks; for example, moving
        an inactive branch from refs/heads/devel/ to
        refs/dead/heads/.  Such a move should be followed by
        "git repack --window=1250 --depth=250 -b -AdFfi"
        to keep the delta islands configuration efficient.

      * The bitmaps configuration would apparently be most efficient
        if "git repack --window-memory=500m --window=250 --depth=50 -b
        -A -d -i" were run weekly, though this is not currently done.

    * /git/gcc-old.git (old git mirror, different refs / commit IDs)

      * This repository is read-only, enforced by a pre-receive hook.

    * /git/gcc-wwwdocs.git (GCC website)

      * denyNonFastforwards = true.

      * Simpler hook configuration, not using AdaCore hooks.

        * Only a post-receive hook.  That post-receive hook is a
          symlink to a file checked out from this repository itself.
          It calls /sourceware/infra/bin/post-receive-email to send
          commit emails to gcc-cvs-wwwdocs and also automatically
          updates a checkout and then runs the preprocess script on
          that checkout.

  * Write access to git over SSH.  606 users in the gcc group have
    access, as of 2023-03-23 (some may no longer be active; some might
    be disabled in /etc/passwd or have no active ssh keys and so not
    in fact be able to commit).

  * Read-only public access with both git:// and https:// protocols.

  * Web-based browsing access for all three repositories:
    https://gcc.gnu.org/git/; want URLs there to be stable.

    * RedirectMatch ^/g:(.+)$ (for g: URLs for commits)

    * RedirectMatch ^/r[0-9]+-[0-9]+-g([0-9a-f]+)$ (for URLs for
      commits in "gcc-descr" format).

    * Similar redirections also for such URLs using SVN revisions to
      map those to corresponding git commits.

* SVN:

  * One read-only repository, /svn/gcc.

    * Read-only enforced by pre-commit hook.

    * Would probably be reasonable to replace by a downloadable
      tarball (repository is 45 GB) or repository dump.

    * URLs pointing to SVN revisions are automatically redirected to
      corresponding git revisions, see above.

* CVS:

  * One read-only repository, /cvs/gcc.

    * Includes various separate pieces (CVS modules); the part for GCC
      itself stopped being used for new GCC changes when GCC moved to
      SVN, long before the part for the GCC website stopped being used
      when that was migrated to git.  Some directories such as
      benchmarks/ may never have formally been migrated to another
      version control system, but those are not in active use.

    * Would probably be reasonable to replace by a downloadable
      tarball.

  * Also repositories /cvs/java and /cvs/libstdc++ for early history
    of projected integrated into GCC a long time ago.

    * Downloadable tarballs of those are already available:
      https://gcc.gnu.org/pub/gcc/old-releases/old-cvs/

* rsync:

  * See https://gcc.gnu.org/rsync.html

    * rsync access to CVS repositories, SVN repositories, FTP download
      areas, websites, mailing list archives.  Server claims rsync
      access to GNATS databases but the configured directories don't
      appear to exist.  Note list provided by the server includes many
      non-GCC projects.

* ftp / downloads:

  * Download area available as https://gcc.gnu.org/pub/gcc/ and
    ftp://gcc.gnu.org/pub/gcc/

  * Release and snapshot processes place things there automatically.
    Snapshot process also updates LATEST-* symlinks (i.e. it doesn't
    just add new files / directories).  I'm not aware of any
    automation for removing old snapshots, but they do get removed
    from time to time.

  * New versions of host libraries (as used by
    contrib/download_prerequisites) are placed manually in
    infrastructure/, some form of access to add new files there is
    needed.

* cron jobs run from the gccadmin account:

  * The actual scripts run for these are checked into the
    maintainer-scripts directory in the main GCC repository; the
    checkout used on gcc.gnu.org needs to be updated manually.

  * Nightly update_version_git (updates DATESTAMP and ChangeLog files
    in git for master and active release branches).

  * Nightly update_web_docs_git and update_web_docs_libstdcxx_git
    (update online documentation for master on gcc.gnu.org).

  * Weekly snapshot jobs for master and active release branches.
    These make snapshots available in the download area (including
    updating the LATEST-* symlinks) and send emails to the gcc list
    announcing them.  They may be temporarily disabled while release
    candidates are being created for a given branch to avoid
    confusion.  These jobs also maintain state (.snapshot_date-*
    files) in ~gccadmin, that's used by the next run of a snapshot job
    to know what the last snapshot from a branch was.

* Bugzilla:

  * This has various local changes and uncommitted files, and parts of
    the checkout in /www/gcc/bugzilla are only root-accessible, so I
    can't fully assess what all the local changes and configuration
    are.  However, extensions/GCC/ probably contains the main local
    code.

  * Used for gcc and classpath products.

  * User account creation is restricted for users in a large list of
    blacklisted domains; users in such domains must email
    gcc-bugzilla-account-request (a mailing list) to get someone (with
    addusers permission, which might be a local change) to create them
    an account.  This is necessary because previously spam was added
    faster than the REST API could be used to remove it.

  * The REST API may be used for both anonymous and authenticated
    operations.

  * Bugzilla sends email for various actions on bugs.

  * Bugzilla receives incoming email to gcc-bugzilla@gcc.gnu.org and
    processes it to add to bugs.

  * Commit messages also get appended to bugs (see discussion above
    under git for how this uses SQL access at present).

  * When a new GCC release branch is created, it's necessary to update
    bug summaries so e.g. "13 Regression" becomes "13/14 Regression".
    This has at least sometimes been done with a script using direct
    SQL access, see e.g. /home/gccadmin/11changer.pl.

* Mailing lists:

  * Many mailman mailing lists, some but not all described at
    https://gcc.gnu.org/lists.html - names include gcc*
    gnutools-advocacy fortran java* libstdc++* jit.  gcc-sc is a
    mailing list on the sourceware.org domain rather than on
    gcc.gnu.org, don't know why.

  * Most but not all are public.

  * Some announcement lists are moderated.

  * Configuration for e.g. message size limits may vary between lists.

  * Lists may set sender address to the list where needed to avoid
    DKIM problems.

  * It's important that people can post to lists without being
    subscribers to those lists, and that they are not prevented from
    posting in HTML (although we'd rather they didn't) to avoid
    placing excess barriers to contributing to discussions.

  * There is some level of spam filtering applied to incoming email
    before it goes to lists.

  * Three sets of list archives, all need to keep stable URLs for
    existing messages:

    * Older MHonArc archives (no longer updated),
      e.g. https://gcc.gnu.org/legacy-ml/gcc/2020-01/ (with /ml/
      redirections).

    * Pipermail archives,
      e.g. https://gcc.gnu.org/pipermail/gcc/2023-March/thread.html -
      note we've deliberately disabled most email address munging that
      Pipermail might do by default, to avoid messing up patches,
      especially those containing Texinfo code.

    * public-inbox archives,
      e.g. https://inbox.sourceware.org/gcc-patches/

* User email:

  * Email to @gcc.gnu.org addresses available for users with write
    access; users can configure where it forwards to (via a special
    command run over ssh).

  * @gcc.gnu.org addresses also have special access rights in GCC
    Bugzilla (maybe also in Sourceware Bugzilla).

  * User gccadmin is both a user and a mailing list at present (that
    is, when cron automatically generates emails to
    gccadmin@gcc.gnu.org, it goes to a mailing list of the same name).

* User account management:

  * There is a system for accounts to be created (with approval from a
    global or subsystem maintainer, not someone with
    write-after-approval access), giving ssh access to write to git
    (and thus the ability to have @gcc.gnu.org email forwarded, and
    thus to set up an @gcc.gnu.org account in Bugzilla with
    corresponding privileges).

  * Most users do not have shell access over ssh.

  * Users can change their own SSH keys and forwarding email address:
    https://www.sourceware.org/sourceware/accountinfo.html

* Wiki:

  * MoinMoin wiki.

  * User accounts have no write access by default because of spam; an
    existing user must add someone to the EditorGroup page before they
    have write access.

  * Accounts without write access get created by spammers anyway and
    are periodically deleted automatically because MoinMoin slows down
    when there are too many users.

* Website:

  * Website https://gcc.gnu.org/ (plus http://) (plus
    gcc.sourceware.org name).

  * Static content from gcc-wwwdocs.git, passed through limited
    preprocessing from git hooks.

  * Documentation for master and releases (served as static content,
    after the initial generation process).

  * Various redirects, some using complicated rewrite rules.

  * Mailing list archives, as discussed above.

  * Bugzilla, as discussed above.

  * Repository browsing, as discussed above.

  * Wiki, as discussed above.

  * Download area for releases and snapshots, as discussed above.

  * Mailman interface for subscribing / unsubscribing to mailing lists.

* Non-sourceware services:

  * Releases also made available from ftp.gnu.org.

  * Translation Project used to handle translations.

  * There is a version of the website on
    https://www.gnu.org/software/gcc/ - not sure how that's kept up to
    date in sync with the https://gcc.gnu.org/ version.

  * The gcc.gnu.org name is part of gnu.org DNS so any updates are
    handled through that.

  * IRC at irc.oftc.net/#gcc

Originally posted to the CTI TAC mailing list: https://lore.kernel.org/cti-tac/7e59d8db-7b26-1249-ad5c-67b7f3411e1@codesourcery.com/T/#u

GNU Binary Utilities
--------------------

* 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

   * git-hooks (https://github.com/AdaCore/git-hooks) installed in
     the binutils-gdb.git repository.

   * binutils-gdb.git's git-hooks configuration pointing to the following
     scripts locally installed on the machine hosting the repository,
     to which the binutils & GDB admins need access (currently done
     via SSH access)

     * binutils-gdb.git/hooks-bin/email_to.py
       Small python script which determine which mailing-list(s) to use
       when sending commit email notifications. No special requirements
       other than a Python3 interpreter.

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

       No special requirements other than a Python3 interpreter.

       Note - although the comment refers to gdb mailing lists, this hook also
       catches sent to the binutils mailing lists.

     * /git/binutils-gdb.git/hooks-bin/style_checker

       An empty script at the moment (set because the git-hooks require
       it to be set).

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

       A perl script whose maintainership is unclear. Comments at
       the beginning of the script mention David Hampton <hampton@cisco.com>
       as contributor and Greg A. Woods <woods@web.net> as having "greatly
       hacked" it. Beyond that, don't know.

       * 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
         (Joel: I think sourceware-bugzilla@localhost)

       * Joel's note: If I understood the script correctly, then there
         must be a handler in the local MTA to catch those emails and
         send them to bugzilla for further processing. Don't know how
         that works, though.

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

       Bash wrapper scripts which essentially calls the following
       script: /usr/local/bin/irkerhook.py. I suspect the origin
       of this script is this github repository:
       https://gitlab.com/esr/irker

       If not, ISTR that it was Tom Tromey who got it installed,
       so we could ask him.

   * The git-hooks themselves send emails about commits to the binutils-cvs
     mailing list (each repository configures the destination, and for
     binutils-gdb, this this a "dynamic" configuration via the email_to.py
     script mentioned above allowing the destination to vary depending
     on which files got modified, whether they are binutils files or GDB
     file, or both).

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

   * URLs to a given commit in the Web UI should be easily computable
     using their SHA1; e.g.
     "https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=%(rev)s"
     We use those in the commit emails being sent by the git-hooks.

* Mailing lists

   * Those I know for sure are used / useful:

     * binutils@

     * binutils-cvs@ (now misnamed, but can be used to follow commits to the repo)

   * There is also:

     * bug-binutils@gnu.org

       * which is effectively the same as the binutils@sourceware.org list,
         but hosted by the FSF.

* Mailing list web interface

   * The original one, which I find not so useful now that we have
     public-inbox: https://sourceware.org/pipermail/binutils/

   * 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

* Website

   * Handwritten pages in a couple of CVS repositories:

     * The gnu.org copy is maintained on https://savannah.gnu.org/;

     * The sourceware.org copy is maintained on sourceware.org itself,
       in /cvs/gdb/htdocs

     * It used to be that both versions were kept in sync by duplicating
       all the commits in both repositories. But this was recently changed
       in favor of installing redirects from the gnu.org website to
       the sourceware.org. This was the first step towards a possible
       transition of the web-pages to Git.

   * The documentation part of the website is created by building the
     relevant files locally and then uploading them to the website.

   * SFTP access to the machine hosting the website is used in order to
     upload new or edited files and to change symbolic links.

* 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 binutils@

   * Sends notifications of comments on a bug 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

     * https://sourceware.org/pub/binutils/releases/

   * Pre-release snapshots are available here:

     * https://sourceware.org/pub/binutils/snapshots/

Originally posted to the CTI TAC mailing list here: https://lore.kernel.org/gti-tac/679ba29a-24c7-6684-a565-0e5d5db05b19@redhat.com/

GNU C Library
-------------

* mailing lists

  * Mailman 2 mailing lists: https://sourceware.org/mailman/listinfo/

    * libc-announce

    * libc-alpha

    * libc-stable

    * libc-help

    * libc-locales

    * libc-testresults

    * glibc-cvs

    * glibc-bugs

    * glibc-bugs-regex (limited bugs just for regex).

  * Closed legacy mailing lists:

    * libc-ports: https://sourceware.org/mailman/listinfo/libc-ports

    * libc-hacker: https://sourceware.org/mailman/listinfo/libc-hacker

  * Mailing lists accept non-html email only.

  * Run through spamassassin

  * Run through clamav

* Pipermail archives:

  * https://sourceware.org/pipermail/

  * e.g. https://sourceware.org/pipermail/libc-alpha/

* public-inbox archives:

  * https://inbox.sourceware.org/*

  * e.g. https://inbox.sourceware.org/libc-alpha/

* MHonArc archives (/legacy-ml/) - no longer updated

  * The /legacy-ml/ URLs and /ml/ redirects to them need to keep working.

  * E.g. https://sourceware.org/legacy-ml/libc-alpha/2020-01/

* bugzilla 5.0.4+

  * Uses backend SQL database of MariaDB 10.3

  * Must be able to send email to glibc-bugs mailing list.

    * Don't know how email is routed to this list.

  * Must also send email glibc-bugs-regex mailing list.

    * Don't know how email is routed to this list.

  * Must be able to send email to all users on the bug.

  * Must be able to receive email when someone responds to a glibc-bugs
    email e.g. sourceware-bugzilla@sourceware.org.

  * Custom Administration->Groups settings for User RegExp.

    * canconfirm: Allow certain domains to always be able to confirm bugs.

    * editbugs: Likewise but for editbugs.

  * Must have REST API enabled to allow RM to generate release list
    of fixed bugs using the glibc/scripts/list-fixed-bugs.py script
    e.g. https://sourceware.org/bugzilla/rest.cgi/

    * Implies that non-logged-in users can list and view all bugs
      that were fixed for the release.

  * Must have account creation disabled due to spamming.

  * Must have someone with Bugzilla admin access to:

    * Add new users to bugzilla.

    * Add new Product components, versions, and milestones.

    * Add new Key Words

    * Remove users.

* git 2.31

  * Allows per-user access to commit to the glibc repo.

  * Allows per-user access to commit to the legacy glibc-ports repo.

  * Uses group access to control repository access.

  * Must be able to send email to glibc-cvs mailing list with one
    email for each commit made by a developer to any branch of the repository.

  * AdaCore hooks need more thorough audit for required services.

    * Must be able to send email to bugzilla to update bugs.

    * Done by AdaCore hook 'file-commit-cmd'

    * Configured to use email-to-bugzilla-filtered command.

    * Uses connection to SQL database to determine if bug exists.

    * Currently uses shared AdaCore hooks configured via origin/meta/config 

      * Active hooks:

        * post-receive

          * AdaCore post_receive

            * /git/glibc.git/hooks-bin/post-receive

            * Triggers irkerhook.py (see notes below).

            * Does not work today, likely due to requirement to register OFTC user.

        * post-update

            * Standard git-update-server-info.

        * pre-receive

            * AdaCore pre_receive

        * AdaCore config:

            * No max line lengths.

            * Allow UTF-8 in commit messages.

            * 5MiB max email size.

            * Max 500 commit messages for larger commit series sent to glibc-cvs.

            * Reject merge commits to master and release branches.

            * Allow rebasing only private branches (non master and non release).

        * Run minimal style checker, nominally for whitespace issue rejection.

        * Run extra commit checking to avoid source address for author being wrong.

            * /git/glibc.git/hooks-bin/commit_checker

              * From email format checker. No special requirements.

            * /git/glibc.git/hooks-bin/style_checker

              * Style chcker. No special requirements.

        * Send email to bugzilla if a commit mentions a bug.

          * /git/glibc.git/hooks-bin/email-to-bugzilla-filtered

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

            * Must be able to connect to bugzilla SQL database.

            * Does not appear to work today. We don't get emails for commits with bugs.

        * Send IRC message to per-project configured IRC channel.

          * Involves irkerhook.py and git config information for project.

          * Hook must be able to connect to external IRC networks to post IRC notices.

* wiki

  * Uses MoinMoin 1.9.10

  * Must have account creation disabled due to spamming.

    * Uses EditorGroup permissions to allow any community member to add a new
      community member to the wiki e.g. human vetting another human.

  * Must be able to send notification emails.

  * Cron run to purge users not in EditorGroup to prevent wiki slowdown.

* patch management.

  * Uses patchwork v3.1.1.post18-g11cf1f3

  * Must be able to receive email (as part of collecting patch data)

  * Must be able to send emails as part of account verification.

  * Uses django for administration

  * Must allow authenticated REST API access for patchwork.

    * Currently rate limited.

  * Used by SLI tools (Carlos O'Donell)

    * Run manually on developer systems.

  * Auto-close on commit patchwork bot (Siddhesh Poyarekar)

    * Run on sourceware.org via cron.

  * Used for weekly patch management meetings.

  * git-pw integration used to access patchwork directly using REST API and API token.

* Red Hat Bluejeans remote meeting system.

  * Must allow remote video and audio for participants around the world.

  * Allows weekly glibc patch review meetings for patch review collaboration.

  * Meetings must operate without host needing to be present so community can host.

    * Delegating host is difficult in bluejeans.

  * Managed by Bluejeans/Verizon.

* pre-commit CI system https://gitlab.com/djdelorie/glibc-cicd

  * Run inside a VM.

  * Uses networkless containers for further build isolation.

  * Highest risk system because it runs mailing list posted patches.

  * Event curation system (curator):

    * Must have network access to patchwork REST API.

    * Must have access to SQL database for storing state.

      * Currently using MariaDB.

    * Must allow runners to access curator REST API URL.

    * One curator currently hosted by DJ Delorie.

  * Event running system (runner + trybots):

    * Must have network access to curator REST API.

    * Must have local network access to rabbitmq queue (job delegation)

    * trybots must have local network access to rabbitmq.

      * Must have network access to patchwork REST API to post results.

      * Must have network access to container registries to pull modern containers.w

      * Must have network git access to pull updated glibc git repo.

    * Generally the runner and trybots are on one site together.

      * Avoid passing rabbitmq traffic beyond the local network.

    * Eventual emailing of results to the mailing list will happen via another bot
      that is distinct from this system to avoid the runners needing anything but
      restricted network access.

    * One runner hosted by DJ Delorie	

    * One i686 trybot hosted by DJ Delorie

    * One "patch applies" trybot hosted by DJ Delorie

* Website (sourceware.org)

  * CVS hosted website.

  * Static redirect to gnu.org website.

* Website (gnu.org) https://www.gnu.org/software/libc/

  * CVS hosted website uploads along with manual.

    * Manuals are generated with scripts in the CVS repo and generated files committed.

  * All static content.

  * Website automatically updated after CVS commits.

  * Manged by the GNU Project/FSF.

* Release tarballs (ftp upload of gpg-signed release tarballs) https://ftp.gnu.org/gnu/libc/

  * Use gnupload script to gpg sign uploaded tarballs.

    * Uses ncftpput to place files into /incoming directories.

    * Network ftp access required.

  * Managed by the GNU Project/FSF.

* Translation project services https://translationproject.org/html/welcome.html

  * https network access to TP servers to fetch uploaded translation files.

  * Managed by the Translation Project.

Originally posted to the CTI TAC mailing list here: https://lore.kernel.org/gti-tac/13b3266b-a410-77fd-5dfc-4e4994b630cd@redhat.com/T/#u

GNU Debugger
------------

* 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 misnamed, 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.

Originally posted to the CTI TAC mailing list here: https://lore.kernel.org/gti-tac/b755774c-3912-2dac-957c-91f659c95119@efficios.com/

-----------------

* :ref:`genindex`

* :ref:`search`

.. spelling::
   htdocs
   Pre
   computable
   irker
   irkerhook
   gdbadmin
   gccadmin
   addusers
   gnutools
   fortran
   libstdc
   wwwdocs
   pre
   py
   usr
   libstdcxx
   classpath
   symlink
   symlinks
   redirections
   descr
   formatter
   writeBitmaps
   devel
   AdFfi
   denyNonFastforwards
   passwd
   contrib
   www
   sc
   Texinfo
   preprocessing
   oftc
   maintainership
   pw
   prs
   ssh'ed