faq, gov, projects, services, tax: Update all docs.

Added a spell checker via `make spelling` to check spelling.
Currently projects/enum.rst is still not spelling clean.

Added more faq entries.

Reworded governance page.

Added projects page to list ongoing projects in CTI.

Added services page to list currently provided services.

Added TAC section on suggested annual technical audit by the TAC.

Signed-off-by: Carlos O'Donell <carlos@redhat.com>

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.