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 as contributor and Greg A. Woods 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