[PATCH 0/5] Multiple website cleanups

[PATCH 0/5] Multiple website cleanups

[Siddhesh Poyarekar]

Most of the changes are structural and formatting. The biggest change is
probably in the FAQ.

Sid

Siddhesh Poyarekar (5):
  projects/glibc: slightly adjust the structure
  Add a toplevel README
  services: Clean up links to projects
  tac/audit: Minor cleanups
  faq: Reformat so that it's not a list

 README                    |  15 +++
 source/faq/index.rst      | 223 ++++++++++++++++++--------------------
 source/projects/glibc.rst |  11 +-
 source/services/index.rst |  17 ++-
 source/tac/audit.rst      |   6 +-
 5 files changed, 139 insertions(+), 133 deletions(-)
 create mode 100644 README

-- 
2.43.0

[PATCH 1/5] projects/glibc: slightly adjust the structure

[Siddhesh Poyarekar]

Add some subheadings and fix a broken link.

Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
---
 source/projects/glibc.rst | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/source/projects/glibc.rst b/source/projects/glibc.rst
index 7e6604a..a400dab 100644
--- a/source/projects/glibc.rst
+++ b/source/projects/glibc.rst
@@ -5,6 +5,9 @@ In 2024 the goal is to migrate the glibc project to use CTI services.
 
 The community feedback was collected from July to August 2023.
 
+Current Status
+--------------
+
 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
@@ -24,13 +27,17 @@ 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:
+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/
 
+Service migration
+-----------------
+
 The following is the suggested list of services to be migrated (with notes):
 
 * Mailing lists
@@ -81,7 +88,7 @@ The following is the suggested list of services to be migrated (with notes):
   * Isolate BBB from other services.
 
 The current list of glibc services were put together as part of the
-CTI TAC `glibc service enumeration <./enum>`_.
+CTI TAC `glibc service enumeration <./enum.html>`_.
 
 -----------------
 
-- 
2.43.0

[PATCH 2/5] Add a toplevel README

[Siddhesh Poyarekar]

Add basic instructions to allow one to test and later submit changes for
review and inclusion.

Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
---
 README | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 README

diff --git a/README b/README
new file mode 100644
index 0000000..f0a7f64
--- /dev/null
+++ b/README
@@ -0,0 +1,15 @@
+CTI documentation portal
+========================
+
+You need sphinxcontrib-spelling and piccolo-theme to build html pages
+from the rst sources, both of which are available through pip.  Once you
+have them, run
+
+  make html
+
+To build the html pages for testing.
+
+Submitting changes
+------------------
+
+Send your patches to cti-tac@lists.linuxfoundation.org.
-- 
2.43.0

[PATCH 3/5] services: Clean up links to projects

[Siddhesh Poyarekar]

Use links on project names instead of putting them in bulleted lists.

Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
---
 source/services/index.rst | 17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/source/services/index.rst b/source/services/index.rst
index 84cb02b..34eba77 100644
--- a/source/services/index.rst
+++ b/source/services/index.rst
@@ -11,21 +11,18 @@ The following services are currently being provided by CTI via the Linux Foundat
 
 * Big Blue Button servers
 
-    * Service uses BBB which is FOSS and LGPL-3.0 licensed.
+    * Service uses `BBB <https://github.com/bigbluebutton/bigbluebutton>`_
+      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>`_.
 
-    * 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
+    * GNU Toolchain: `Monthly office hours <https://gcc.gnu.org/wiki/OfficeHours>`_
+      for the GNU Toolchain.
 
 * gitolite servers
 
-    * Service uses Gitolite which is FOSS and GPL-2.0 licensed.
-
-      * ``https://github.com/sitaramc/gitolite``
+    * Service uses `Gitolite <https://github.com/sitaramc/gitolite>`_ which is
+      FOSS and GPL-2.0 licensed.
 
     * Core Toolchain Infrastructure project documentation repository.
         * ``git clone gitolite.coretoolchain.dev:cti/cti.coretoolchain.dev``
-- 
2.43.0

[PATCH 4/5] tac/audit: Minor cleanups

[Siddhesh Poyarekar]

Subsume the sub-bullet into its parent and fix a dead link.

Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
---
 source/tac/audit.rst | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/source/tac/audit.rst b/source/tac/audit.rst
index a47e4e3..119f7c6 100644
--- a/source/tac/audit.rst
+++ b/source/tac/audit.rst
@@ -7,9 +7,7 @@ technical requirements of the community.
 
 The audit will cover:
 
