Merge pull request #2 from riscv-admin/Clean-up-pre-commit

clean up precommit

Makefile

@@ -55,7 +55,7 @@ OPTIONS := --trace \
            $(XTRA_ADOC_OPTS) \
 		   -D build \
            --failure-level=ERROR
-REQUIRES := --require=asciidoctor-bibtex 
+REQUIRES := --require=asciidoctor-bibtex
 
 .PHONY: all build clean build-container build-no-container build-docs
 

src/act.adoc

@@ -117,12 +117,10 @@ implemented,
 
 * Any optional feature and configuration parameters allowed by the
 architecture that are used, defined by listing a YAML formatted file
-using the schema defined by the riscv-config format (see
-https://riscv-config.readthedocs.io/en/latest/overview.html), 
+using the schema defined by the riscv-config format (see https://riscv-config.readthedocs.io/en/latest/overview.html),
 
 * The vendor and implementation IDs that the DUT will report in those
-respective CSRs (should be in the YAML feature/config file),
-
+respective CSRs (should be in the YAML feature/config file),+
 NOTE: these may be zero if unimplemented
 
 * Name, commit hash, and either version tags or git commit date (in ISO
@@ -331,4 +329,3 @@ be only supported through vendor efforts and not through RISC-V.
 
 Any escalation should occur to the CTO who may choose to resolve the
 issue, or escalate to the TSC or the CEO or the BOD.
-

src/architecture_review.adoc

@@ -21,7 +21,7 @@
 
 === Rationale
 
-We need to produce robust extensions that are consistent with the ratified RISC-V specifications and RISC-V overall strategy. 
+We need to produce robust extensions that are consistent with the ratified RISC-V specifications and RISC-V overall strategy.
 
 We also need to coordinate assignments of opcode encodings, mnemonics,
 CSRs, etc so we have a consistent set of conventions across extensions,
@@ -89,14 +89,15 @@ In the process of developing the RISC-V Specification, Architecture
 Review (AR) serves a pivotal function. This review can occur at various
 stages: Planning, Development, Freeze, and Ratification-Ready.
 
-During the Planning and Development phases, AR functions primarily as a 
-consultative activity, offering requested guidance on possible architectural 
-choices and suggestions for improvement. However, the Architecture Review conducted 
-during the Freeze stage is particularly important and mandatory, as it determines 
-whether the specification is genuinely prepared to advance or if modifications 
-and enhancements are needed. Lastly, AR is required during the Ratification-Ready 
-phase if the specification text has undergone any significant changes (i.e. past 
-simple typo corrections, formatting corrections, and very simple clarifications).
+During the Planning and Development phases, AR functions primarily as a
+consultative activity, offering requested guidance on possible architectural
+choices and suggestions for improvement. However, the Architecture Review
+conducted during the Freeze stage is particularly important and mandatory, as
+it determines whether the specification is genuinely prepared to advance or if
+modifications and enhancements are needed. Lastly, AR is required during the
+Ratification-Ready phase if the specification text has undergone any significant
+changes (i.e. past simple typo corrections, formatting corrections, and very
+simple clarifications).
 
 === Exception handling
 

src/ccm_guest_policy.adoc

@@ -73,4 +73,3 @@ conversation. Guests may not request this.
 
 === Transition to start using policy
 Immediate
-

src/chairs_best_practices.adoc

@@ -17,8 +17,7 @@
 
 |1.3 |2022-02-18 |Reference Encumbered information policy for new Chairs |Jeff Scheel
 
-|1.2 |2021-09-24 |Added information for new Chairs. Simplified handling 
-of inappropriate behavior. |Jeff Scheel
+|1.2 |2021-09-24 |Added information for new Chairs. Simplified handling of inappropriate behavior. |Jeff Scheel
 
 |===
 
@@ -230,4 +229,3 @@ Active as of now as it is only advice
 === Exceptions
 
 Not applicable
-

src/dev_partner.adoc

@@ -13,7 +13,7 @@ public review and ratification +
 |===
 |Ver |Date |Details |Name(s)
 
-|1.1 |2021-02-02 
+|1.1 |2021-02-02
 
 a| Updates:
 
@@ -127,4 +127,3 @@ Not applicable
 === Transition to start using policy
 
 Immediately
-

src/ecosystem_labs.adoc

@@ -139,4 +139,3 @@ email to [email protected].
 
 === Transition to start using policy +
 Immediately upon approval
-

src/encumbered_info.adoc

@@ -77,4 +77,3 @@ modifications before approval).
 
 === Exceptions +
 None allowed.
-

src/fast_track_extension.adoc

@@ -171,7 +171,7 @@ enters the standard 30-day public review process. This is announced via
 email to `isa-dev' and to the `tech' email list. +
 . Approval by TSC +
 * All comments from the public review must be addressed. +
-* The proposer, the two chairs of the relevant Horizontal or ISA 
+* The proposer, the two chairs of the relevant Horizontal or ISA
 Committee, and two others outside the proposer’s organization must agree
 to push for approval and then present such a motion to the
 `tech-announce' email list ([email protected]) - with a

src/github_administration.adoc

@@ -187,4 +187,3 @@ changes.
 === Exception Handling
 
 The CTO is the escalation path for all policy issues, with the authority to resolve them or, if necessary, escalate further to the TSC or the BOD.
-

src/gnu_toolchain_signoff_criteria.adoc

@@ -64,4 +64,3 @@ Immediate on approval
 . Identify at least two specific people from TSC to review the policy before it is approved. +
 . Have the TSC chair and CTO review the proposal. +
 . If approved, communicate to all task/sig groups commissioning GNU tool chain work. +
-

src/groups_chairs.adoc

@@ -117,7 +117,7 @@ Interest Groups, and Task Groups.
 The Technical Steering Committee requires notification of some decisions that these groups are making in order to provide appropriate oversight. The TSC reserves the right to review and adjust decisions made by any of the working groups or committees. Each policy will call out, at the top of the document, if the TSC requires notification of any process detailed in a RISC-V policy document. See the TSC Required Notification Statement below for the full text.
 
 [IMPORTANT]
-*TSC Required Notification Statement:* 
+*TSC Required Notification Statement:*
 This document contains delegated tasks from the Technical Steering
 Committee (TSC). The TSC requires notification of these delegated tasks
 (highlighted in red) and reserves the right to review and adjust at any
@@ -521,4 +521,3 @@ the CTO. the CTO may further escalate to TSC or the BOD.
 Members who feel their escalation is not being addressed appropriately
 should send email to [email protected]. Members should try to work through
 their HC or IC first, if possible, before sending email.
-

src/intro.adoc

@@ -49,4 +49,3 @@ Policies in this section are no longer in use by RISC-V:
 * ACT Requirements for Privileged 1.11 Specification +
 * Non-ISA Definition of Done +
 * SAIL Requirements for Privileged 1.11 Extensions +
-

src/isa_nonisa.adoc

@@ -118,4 +118,3 @@ adhere to this policy. +
 by 2021-07-01. +
 . Any non-ISA items that were already ratified will be considered
 approved.
-

src/joint_working_groups.adoc

@@ -95,4 +95,3 @@ Escalations get sent to the executives to resolve.
 === Transition to start using policy
 
 Effective immediately
-

src/llvm_toolchain_signoff.adoc

@@ -120,4 +120,3 @@ by reviewers by two weeks). +
 . Identify at least two specific people from TSC to review the policy
 before it is approved. +
 . Have the TSC chair and CTO review the proposal.
-

src/nonisa_definition_of_done.adoc

@@ -11,9 +11,9 @@
 |===
 |Ver |Date |Details |Name(s)
 
-|1.2 |2021-10-05 |elaborate on custom plans | 
-|1.1 |2021-09-28 |require sign off for non isa specs | 
-|1.0 |2021-08-16 |who approves customized portions of Non-ISA DoD | 
+|1.2 |2021-10-05 |elaborate on custom plans |
+|1.1 |2021-09-28 |require sign off for non isa specs |
+|1.0 |2021-08-16 |who approves customized portions of Non-ISA DoD |
 |0.1 |2021-03-22 |Original draft |Gajinder Panesar, Arun Thomas and Greg Favor +
 |===
 
@@ -115,5 +115,4 @@ Freeze milestone.
 
 === Exception handling
 
-Any Task Group wanting an exception from any part of this policy must get written approval from the Chairs. The exception should list the explicit rows that need to be waived, the cause for needing the waiver, and when they will get done. To set expectations:  it is likely Chairs will only grant waivers for items in the earlier part of the DoD and unlikely that Chairs will grant permanent waivers at all.  
-
+Any Task Group wanting an exception from any part of this policy must get written approval from the Chairs. The exception should list the explicit rows that need to be waived, the cause for needing the waiver, and when they will get done. To set expectations:  it is likely Chairs will only grant waivers for items in the earlier part of the DoD and unlikely that Chairs will grant permanent waivers at all.

src/os_hypervisor_requirements.adoc

@@ -118,4 +118,3 @@ consequently, been addressed)
 
 === Transition to start using policy +
 Immediate
-

src/platforms.adoc

@@ -388,4 +388,3 @@ Compatibility test.* +
 specifications and provide additional functionality, as long as they
 remain compatible* (i.e., they may not implement incompatible features
 unless these are disabled by default).
-

src/policy.adoc

@@ -49,4 +49,3 @@ its exception handling.
 
 === Transition to start using policy +
 Immediate
-

src/profiles.adoc

@@ -129,7 +129,7 @@ don’t conflict in any way with required or optional standard extensions.
 
 === Transition to start using policy
 
-This will be the acting policy until approved (possibly with modifications before approval). 
+This will be the acting policy until approved (possibly with modifications before approval).
 
 Upon approval of this policy, implementations must adhere to the policy.
 Existing branding must transition within 12 months unless an exception
@@ -141,4 +141,3 @@ described in this policy immediately.
 === Exceptions
 
 Profile naming and versioning exceptions must be approved by the TSC.
-

src/question_response.adoc

@@ -1,5 +1,5 @@
 [[question_response]]
-== Question Response 
+== Question Response
 
 *Version:* 1.1 +
 *One line description:* Answer member questions reliably within a SLA and
@@ -45,12 +45,12 @@ github in the README.
 The chairs of those groups should at least respond to emails within
 24-48 hours M-F except on holidays (i.e. business days).
 
-Responses can be one of three things: 
+Responses can be one of three things:
 
 . answer and resolve the question, +
 . notify the requester that the question belongs to another
 group and CC that group who in turn should respond in accordance with
-this policy or 
+this policy or
 . acknowledge receipt of the question and tell the
 responder when they should expect an answer by the chair or someone else
 (it may take time to get someone to answer because they don’t have the

src/ratification.adoc

@@ -286,4 +286,3 @@ ratified specification.
 
 Any exceptions get escalated to the CTO who may choose to resolve the
 issue, or escalate to the TSC or the CEO or the BOD.
-

src/rationale.adoc

@@ -103,4 +103,3 @@ hardship along with a recommendation on how, if, and when to answer
 them. Alternatively they can escalate to TSC and should include some
 idea about what the TG thinks might have been useful had they had this
 policy in a more convenient time period.
-

src/technical_voting.adoc

@@ -84,4 +84,3 @@ RISC-V CTO directly.
 === Transition to start using policy
 
 Immediate
-

src/universes.adoc

@@ -98,4 +98,3 @@ email to [email protected].
 Cheri will be the test universe and we will not create any others until
 we agree that the Cheri universe is successful and the universe paradigm
 is appropriate.
-