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.
Thanks for the additional detail!
Thanks, David