diff options
Diffstat (limited to 'source/projects')
| -rw-r--r-- | source/projects/enum.rst | 1026 | ||||
| -rw-r--r-- | source/projects/glibc.rst | 90 | ||||
| -rw-r--r-- | source/projects/index.rst | 22 |
3 files changed, 1138 insertions, 0 deletions
diff --git a/source/projects/enum.rst b/source/projects/enum.rst new file mode 100644 index 0000000..45edeb2 --- /dev/null +++ b/source/projects/enum.rst @@ -0,0 +1,1026 @@ +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 + :spelling:ignore:`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 fils 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` diff --git a/source/projects/glibc.rst b/source/projects/glibc.rst new file mode 100644 index 0000000..7e6604a --- /dev/null +++ b/source/projects/glibc.rst @@ -0,0 +1,90 @@ +CY24: Migrate glibc to CTI services +=================================== + +In 2024 the goal is to migrate the glibc project to use CTI services. + +The community feedback was collected from July to August 2023. + +The `GNU Maintainers for the glibc project +<https://sourceware.org/glibc/wiki/MAINTAINERS#Project_stewards_.28GNU_package_maintainers.29>`_ +were asked to make a decision on switching to the services provided by +CTI and currently the following support has been tallied: + + * Ryan Arnold - Yay + * Paul Eggert - Nay + * Jakub Jelinek - Abstain + * Maxim Kuvyrkov - Yay + * Joseph Myers - Yay + * Carlos O'Donell - Yay + * Alexandre Oliva - Nay + * Andreas Schwab - No statement + +As of 2024-02-28 feedback from the stewards was being incorporated into +this document to provide assurances that FOSS would be used to provide +services and that there was a checking mechanism in place for services +to remain FOSS. + +Next steps: + + * Revisit discussion with Paul Eggert and attain resolution in March 2024 + to move forward. + +Posted originally here: https://inbox.sourceware.org/libc-alpha/45e98807-908f-0968-b6fe-5dbb0af265b1@redhat.com/ + +The following is the suggested list of services to be migrated (with notes): + +* Mailing lists + + * Support public-inbox for mailing list archives. + * Use of public-inbox means archives can be cloned and copied. + * Use of LF IT Subspace mailing list services (mlmmj, postfix). + +* bug database + + * Consider starting fresh in new Bugzilla 5.0.4+ instance and freeze old product. + * glibc component in sourceware instance marked "Not open for new bugs." + * No easy way to clone this but we can discuss options. + * Isolate bugzilla from other services. + +* git + + * Migrate to gitolite + * Community manages access via gitolite keys. + * Minimize all access to sources and isolate from other processes. + * Minimal server side web hooks where required. + * Isolate git service from other services. + * Stop supporting svn/cvs and provide tarball dumps. + +* wiki + + * Migrate to git-based documentation with existing content copied over. + * Suggest rst/Sphinx or similar to existing discussions for GCC docs. + * Sphinx with themes can provide a lot of flexibility for display. + * Isolate wiki service from other services. + +* patch management + + * Continue patchwork usage and maintenance of isolated instance + * Required for community driven pre-commit CI + * LF IT hosting patchwork instance with community hosting bots. + * Isolate patchwork from other services. + +* Website + + * Provide a simple static site. + * Isolate web hosting from other services. + +* Meeting + + * Already migrated away from proprietary solutions. + * Continue to use LF IT BBB instance for glibc meetings including weekly patch review. + * Isolate BBB from other services. + +The current list of glibc services were put together as part of the +CTI TAC `glibc service enumeration <./enum>`_. + +----------------- + +* :ref:`genindex` + +* :ref:`search` diff --git a/source/projects/index.rst b/source/projects/index.rst new file mode 100644 index 0000000..1192bd8 --- /dev/null +++ b/source/projects/index.rst @@ -0,0 +1,22 @@ +Projects +======== + +The CTI TAC has the following ongoing active projects: + +.. toctree:: + + glibc + +* CY24: Evaluate migration of gcc, binutils and gdb to CTI services + +The CTI TAC has the following completed projects: + +.. toctree:: + + enum + +----------------- + +* :ref:`genindex` + +* :ref:`search` |