-  * Reviewing that services cover the current requirements.
-
-    * Includes security requirements.
+  * Reviewing that services cover the current requirements, including any security requirements.
 
   * Reviewing that the services are being provided using FOSS.
 
@@ -21,7 +19,7 @@ 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>`_.
+the current `services being used <../services/index.html>`_.
 
 -----------------
 
-- 
2.43.0

[PATCH 5/5] faq: Reformat so that it's not a list

[Siddhesh Poyarekar]

Making it into subheadings and content instead not only makes it cleaner
looking, it also gives us a nifty bar on the right to scroll through
questions.

Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
---
 source/faq/index.rst | 223 ++++++++++++++++++++-----------------------
 1 file changed, 106 insertions(+), 117 deletions(-)

diff --git a/source/faq/index.rst b/source/faq/index.rst
index cb8a458..84ff30f 100644
--- a/source/faq/index.rst
+++ b/source/faq/index.rst
@@ -6,123 +6,112 @@ FAQ
 
 You have questions we have answers!
 
-* Q: Can we keep deploying services as we have? 
-
-  * A: No. The GNU Toolchain is a critical foundation of trust for the GNU/Linux 
-    ecosystem and the demands on its infrastructure, services, and security
-    requirements have grown over time. The trend of increasing complexity to 
-    support its development and associated financial demands will not abate.
-    Different projects have different risk tolerances and the GNU Toolchain
-    must meet more stringent expectations to maintain the trust of the 
-    ecosystem. It is with this context in mind that CTI has been formed.
-
-* Q: What concrete steps will CTI help with?
-
-    * A: Some of the major goals include:
-
-        * Isolating all services in VMs or containers to increase service
-          security and reduce service resource interference. 
-
-        * Allow volunteers to focus efforts outside of core infrastructure
-          maintenance.
- 
-        * Prepare for additional software supply chain requirements from
-
-* Q: Why are you currently using Linux Foundation IT as the service provider?
-
-    * A: The CTI TAC recommendation is to use Linux Foundation IT services
-      for core infrastructure. The LF IT team already supports many of
-      the same services for the Linux kernel and at scale. The migration
-      would involve moving services from Sourceware.org to LF IT servers.
-      We continue to be thankful and appreciative of the time spent by
-      Sourceware.org volunteers in support of the current services.
-
-* Q: What is the urgency vs what is the timeline?
-
-    * A: The GNU Toolchain community should be making consistent forward 
-      progress to improve our infrastructure and cybersecurity position.
-      Showing progress is important for the ecosystem to trust us as a
-      secure and critical part of the software supply chain. We should
-      not wait until there are Cybersecurity regulations that are beyond
-      our ability to comply with as the FOSS ecosystem of tooling and
-      infrastructure. Projects of similar scope and importance have been
-      deploying significant resources for the use of the development community.
-
-* Q: Sourceware volunteers have fielded requests and organized volunteer 
-  efforts that have worked well. Does LF allow volunteers to administer 
-  the servers together with them? Have they in the past?
-
-    * A: The CTI TAC is the point of contact for volunteers.  CTI can fund 
-      multiple activities, by multiple entities, and the way in which the
-      volunteers engage may differ between them.
-
-* Q: How does this project relate to the GNU Project or the Free Software
-  Foundation (FSF)?
-
-    * A: Many of the GNU Toolchain components are a part of the GNU
-      Project, and contribute to the development of the GNU system.
-      The FSF supports the GNU Project, and in turn supports the GNU
-      Toolchain. The GNU Toolchain community works with the FSF via a 
-      working together fund (https://www.fsf.org/working-together/fund)
-      to support the development of the GNU Toolchain directly.
-      The Core Toolchain Infrastructure project is distinct from the
-      GNU Project and the FSF.
-
-* Q: How does this project relate to the GCC Compile Farm Project 
-  (https://gcc.gnu.org/wiki/CompileFarm)?
-
-    * A: The GCC Compiler Farm is a unique resource for the GNU Toolchain
-      and provides interactive systems for developers to manually test on 
-      a wide variety of hardware and software configurations. This is not
-      exactly the same set of requirements that the community might have
-      for securing a supply chain, or using modern CI/CD workflows.
-
-* Q: How will the composition of the Core Toolchain infrastructure project
-  reflect the communities it supports?
-
-    * A: Members of the GNU Toolchain community will always be invited to
-      become members of the technical advisory council for the project.
-
-* Q: What is the composition of the project steering committee?
-
-    * A: The project steering committee will be composed of sponsoring 
-      members of the Linux Foundation and members of the GNU Toolchain
-      community.
-
-* Q: What does the project TAC do?
-
-    * A: The TAC takes input from the GNU Toolchain community and works 
-      with the members to, implement, and resolve prioritized requirements.
-
-* Q: Is the GNU Toolchain development model going to change?
-
-    * A: No. The aim of the project is to provide additional infrastructure
-      for the community that is being made available to support the 
-      GNU Toolchain. All development changes will always be driven by the
-      community.
-
-* Q: Is Sourceware (https://sourceware.org/) going to be deprecated?
-
-    * A: The GNU Toolchain Infrastructure project is distinct from Sourceware.
-      The intent is to move critical infrastructure from Sourceware to the 
-      Core Toolchain Infrastructure project to provide paid services.
-
-* Q: Who can use the new infrastructure?
-
-    * A: That depends on the requirements given by the GNU Toolchain community.
-      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: What can the new infrastructure be used for?
-
-    * A: That depends on the requirements given by the GNU Toolchain community.
-      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/
+Can we keep deploying services as we have?
+""""""""""""""""""""""""""""""""""""""""""
+No. The GNU Toolchain is a critical foundation of trust for the
+GNU/Linux ecosystem and the demands on its infrastructure, services, and
+security requirements have grown over time. The trend of increasing complexity
+to support its development and associated financial demands will not abate.
+Different projects have different risk tolerances and the GNU Toolchain must
+meet more stringent expectations to maintain the trust of the ecosystem. It is
+with this context in mind that CTI has been formed.
+
+What concrete steps will CTI help with?
+"""""""""""""""""""""""""""""""""""""""
+Some of the major goals include:
+
+* Isolating all services in VMs or containers to increase service security and
+  reduce service resource interference. 
+
+* Allow volunteers to focus efforts outside of core infrastructure maintenance.
+
+* Prepare for additional software supply chain requirements from
+
+Why are you currently using Linux Foundation IT as the service provider?
+""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+The CTI TAC recommendation is to use Linux Foundation IT services for
+core infrastructure. The LF IT team already supports many of the same services
+for the Linux kernel and at scale. The migration would involve moving services
+from Sourceware.org to LF IT servers.  We continue to be thankful and
+appreciative of the time spent by Sourceware.org volunteers in support of the
+current services.
+
+What is the urgency vs what is the timeline?
+""""""""""""""""""""""""""""""""""""""""""""
+The GNU Toolchain community should be making consistent forward progress
+to improve our infrastructure and cybersecurity position.  Showing progress is
+important for the ecosystem to trust us as a secure and critical part of the
+software supply chain. We should not wait until there are Cybersecurity
+regulations that are beyond our ability to comply with as the FOSS ecosystem of
+tooling and infrastructure. Projects of similar scope and importance have been
+deploying significant resources for the use of the development community.
+
+Sourceware volunteers have fielded requests and organized volunteer efforts that have worked well. Does LF allow volunteers to administer the servers together with them? Have they in the past?
+""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+The CTI TAC is the point of contact for volunteers.  CTI can fund multiple
+activities, by multiple entities, and the way in which the volunteers engage
+may differ between them.
+
+How does this project relate to the GNU Project or the Free Software Foundation (FSF)?
+""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+Many of the GNU Toolchain components are a part of the GNU Project, and
+contribute to the development of the GNU system.  The FSF supports the GNU
+Project, and in turn supports the GNU Toolchain. The GNU Toolchain community
+works with the FSF via a `working together fund
+<https://www.fsf.org/working-together/fund>`_ to support the development of the
+GNU Toolchain directly.  The Core Toolchain Infrastructure project is distinct
+from the GNU Project and the FSF.
+
+How does this project relate to the `GCC Compile Farm Project <https://gcc.gnu.org/wiki/CompileFarm>`_?
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+The GCC Compiler Farm is a unique resource for the GNU Toolchain and
+provides interactive systems for developers to manually test on a wide variety
+of hardware and software configurations. This is not exactly the same set of
+requirements that the community might have for securing a supply chain, or
+using modern CI/CD workflows.
+
+How will the composition of the Core Toolchain infrastructure project reflect the communities it supports?
+""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+Members of the GNU Toolchain community will always be invited to become members
+of the technical advisory council for the project.
+
+What is the composition of the project steering committee?
+""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+The project steering committee will be composed of sponsoring members of
+the Linux Foundation and members of the GNU Toolchain community.
+
+What does the project TAC do?
+"""""""""""""""""""""""""""""
+The TAC takes input from the GNU Toolchain community and works with the
+members to, implement, and resolve prioritized requirements.
+
+Is the GNU Toolchain development model going to change?
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""
+No. The aim of the project is to provide additional infrastructure for
+the community that is being made available to support the GNU Toolchain. All
+development changes will always be driven by the community.
+
+Is `Sourceware <https://sourceware.org/>`_ going to be deprecated?
+""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+The GNU Toolchain Infrastructure project is distinct from Sourceware.
+The intent is to move critical infrastructure from Sourceware to the Core
+Toolchain Infrastructure project to provide paid services.
+
+Who can use the new infrastructure?
+"""""""""""""""""""""""""""""""""""
+That depends on the requirements given by the GNU Toolchain community.
+The requirements from the community are input to the steering committee, and so
+the answer depends largely on exactly what was the intended purpose.
+
+What can the new infrastructure be used for?
+""""""""""""""""""""""""""""""""""""""""""""
+That depends on the requirements given by the GNU Toolchain community.
+The requirements from the community are input to the steering committee, and so
+the answer depends largely on exactly what was the intended purpose.
+
+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/>`_.
 
 -----------------
 
-- 
2.43.0

Re: [PATCH 1/5] projects/glibc: slightly adjust the structure

[Carlos O'Donell]

On 3/7/24 14:30, Siddhesh Poyarekar wrote:
> Add some subheadings and fix a broken link.
> 

The HTML part is not OK. Please check format of cross doc ref.

> Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
> ---
>  source/projects/glibc.rst | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/source/projects/glibc.rst b/source/projects/glibc.rst
> index 7e6604a..a400dab 100644
> --- a/source/projects/glibc.rst
> +++ b/source/projects/glibc.rst
> @@ -5,6 +5,9 @@ In 2024 the goal is to migrate the glibc project to use CTI services.
>  
>  The community feedback was collected from July to August 2023.
>  
> +Current Status
> +--------------

OK.

> +
>  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
> @@ -24,13 +27,17 @@ 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:
> +Next steps
> +----------

OK.

>  
>   * 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/
>  
> +Service migration
> +-----------------

OK.

> +
>  The following is the suggested list of services to be migrated (with notes):
>  
>  * Mailing lists
> @@ -81,7 +88,7 @@ The following is the suggested list of services to be migrated (with notes):
>    * Isolate BBB from other services.
>  
>  The current list of glibc services were put together as part of the
> -CTI TAC `glibc service enumeration <./enum>`_.
> +CTI TAC `glibc service enumeration <./enum.html>`_.

I don't think this is correct.

I agree the website link is broken, but it has to be a cross-document reference
that works when generated as html (rather than assume html).

>  
>  -----------------
>  

-- 
Cheers,
Carlos.

Re: [PATCH 2/5] Add a toplevel README

[Carlos O'Donell]

On 3/7/24 14:30, Siddhesh Poyarekar wrote:
> Add basic instructions to allow one to test and later submit changes for
> review and inclusion.
> 

Uses markdown, suggest the preferred README.md rather than README.

> Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
> ---
>  README | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>  create mode 100644 README
> 
> diff --git a/README b/README
> new file mode 100644
> index 0000000..f0a7f64
> --- /dev/null
> +++ b/README
> @@ -0,0 +1,15 @@
> +CTI documentation portal
> +========================
> +
> +You need sphinxcontrib-spelling and piccolo-theme to build html pages
> +from the rst sources, both of which are available through pip.  Once you
> +have them, run
> +
> +  make html
> +
> +To build the html pages for testing.
> +
> +Submitting changes
> +------------------
> +
> +Send your patches to cti-tac@lists.linuxfoundation.org.

-- 
Cheers,
Carlos.

Re: [PATCH 2/5] Add a toplevel README

[Carlos O'Donell]

On 3/7/24 14:30, Siddhesh Poyarekar wrote:
> Add basic instructions to allow one to test and later submit changes for
> review and inclusion.
> 
> Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>

Content looks good though, you can keep my RB and push so long as you call it README.md.

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

> ---
>  README | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>  create mode 100644 README
> 
> diff --git a/README b/README
> new file mode 100644
> index 0000000..f0a7f64
> --- /dev/null
> +++ b/README
> @@ -0,0 +1,15 @@
> +CTI documentation portal
> +========================
> +
> +You need sphinxcontrib-spelling and piccolo-theme to build html pages
> +from the rst sources, both of which are available through pip.  Once you
> +have them, run
> +
> +  make html
> +
> +To build the html pages for testing.
> +
> +Submitting changes
> +------------------
> +
> +Send your patches to cti-tac@lists.linuxfoundation.org.

-- 
Cheers,
Carlos.

Re: [PATCH 3/5] services: Clean up links to projects

[Carlos O'Donell]

On 3/7/24 14:30, Siddhesh Poyarekar wrote:
> Use links on project names instead of putting them in bulleted lists.
> 
> Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>

LGTM.

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

> ---
>  source/services/index.rst | 17 +++++++----------
>  1 file changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/source/services/index.rst b/source/services/index.rst
> index 84cb02b..34eba77 100644
> --- a/source/services/index.rst
> +++ b/source/services/index.rst
> @@ -11,21 +11,18 @@ The following services are currently being provided by CTI via the Linux Foundat
>  
>  * Big Blue Button servers
>  
> -    * Service uses BBB which is FOSS and LGPL-3.0 licensed.
> +    * Service uses `BBB <https://github.com/bigbluebutton/bigbluebutton>`_
> +      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>`_.
>  
> -    * 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
> +    * GNU Toolchain: `Monthly office hours <https://gcc.gnu.org/wiki/OfficeHours>`_
> +      for the GNU Toolchain.
>  
>  * gitolite servers
>  
> -    * Service uses Gitolite which is FOSS and GPL-2.0 licensed.
> -
> -      * ``https://github.com/sitaramc/gitolite``
> +    * Service uses `Gitolite <https://github.com/sitaramc/gitolite>`_ which is
> +      FOSS and GPL-2.0 licensed.
>  
>      * Core Toolchain Infrastructure project documentation repository.
>          * ``git clone gitolite.coretoolchain.dev:cti/cti.coretoolchain.dev``

