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

On Tue, Dec 6, 2022 at 12:42 PM Simon Marchi <[email protected]>
wrote:

> 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 [email protected]". 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.
>

Thanks for the additional detail!

Thanks, David