aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--Makefile4
-rw-r--r--source/conf.py3
-rw-r--r--source/faq/index.rst7
-rw-r--r--source/gov/index.rst6
-rw-r--r--source/index.rst2
-rw-r--r--source/name_wordlist.txt27
-rw-r--r--source/projects/enum.rst1026
-rw-r--r--source/projects/glibc.rst90
-rw-r--r--source/projects/index.rst22
-rw-r--r--source/services/index.rst35
-rw-r--r--source/spelling_wordlist.txt60
-rw-r--r--source/tac/audit.rst30
-rw-r--r--source/tac/index.rst7
-rw-r--r--source/tac/minutes.rst13
14 files changed, 1327 insertions, 5 deletions
diff --git a/Makefile b/Makefile
index d0c3cbf..502dafb 100644
--- a/Makefile
+++ b/Makefile
@@ -12,6 +12,10 @@ BUILDDIR = build
help:
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+# Run spell checking.
+spelling:
+ @$(SPHINXBUILD) -b spelling -d "$(BUILDDIR)/doctrees" "$(SOURCEDIR)" "$(BUILDDIR)/spelling"
+
.PHONY: help Makefile
# Catch-all target: route all unknown targets to Sphinx using the new
diff --git a/source/conf.py b/source/conf.py
index c132d06..d768527 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -13,7 +13,8 @@ author = 'CTI TAC'
# -- General configuration ---------------------------------------------------
# https://www.sphinx-doc.org/en/master/usage/configuration.html#general-configuration
-extensions = []
+extensions = [ 'sphinxcontrib.spelling' ]
+spelling_word_list_filename = [ 'spelling_wordlist.txt', 'name_wordlist.txt' ]
templates_path = ['_templates']
exclude_patterns = []
diff --git a/source/faq/index.rst b/source/faq/index.rst
index 1ad148e..cb8a458 100644
--- a/source/faq/index.rst
+++ b/source/faq/index.rst
@@ -81,7 +81,7 @@ You have questions we have answers!
reflect the communities it supports?
* A: Members of the GNU Toolchain community will always be invited to
- become members of the technical advisory cuncil for the project.
+ become members of the technical advisory council for the project.
* Q: What is the composition of the project steering committee?
@@ -119,6 +119,11 @@ You have questions we have answers!
The requirements from the community are input to the steering committee,
and so the answer depends largely on exactly what was the intended purpose.
+* Q: Are there any presentations covering CTI?
+
+ * Yes, in October 2022 the CTI TAC gave an FSF hosted community Q&A:
+ https://media.libreplanet.org/u/libreplanet/m/the-gti-project-a-conversation-and-community-q-a/
+
-----------------
* :ref:`genindex`
diff --git a/source/gov/index.rst b/source/gov/index.rst
index a6b9fd4..0bfef38 100644
--- a/source/gov/index.rst
+++ b/source/gov/index.rst
@@ -17,8 +17,8 @@ The role of the GB is to review and authorize spending of funds, acting as
fiscal oversight to approved and prioritized projects that are presented
by the TAC.
-The role of the TAC is to work with the GNU Toolchain community to prioritze
-and refine requirments so they can be implemented to support the community.
+The role of the TAC is to work with the GNU Toolchain community to prioritize
+and refine requirements so they can be implemented to support the community.
The TAC has a seat on the GB, and must vote one of their members to attend
GB meetings. The TAC seat on the GB will act as the chair for GB meetings.
@@ -29,7 +29,7 @@ e.g. security.
Premier members of the Core Toolchain Infrastructure project are entitled
to one GB seat and one TAC seat.
-The intial TAC bootstrap included 3 community members and was expanded to
+The initial TAC bootstrap included 3 community members and was expanded to
10 community members. Membership in the TAC requires GB approval.
-----------------
diff --git a/source/index.rst b/source/index.rst
index 6b3bf9f..d10d495 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -15,6 +15,8 @@ trusted foundation in a secure supply chain.**
:maxdepth: 1
:caption: Contents:
+ Projects <projects/index>
+ Services <services/index>
CTI Governance <gov/index>
CTI TAC <tac/index>
FAQ <faq/index>
diff --git a/source/name_wordlist.txt b/source/name_wordlist.txt
new file mode 100644
index 0000000..a63c0d6
--- /dev/null
+++ b/source/name_wordlist.txt
@@ -0,0 +1,27 @@
+Carlos
+O'Donell
+David
+Edelsohn
+Frank
+Ch.
+Eigler
+Jeff
+Law
+Joel
+Brobecker
+Jose
+Marchesi
+Joseph
+Myers
+Nick
+Clifton
+Simon
+Marchi
+Siddhesh
+Poyarekar
+Martin
+Liška
+Chris
+Faylor
+DJ
+Delorie
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`
diff --git a/source/services/index.rst b/source/services/index.rst
new file mode 100644
index 0000000..93ed883
--- /dev/null
+++ b/source/services/index.rst
@@ -0,0 +1,35 @@
+Services
+========
+
+The CTI project requests that all services providers use FOSS to provide the
+services that project uses. The use of FOSS for the services is a mandatory
+requirement.
+
+The following services are currently being provided by CTI via the Linux Foundation IT:
+
+* Big Blue Button servers
+
+ * Service uses BBB which is FOSS and LGPL-3.0 licensed.
+
+ * ``https://github.com/bigbluebutton/bigbluebutton``
+
+ * glibc: Used for weekly patch triage meetings.
+ * https://sourceware.org/glibc/wiki/PatchworkReviewMeetings
+
+ * GNU Toolchain: Monthly office hours for the GNU Toolchain.
+ * https://gcc.gnu.org/wiki/OfficeHours
+
+* gitolite servers
+
+ * Service uses Gitolite which is FOSS and GPL-2.0 licensed.
+
+ * ``https://github.com/sitaramc/gitolite``
+
+ * Core Toolchain Infrastructure project documentation repository.
+ * ``git clone gitolite.coretoolchain.dev:cti/cti.coretoolchain.dev``
+
+-----------------
+
+* :ref:`genindex`
+
+* :ref:`search`
diff --git a/source/spelling_wordlist.txt b/source/spelling_wordlist.txt
new file mode 100644
index 0000000..dc7c11d
--- /dev/null
+++ b/source/spelling_wordlist.txt
@@ -0,0 +1,60 @@
+backend
+binutils
+bugzilla
+canconfirm
+chcker
+clamav
+cmd
+config
+Cron
+cron
+curation
+curator
+cvs
+Cybersecurity
+cybersecurity
+Django
+django
+editbugs
+featureful
+frontends
+gcc
+gdb
+git
+gitolite
+glibc
+gnu
+gnupload
+gpg
+html
+https
+irkerhook
+libc
+mlmmj
+ncftpput
+networkless
+Pipermail
+postfix
+pre
+prs
+pw
+py
+rabbitmq
+rebasing
+repo
+rst
+runtimes
+simark
+Sourceware
+sourceware
+spamassassin
+spammy
+ssh'ed
+svn
+testresults
+Toolchain
+toolchain
+trybot
+trybots
+webpages
+whitespace
diff --git a/source/tac/audit.rst b/source/tac/audit.rst
new file mode 100644
index 0000000..a47e4e3
--- /dev/null
+++ b/source/tac/audit.rst
@@ -0,0 +1,30 @@
+Annual Technical Audit
+======================
+
+The CTI TAC will conduct an annual technical audit of the services
+provided to ensure that the services in use continue to meet the
+technical requirements of the community.
+
+The audit will cover:
+
+ * Reviewing that services cover the current requirements.
+
+ * Includes security requirements.
+
+ * Reviewing that the services are being provided using FOSS.
+
+ * Reviewing the cost of all services currently being provided.
+
+If prices have increased or services are not being provided by FOSS
+that will be noted in the public report and actions will be taken
+by the TAC to discuss these with the community and current service
+provider.
+
+The CY24 audit has not yet been conducted, but the audit will review
+the current `services being used <../services/index>`_.
+
+-----------------
+
+* :ref:`genindex`
+
+* :ref:`search`
diff --git a/source/tac/index.rst b/source/tac/index.rst
index 2f0372c..41238dd 100644
--- a/source/tac/index.rst
+++ b/source/tac/index.rst
@@ -4,6 +4,11 @@
Core Toolchain Infrastructure - Technical Advisory Council
==========================================================
+.. toctree::
+
+ Meetings Minutes <minutes>
+ Annual technical audit <audit>
+
The Core Toolchain Infrastructure Technical Advisory Council is
currently made up of the following community member (alphabetical):
@@ -28,6 +33,8 @@ We wish to extend a heartfelt thank you to our previous CTI TAC members:
You can reach the CTI TAC by emailing `cti-tac@lists.linuxfoundation.org <mailto:cti-tac@lists.linuxfoundation.org>`_.
+CTI TAC mailing list archives: https://lore.kernel.org/cti-tac/
+
-----------------
* :ref:`genindex`
diff --git a/source/tac/minutes.rst b/source/tac/minutes.rst
new file mode 100644
index 0000000..b279cfb
--- /dev/null
+++ b/source/tac/minutes.rst
@@ -0,0 +1,13 @@
+Meeting Minutes
+===============
+
+The CTI TAC meets on the last Wednesday of every month at 11am EST5EDT.
+
+The CTI TAC meetings minutes are sent to mailing list for archival: https://lore.kernel.org/cti-tac/
+
+Recent meeting minutes are linked to here:
+
+ * `CTI TAC Meeting Notes 2024-02-28 <https://lore.kernel.org/cti-tac/ea82c272-9bdf-4685-bc72-9fa6da83e6be@redhat.com/T/#u>`_
+ * `CTI TAC Meeting Notes 2024-01-31 <https://lore.kernel.org/cti-tac/6b433955-2865-232a-44c0-59682cbac446@redhat.com/T/#u>`_
+
+Older meeting minutes can be found in the list archive.