-- 
Cheers,
Carlos.

Re: [PATCH 4/5] tac/audit: Minor cleanups

[Carlos O'Donell]

On 3/7/24 14:30, Siddhesh Poyarekar wrote:
> Subsume the sub-bullet into its parent and fix a dead link.
> 

Docs change is OK but HTML change is not.

> Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
> ---
>  source/tac/audit.rst | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/source/tac/audit.rst b/source/tac/audit.rst
> index a47e4e3..119f7c6 100644
> --- a/source/tac/audit.rst
> +++ b/source/tac/audit.rst
> @@ -7,9 +7,7 @@ technical requirements of the community.
>  
>  The audit will cover:
>  
> -  * Reviewing that services cover the current requirements.
> -
> -    * Includes security requirements.
> +  * Reviewing that services cover the current requirements, including any security requirements.
>  
>    * Reviewing that the services are being provided using FOSS.
>  
> @@ -21,7 +19,7 @@ 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>`_.
> +the current `services being used <../services/index.html>`_.

This needs to work across documents correctly and not assume HTML.

>  
>  -----------------
>  

-- 
Cheers,
Carlos.

Re: [PATCH 5/5] faq: Reformat so that it's not a list

[Carlos O'Donell]

On 3/7/24 14:30, Siddhesh Poyarekar wrote:
> Making it into subheadings and content instead not only makes it cleaner
> looking, it also gives us a nifty bar on the right to scroll through
> questions.
> 

LGTM.

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

> Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
> ---
>  source/faq/index.rst | 223 ++++++++++++++++++++-----------------------
>  1 file changed, 106 insertions(+), 117 deletions(-)
> 
> diff --git a/source/faq/index.rst b/source/faq/index.rst
> index cb8a458..84ff30f 100644
> --- a/source/faq/index.rst
> +++ b/source/faq/index.rst
> @@ -6,123 +6,112 @@ FAQ
>  
>  You have questions we have answers!
>  
> -* Q: Can we keep deploying services as we have? 
> -
> -  * A: No. The GNU Toolchain is a critical foundation of trust for the GNU/Linux 
> -    ecosystem and the demands on its infrastructure, services, and security
> -    requirements have grown over time. The trend of increasing complexity to 
> -    support its development and associated financial demands will not abate.
> -    Different projects have different risk tolerances and the GNU Toolchain
> -    must meet more stringent expectations to maintain the trust of the 
> -    ecosystem. It is with this context in mind that CTI has been formed.
> -
> -* Q: What concrete steps will CTI help with?
> -
> -    * A: Some of the major goals include:
> -
> -        * Isolating all services in VMs or containers to increase service
> -          security and reduce service resource interference. 
> -
> -        * Allow volunteers to focus efforts outside of core infrastructure
> -          maintenance.
> - 
> -        * Prepare for additional software supply chain requirements from
> -
> -* Q: Why are you currently using Linux Foundation IT as the service provider?
> -
> -    * A: The CTI TAC recommendation is to use Linux Foundation IT services
> -      for core infrastructure. The LF IT team already supports many of
> -      the same services for the Linux kernel and at scale. The migration
> -      would involve moving services from Sourceware.org to LF IT servers.
> -      We continue to be thankful and appreciative of the time spent by
> -      Sourceware.org volunteers in support of the current services.
> -
> -* Q: What is the urgency vs what is the timeline?
> -
> -    * A: The GNU Toolchain community should be making consistent forward 
> -      progress to improve our infrastructure and cybersecurity position.
> -      Showing progress is important for the ecosystem to trust us as a
> -      secure and critical part of the software supply chain. We should
> -      not wait until there are Cybersecurity regulations that are beyond
> -      our ability to comply with as the FOSS ecosystem of tooling and
> -      infrastructure. Projects of similar scope and importance have been
> -      deploying significant resources for the use of the development community.
> -
> -* Q: Sourceware volunteers have fielded requests and organized volunteer 
> -  efforts that have worked well. Does LF allow volunteers to administer 
> -  the servers together with them? Have they in the past?
> -
> -    * A: The CTI TAC is the point of contact for volunteers.  CTI can fund 
> -      multiple activities, by multiple entities, and the way in which the
> -      volunteers engage may differ between them.
> -
> -* Q: How does this project relate to the GNU Project or the Free Software
> -  Foundation (FSF)?
> -
> -    * A: Many of the GNU Toolchain components are a part of the GNU
> -      Project, and contribute to the development of the GNU system.
> -      The FSF supports the GNU Project, and in turn supports the GNU
> -      Toolchain. The GNU Toolchain community works with the FSF via a 
> -      working together fund (https://www.fsf.org/working-together/fund)
> -      to support the development of the GNU Toolchain directly.
> -      The Core Toolchain Infrastructure project is distinct from the
> -      GNU Project and the FSF.
> -
> -* Q: How does this project relate to the GCC Compile Farm Project 
> -  (https://gcc.gnu.org/wiki/CompileFarm)?
> -
> -    * A: The GCC Compiler Farm is a unique resource for the GNU Toolchain
> -      and provides interactive systems for developers to manually test on 
> -      a wide variety of hardware and software configurations. This is not
> -      exactly the same set of requirements that the community might have
> -      for securing a supply chain, or using modern CI/CD workflows.
> -
> -* Q: How will the composition of the Core Toolchain infrastructure project
> -  reflect the communities it supports?
> -
> -    * A: Members of the GNU Toolchain community will always be invited to
> -      become members of the technical advisory council for the project.
> -
> -* Q: What is the composition of the project steering committee?
> -
> -    * A: The project steering committee will be composed of sponsoring 
> -      members of the Linux Foundation and members of the GNU Toolchain
> -      community.
> -
> -* Q: What does the project TAC do?
> -
> -    * A: The TAC takes input from the GNU Toolchain community and works 
> -      with the members to, implement, and resolve prioritized requirements.
> -
> -* Q: Is the GNU Toolchain development model going to change?
> -
> -    * A: No. The aim of the project is to provide additional infrastructure
> -      for the community that is being made available to support the 
> -      GNU Toolchain. All development changes will always be driven by the
> -      community.
> -
> -* Q: Is Sourceware (https://sourceware.org/) going to be deprecated?
> -
> -    * A: The GNU Toolchain Infrastructure project is distinct from Sourceware.
> -      The intent is to move critical infrastructure from Sourceware to the 
> -      Core Toolchain Infrastructure project to provide paid services.
> -
> -* Q: Who can use the new infrastructure?
> -
> -    * A: That depends on the requirements given by the GNU Toolchain community.
> -      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: What can the new infrastructure be used for?
> -
> -    * A: That depends on the requirements given by the GNU Toolchain community.
> -      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/
> +Can we keep deploying services as we have?
> +""""""""""""""""""""""""""""""""""""""""""
> +No. The GNU Toolchain is a critical foundation of trust for the
> +GNU/Linux ecosystem and the demands on its infrastructure, services, and
> +security requirements have grown over time. The trend of increasing complexity
> +to support its development and associated financial demands will not abate.
> +Different projects have different risk tolerances and the GNU Toolchain must
> +meet more stringent expectations to maintain the trust of the ecosystem. It is
> +with this context in mind that CTI has been formed.
> +
> +What concrete steps will CTI help with?
> +"""""""""""""""""""""""""""""""""""""""
> +Some of the major goals include:
> +
> +* Isolating all services in VMs or containers to increase service security and
> +  reduce service resource interference. 
> +
> +* Allow volunteers to focus efforts outside of core infrastructure maintenance.
> +
> +* Prepare for additional software supply chain requirements from
> +
> +Why are you currently using Linux Foundation IT as the service provider?
> +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> +The CTI TAC recommendation is to use Linux Foundation IT services for
> +core infrastructure. The LF IT team already supports many of the same services
> +for the Linux kernel and at scale. The migration would involve moving services
> +from Sourceware.org to LF IT servers.  We continue to be thankful and
> +appreciative of the time spent by Sourceware.org volunteers in support of the
> +current services.
> +
> +What is the urgency vs what is the timeline?
> +""""""""""""""""""""""""""""""""""""""""""""
> +The GNU Toolchain community should be making consistent forward progress
> +to improve our infrastructure and cybersecurity position.  Showing progress is
> +important for the ecosystem to trust us as a secure and critical part of the
> +software supply chain. We should not wait until there are Cybersecurity
> +regulations that are beyond our ability to comply with as the FOSS ecosystem of
> +tooling and infrastructure. Projects of similar scope and importance have been
> +deploying significant resources for the use of the development community.
> +
> +Sourceware volunteers have fielded requests and organized volunteer efforts that have worked well. Does LF allow volunteers to administer the servers together with them? Have they in the past?
> +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> +The CTI TAC is the point of contact for volunteers.  CTI can fund multiple
> +activities, by multiple entities, and the way in which the volunteers engage
> +may differ between them.
> +
> +How does this project relate to the GNU Project or the Free Software Foundation (FSF)?
> +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> +Many of the GNU Toolchain components are a part of the GNU Project, and
> +contribute to the development of the GNU system.  The FSF supports the GNU
> +Project, and in turn supports the GNU Toolchain. The GNU Toolchain community
> +works with the FSF via a `working together fund
> +<https://www.fsf.org/working-together/fund>`_ to support the development of the
> +GNU Toolchain directly.  The Core Toolchain Infrastructure project is distinct
> +from the GNU Project and the FSF.
> +
> +How does this project relate to the `GCC Compile Farm Project <https://gcc.gnu.org/wiki/CompileFarm>`_?
> +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> +The GCC Compiler Farm is a unique resource for the GNU Toolchain and
> +provides interactive systems for developers to manually test on a wide variety
> +of hardware and software configurations. This is not exactly the same set of
> +requirements that the community might have for securing a supply chain, or
> +using modern CI/CD workflows.
> +
> +How will the composition of the Core Toolchain infrastructure project reflect the communities it supports?
> +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> +Members of the GNU Toolchain community will always be invited to become members
> +of the technical advisory council for the project.
> +
> +What is the composition of the project steering committee?
> +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> +The project steering committee will be composed of sponsoring members of
> +the Linux Foundation and members of the GNU Toolchain community.
> +
> +What does the project TAC do?
> +"""""""""""""""""""""""""""""
> +The TAC takes input from the GNU Toolchain community and works with the
> +members to, implement, and resolve prioritized requirements.
> +
> +Is the GNU Toolchain development model going to change?
> +"""""""""""""""""""""""""""""""""""""""""""""""""""""""
> +No. The aim of the project is to provide additional infrastructure for
> +the community that is being made available to support the GNU Toolchain. All
> +development changes will always be driven by the community.
> +
> +Is `Sourceware <https://sourceware.org/>`_ going to be deprecated?
> +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> +The GNU Toolchain Infrastructure project is distinct from Sourceware.
> +The intent is to move critical infrastructure from Sourceware to the Core
> +Toolchain Infrastructure project to provide paid services.
> +
> +Who can use the new infrastructure?
> +"""""""""""""""""""""""""""""""""""
> +That depends on the requirements given by the GNU Toolchain community.
> +The requirements from the community are input to the steering committee, and so
> +the answer depends largely on exactly what was the intended purpose.
> +
> +What can the new infrastructure be used for?
> +""""""""""""""""""""""""""""""""""""""""""""
> +That depends on the requirements given by the GNU Toolchain community.
> +The requirements from the community are input to the steering committee, and so
> +the answer depends largely on exactly what was the intended purpose.
> +
> +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/>`_.
>  
>  -----------------
>  

-- 
Cheers,
Carlos.

Re: [PATCH 1/5] projects/glibc: slightly adjust the structure

[Siddhesh Poyarekar]

On 2024-03-07 15:22, Carlos O'Donell wrote:
>>   * Mailing lists
>> @@ -81,7 +88,7 @@ The following is the suggested list of services to be migrated (with notes):
>>     * Isolate BBB from other services.
>>   
>>   The current list of glibc services were put together as part of the
>> -CTI TAC `glibc service enumeration <./enum>`_.
>> +CTI TAC `glibc service enumeration <./enum.html>`_.
> 
> I don't think this is correct.
> 
> I agree the website link is broken, but it has to be a cross-document reference
> that works when generated as html (rather than assume html).
> 

Oops, looks like it just needed a :doc: prefix and not the .html suffix. 
  OK if I fix this up and add your R-b?

Thanks,
Sid

Re: [PATCH 1/5] projects/glibc: slightly adjust the structure

[Carlos O'Donell]

On 3/7/24 15:38, Siddhesh Poyarekar wrote:
> On 2024-03-07 15:22, Carlos O'Donell wrote:
>>> * Mailing lists @@ -81,7 +88,7 @@ The following is the suggested
>>> list of services to be migrated (with notes): * Isolate BBB from
>>> other services. The current list of glibc services were put
>>> together as part of the -CTI TAC `glibc service enumeration
>>> <./enum>`_. +CTI TAC `glibc service enumeration <./enum.html>`_.
>> 
>> I don't think this is correct.
>> 
>> I agree the website link is broken, but it has to be a
>> cross-document reference that works when generated as html (rather
>> than assume html).
>> 
> 
> Oops, looks like it just needed a :doc: prefix and not the .html
> suffix.  OK if I fix this up and add your R-b?

Yes. You have my R-b for all cases where you fix this in a non-html-specific way
where I otherwise rejected it.

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

-- 
Cheers,
Carlos.

Re: [PATCH 2/5] Add a toplevel README

[Siddhesh Poyarekar]

On 2024-03-07 15:25, Carlos O'Donell wrote:
> On 3/7/24 14:30, Siddhesh Poyarekar wrote:
>> Add basic instructions to allow one to test and later submit changes for
>> review and inclusion.
>>
>> Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
> 
> Content looks good though, you can keep my RB and push so long as you call it README.md.
> 
> Reviewed-by: Carlos O'Donell <carlos@redhat.com>

I'm calling it README.rst instead, since it's more rst than md.  Is that 
fine?

Thanks,
Sid

Re: [PATCH 2/5] Add a toplevel README

[Carlos O'Donell]

On 3/7/24 16:00, Siddhesh Poyarekar wrote:
> On 2024-03-07 15:25, Carlos O'Donell wrote:
>> On 3/7/24 14:30, Siddhesh Poyarekar wrote:
>>> Add basic instructions to allow one to test and later submit changes for
>>> review and inclusion.
>>>
>>> Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
>>
>> Content looks good though, you can keep my RB and push so long as you call it README.md.
>>
>> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
> 
> I'm calling it README.rst instead, since it's more rst than md.  Is that fine?

No. The README.md is intended to be rendered by forges that mirror the repo
and should be in markdown regardless of what we use for the project itself
(rST). For example Github only renders markdown and a README.rst would not
be rendered there, we'd need to use pandoc to sync an update of the same
file but converted.

Suggestion: Call it README.md; and keep it in markdown.

-- 
Cheers,
Carlos.

Re: [PATCH 2/5] Add a toplevel README

[Siddhesh Poyarekar]

On 2024-03-07 16:06, Carlos O'Donell wrote:
> On 3/7/24 16:00, Siddhesh Poyarekar wrote:
>> On 2024-03-07 15:25, Carlos O'Donell wrote:
>>> On 3/7/24 14:30, Siddhesh Poyarekar wrote:
>>>> Add basic instructions to allow one to test and later submit changes for
>>>> review and inclusion.
>>>>
>>>> Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
>>>
>>> Content looks good though, you can keep my RB and push so long as you call it README.md.
>>>
>>> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
>>
>> I'm calling it README.rst instead, since it's more rst than md.  Is that fine?
> 
> No. The README.md is intended to be rendered by forges that mirror the repo
> and should be in markdown regardless of what we use for the project itself
> (rST). For example Github only renders markdown and a README.rst would not
> be rendered there, we'd need to use pandoc to sync an update of the same
> file but converted.
> 
> Suggestion: Call it README.md; and keep it in markdown.
> 

Ack, I changed the name (and format, e.g. # for h1, `` for code blocks, 
etc.) to markdown and pushed this.

Sid