From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) by mx.groups.io with SMTP id smtpd.web12.51566.1597085079093464681 for ; Mon, 10 Aug 2020 11:44:40 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=Yba3fNaR; spf=pass (domain: apple.com, ip: 17.171.2.60, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 07AIghfW051331; Mon, 10 Aug 2020 11:44:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=qrTvWqODIzyB+llJHDj/smKBH5ZV8Vfj7XMZ6OhZUZg=; b=Yba3fNaRGvkCL6IuKwBv5kppDq6h6nr/+6+9v5mQFN4F1z8WEuhXwHDNpvhG0kJCTYAW S2lNCv8PeRjHQmUV+itj/5tr4cySUI74j++Pjg2SDzUvqRQZxbSYJ+zdOHob9HnhLciS 9S4Hya5149I10Rg38l8bBMEKFH641FAiQF3Ao+CwKy4i8YBP5DxaOuOdSR28l93YsHoc 0oKN/2fvRCA+JMDfD1yIMKDM+UKyY5x5GHec26rovYku12kjgvjnNd18x6L/uHJKsxdD zZ+KDqvkG4ZBV7eKuBTjJCZoS4MePfcRrEpHp5tS5+ltlytPQCdmTio0gNnWWfGke3Lm qQ== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 32stqgx132-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 10 Aug 2020 11:44:31 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QEV001YM2Q7E5C0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Mon, 10 Aug 2020 11:44:31 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QEV00R002PF7700@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 10 Aug 2020 11:44:31 -0700 (PDT) X-Va-A: X-Va-T-CD: 74bd2484bc68e36b430e8e57a1f32e6b X-Va-E-CD: 589d3aec1e19f7209af468d40c5948d2 X-Va-R-CD: 717ca627df22c59bca7fd64159b3dff6 X-Va-CD: 0 X-Va-ID: 9802da74-fef4-4560-99b9-a64ebaa2722d X-V-A: X-V-T-CD: 74bd2484bc68e36b430e8e57a1f32e6b X-V-E-CD: 589d3aec1e19f7209af468d40c5948d2 X-V-R-CD: 717ca627df22c59bca7fd64159b3dff6 X-V-CD: 0 X-V-ID: 7b4bd614-99b3-4e6b-87f0-cd336c7226de X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-08-10_16:2020-08-06,2020-08-10 signatures=0 Received: from [17.235.18.161] (unknown [17.235.18.161]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QEV00K5B2Q40300@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 10 Aug 2020 11:44:30 -0700 (PDT) From: "Andrew Fish" Message-id: <60D65DD9-4DA6-4958-8DCC-505398001324@apple.com> MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [edk2-devel] [Wiki][Patch V2] Add EDK II Code First Process Wiki Page Date: Mon, 10 Aug 2020 11:44:28 -0700 In-reply-to: Cc: "devel@edk2.groups.io" , Mike Kinney , "rfc@edk2.groups.io" , Laszlo Ersek , Leif Lindholm To: Samer El-Haj-Mahmoud References: <20200808010448.39460-1-michael.d.kinney@intel.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-08-10_16:2020-08-06,2020-08-10 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_72CF44A8-FB35-456C-8347-20299B4715F1" --Apple-Mail=_72CF44A8-FB35-456C-8347-20299B4715F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 10, 2020, at 11:36 AM, Samer El-Haj-Mahmoud wrote: >=20 > Mike, >=20 > Looks good as a starting point! >=20 > Acked-by: Samer El-Haj-Mahmoud > >=20 >=20 > I do have a few questions on this sentence: "Specification text changes= are held within the affected source repository, using the GitHub flavor of= markdown, in a file (or split across several files) with .md suffix." >=20 > - For TianoCore, is the "affected source repository" this sentence is re= ferring to edk2-staging, or edk2? >=20 > - If the proposed specification and associated code starts in a branch i= n edk2-staging respiratory, when does it get accepted into edk2/edk2-platfo= rms? Is it when the proposed specification change reaches a certain status = (such as "accepted by industry standard forum"), or when the formal specifi= cation (with that proposed change) is published by the UEFI Forum ? >=20 Samer, While in the =E2=80=9Ccode 1st state=E2=80=9D there are BZ# prefixes to ty= pes and globals. So when the code ends up in the specification the =E2=80= =9Ccode 1st=E2=80=9D branch is going to need to get cleaned up for naming,= and I assume we could remove the MD files before a patch is submitted to t= he edk2.=20 We made extra work for ourselves, but we wanted it to be clear what was wo= rk in progress.=20 Thanks, Andrew Fish=20 > - Any guidance on the specification text md file(s) names (and location)= within the repository? >=20 > - If the change includes some graphics, is there any guidance on inclusi= on of the graphics files in the repository? >=20 > Thanks, > --Samer >=20 >=20 >=20 >> -----Original Message----- >> From: devel@edk2.groups.io > On Behalf Of Michael >> D Kinney via groups.io >> Sent: Friday, August 7, 2020 9:07 PM >> To: devel@edk2.groups.io ; Kinney, Michael= D >> >; rfc@e= dk2.groups.io >> Cc: Laszlo Ersek >; Andrew= Fish >; >> Leif Lindholm > >> Subject: Re: [edk2-devel] [Wiki][Patch V2] Add EDK II Code First Proces= s >> Wiki Page >>=20 >> A version of this Wiki page is also provided here for review: >>=20 >> https://github.com/mdkinney/edk2/wiki/EDK-II-Code-First-Process >>=20 >> Mike >>=20 >>> -----Original Message----- >>> From: devel@edk2.groups.io On Behalf Of >> Michael >>> D Kinney >>> Sent: Friday, August 7, 2020 6:05 PM >>> To: devel@edk2.groups.io >>> Cc: Laszlo Ersek ; Andrew Fish ; >>> Leif Lindholm >>> Subject: [edk2-devel] [Wiki][Patch V2] Add EDK II Code First Process >>> Wiki Page >>>=20 >>> Based on the following RFC: >>>=20 >>> https://edk2.groups.io/g/rfc/message/258 >>>=20 >>> Additional updates: >>> * Add examples of all specifications currently maintained by >>> the UEFI Forums. >>> * Added specification change template using a CC-BY-4.0 license. >>> * Add source code example for an enum value >>> * Minor grammar updates to change from an RFC proposal to an >>> active process. >>>=20 >>> Cc: Laszlo Ersek >>> Cc: Andrew Fish >>> Cc: Leif Lindholm >>> Signed-off-by: Michael D Kinney >>> --- >>> EDK-II-Code-First-Process.md | 182 >>> +++++++++++++++++++++++++++++++++++ >>> 1 file changed, 182 insertions(+) >>> create mode 100644 EDK-II-Code-First-Process.md >>>=20 >>> diff --git a/EDK-II-Code-First-Process.md >>> b/EDK-II-Code-First-Process.md new file mode 100644 index >>> 0000000..d5c938e >>> --- /dev/null >>> +++ b/EDK-II-Code-First-Process.md >>> @@ -0,0 +1,182 @@ >>> +The EDK II Code First Process is a process by which new features can >>> +be added to UEFI Forum specifications after first having been >>> +designed and prototyped in the open. >>> + >>> +This process lets changes and the development of new features happen >>> +in the open, without violating the UEFI forum bylaws which prevent >>> +publication of code for in-draft features/changes. >>> + >>> +The process does not in fact change the UEFI bylaws - the change is >>> +that the development (of both specification and code) happens in the >>> +open. The resulting specification update is then submitted to the >>> +appropriate working group as an Engineering Change Request (ECR), and >>> +voted on. For the UEFI Forum, this is a change in workflow, not a cha= nge >> in process. >>> + >>> +ECRs are tracked in a UEFI Forum Mantis instance, access restricted >>> +to UEFI Forum Members. TianoCore enables this new process by >>> +providing areas on [TianoCore >>> +Bugzilla](https://bugzilla.tianocore.org) to track both specification >>> +updates and reference implementations and new repositories under >> [TianoCore GitHub](https://github.com/tianocore) dedicated to hold "cod= e >> first". >>> + >>> +# TianoCore Bugzilla >>> + >>> +[TianoCore Bugzilla](bugzilla.tianocore.org) has a product categories >>> +for >>> + * ACPI Specification >>> + * UEFI Shell Specification >>> + * UEFI Platform Initialization Distribution Packaging Specification >>> + * UEFI Platform Initialization Specification Specification >>> + * UEFI Specification >>> + >>> +Each product category has separate components for >>> + * Specification >>> + * Reference implementation >>> + >>> +# TianoCore GitHub >>> + >>> +Reference implementations targeting the EDK II open source project >>> +are held in branches in the >>> +[edk2-staging](https://github.com/tianocore/edk2-staging) >>> +repository. >>> + >>> +Additional repositories for implementing reference features in >>> +additional open source projects can be added in the future, as requir= ed. >>> + >>> +Specification text changes are held within the affected source >>> +repository, using the GitHub flavor of markdown, in a file (or split >>> +across several files) with .md suffix. Multiple files are required >>> +if changes impact multiple specifications or if the specification is >>> +large and is easier to maintain if the changes are split across multi= ple >> files. >>> + >>> +* NOTE: This one may break down where we have a specification change >>> +affecting >>> + multiple specifications, but at that point we can track it with >>> +multiple >>> + TianoCore Bugzilla entries. >>> + >>> +## Specification Text Template >>> + >>> +The following is a template of specification text changes using the >>> +GitHub flavor of markdown. The title and complete description of the >>> +specification changes must be provided in the specification text >>> +along with the name and version of the specification the change >>> +applies. The `Status` of the specification change always starts in >>> +the `Draft` state and is updated based on feedback from the industry >>> +standard forums. The contents of the specification text are required >>> +to use the [Creative Commons Attribution 4.0 >>> +International](https://spdx.org/licenses/CC-BY-4.0.html) >>> +license using a `SPDX-License-Identifier` statement. >>> + >>> +``` >>> +# Title: [Must be Filled In] >>> + >>> +# Status: [Status] >>> + >>> +[Status] must be one of the following: >>> +* Draft >>> +* Submitted to industry standard forum >>> +* Accepted by industry standard forum >>> +* Accepted by industry standard forum with modifications >>> +* Rejected by industry standard forum >>> + >>> +# Document: [Title and Version] >>> + >>> +Here are some examples of [Title and Version]: >>> +* UEFI Specification Version 2.8 >>> +* ACPI Specification Version 6.3 >>> +* UEFI Shell Specification Version 2.2 >>> +* UEFI Platform Initialization Specification Version 1.7 >>> +* UEFI Platform Initialization Distribution Packaging Specification >>> +Version 1.1 >>> + >>> +# License >>> + >>> +SPDX-License-Identifier: CC-BY-4.0 >>> + >>> +# Submitter: [TianoCore Community](https://www.tianocore.org) >>> + >>> +# Summary of the change >>> + >>> +Required Section >>> + >>> +# Benefits of the change >>> + >>> +Required Section >>> + >>> +# Impact of the change >>> + >>> +Required Section >>> + >>> +# Detailed description of the change [normative updates] >>> + >>> +Required Section >>> + >>> +# Special Instructions >>> + >>> +Optional Section >>> +``` >>> + >>> +# Intended workflow >>> + >>> +The entity initiating a specification change enters a Bugzilla in the >>> +appropriate area of [TianoCore Bugzilla](bugzilla.tianocore.org). >>> +This entry contains the outline of the change, and the full initial d= raft >> text is attached. >>> + >>> +If multiple specification updates are interdependent, especially if >>> +between different specifications, then multiple Bugzilla entries shou= ld be >> created. >>> +These Bugzilla entries *must* be linked together with dependencies. >>> + >>> +After the Bugzillas have been created, new branches should be created >>> +in the relevant repositories for each Bugzilla. The branch names >>> +must use the following format where #### is the Bugzilla ID and >>> + is an optional description of the change. >>> + >>> + BZ####- >>> + >>> +If multiple Bugzilla entries must coexist on a single branch, one of >>> +them is designated the _top-level_, with dependencies properly >>> +tracked. That Bugzilla is be the one naming the branch. >>> + >>> +# Source Code >>> + >>> +In order to ensure draft code does not accidentally leak into >>> +production use, and to signify when the changeover from draft to >>> +final happens, *all* new or modified[1] identifiers must be prefixed = with >> the relevant BZ#### identifiers. >>> + >>> +* [1] Modified in a non-backwards-compatible way. If, for example, a >> statically >>> + sized array is grown - this does not need to be prefixed. But a= tag in a >>> + comment would be *highly* recommended. >>> + >>> +## File names >>> + >>> +New public header files require the prefix (i.e. >> `Bz1234MyNewProtocol.h`). >>> +Private header files do not need the prefix. >>> + >>> +## Contents >>> + >>> +The tagging must follow the coding style used by each affected code >> base. >>> +Examples: >>> + >>> +| Released in spec | Draft version in tree | Comment | >>> +| --- | --- | --- | >>> +| `FunctionName` | `Bz1234FunctionName` | | >>> +| `HEADER_MACRO` | `BZ1234_HEADER_MACRO` | | >>> + >>> +For data structures or enums, any new or non-backwards-compatible >>> +structs or fields require a prefix. As above, growing an existing >>> +array in an existing struct requires no prefix. >>> + >>> +| Released in spec | Draft version in tree | Comment = | >>> +| --- | --- | --- = | >>> +| `typedef SOME_STRUCT` | `BZ1234_SOME_STRUCT` | Typedef only [2] >> | >>> +| `StructField` | `Bz1234StructField` | In existing struct[= 3] | >>> +| `typedef SOME_ENUM` | `BZ1234_SOME_ENUM` | Typedef only [2] >> | >>> +| `EnumValue` | `BzEnumValue` | In existing enum[3]= | >>> + >>> +* [2] If the struct or enum definition is separate from the typedef i= n the >> public >>> + header, the definition does not need the prefix. >>> +* [3] Individual fields in newly added struct or enum do not need pre= fix, >> the >>> + struct or enum already carried the prefix. >>> + >>> +Variable prefixes indicating global scope ('g' or 'm') go before the = BZ >> prefix. >>> + >>> +| Released in spec | Draft version in tree | Comment | >>> +| --- | --- | --- | >>> +| `gSomeGuid` | `gBz1234SomeGuid` | | >>> + >>> +Local identifiers, including module-global ones (m-prefixed) do not >>> +require a BZ prefix. >>> -- >>> 2.21.0.windows.1 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. --Apple-Mail=_72CF44A8-FB35-456C-8347-20299B4715F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 10, 2= 020, at 11:36 AM, Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com> wrote:
Mike,

Looks good as a starting point!

Acked-by: Sam= er El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.co= m>


I d= o have a few questions on this sentence:  "Specification text changes = are held within the affected source repository, using the GitHub flavor of = markdown, in a file (or split across several files) with .md suffix."

- For TianoCore, is the "affected source repository" this sen= tence is referring to edk2-staging, or edk2?

- If the propo= sed specification and associated code starts in a branch in edk2-staging re= spiratory, when does it get accepted into edk2/edk2-platforms? Is it when t= he proposed specification change reaches a certain status (such as "accepte= d by industry standard forum"), or when the formal specification (with that= proposed change) is published by the UEFI Forum ?


Samer,

While in the =E2=80=9Ccode 1st state=E2=80=9D there are BZ# prefixes to = types and globals. So when the code ends up in the specification the =E2=80= = =9Ccode 1st=E2=80=9D branch is going to need to get cleaned up for naming,= and I assume we could remove the MD files before a patch is submitted to t= he edk2. 

We made extra work for o= urselves, but we wanted it to be clear what was work in progress. 

Thanks,

Andrew Fish 

- Any guidance on the specification text md file(s= ) names (and location) within the repository?

- If the chan= ge includes some graphics, is there any guidance on inclusion of the graphi= cs files in the repository?
Thanks,
--Samer



-----O= riginal Message-----
From: devel@ed= k2.groups.io <devel@edk2.groups.io>= On Behalf Of Michael
D Kinney via groups.io<= /a>
Sent: Friday, August 7, 2020 9:07 PM
To: devel@edk2.groups.io; Kinney, Michael D
<michael= .d.kinney@intel.com>; rfc@edk2.groups.io=
Cc: Laszlo Ersek <lersek@redhat.com>; Andrew Fish <afish@apple.com>;
Leif Lindholm= <leif@nuviainc.com&= gt;
Subject: Re: [edk2-devel] [Wiki][Patch V2] Add EDK II Cod= e First Process
Wiki Page

A vers= ion of this Wiki page is also provided here for review:

https://github.com/mdkinney/edk2/wiki/EDK-II-Code-Fir= st-Process

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of=
Michael
D Kinney
Sent: Friday, August 7, 2020 6:05 PM
To: devel@edk2.groups.io
Cc: Laszlo Ersek <lers= ek@redhat.com>; Andrew Fish <afish@apple.com>;
Leif = Lindholm <leif@nuviainc.com>
Subject: [edk2-devel] [Wik= i][Patch V2] Add EDK II Code First Process
Wiki Page

Based on the following RFC:

   https://edk2.groups.io/g/rfc/message/258

Additional updates:
* Add examples of a= ll specifications currently maintained by
 the UEFI Foru= ms.
* Added specification change template using a CC-BY-4.0 l= icense.
* Add source code example for an enum value
* Minor grammar updates to change from an RFC proposal to an
 active process.

Cc: Laszlo Ersek = <lersek@redhat.com>
Cc: Andrew Fish <afish@apple.com= >
Cc: Leif Lindholm <leif@nuviainc.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
---
EDK-II-Code-First-Process.md | 182
= +++++++++++++++++++++++++++++++++++
1 file changed, 182 inser= tions(+)
create mode 100644 EDK-II-Code-First-Process.md

diff --git a/EDK-II-Code-First-Process.md
b/EDK-II-Code-First-Process.md new file mode 100644 index
0000000..d5c938e
--- /dev/null
+++ b/EDK= -II-Code-First-Process.md
@@ -0,0 +1,182 @@
+Th= e EDK II Code First Process is a process by which new features can
+be added to UEFI Forum specifications after first having been
+designed and prototyped in the open.
+
+This process lets changes and the development of new features happen
+in the open, without violating the UEFI forum bylaws which prev= ent
+publication of code for in-draft features/changes.
+
+The process does not in fact change the UEFI byla= ws - the change is
+that the development (of both specificati= on and code) happens in the
+open. The resulting specificatio= n update is then submitted to the
+appropriate working group = as an Engineering Change Request (ECR), and
+voted on. For th= e UEFI Forum, this is a change in workflow, not a change
in process.
++ECRs are tracked in a UEFI Forum Mantis instance, access rest= ricted
+to UEFI Forum Members. TianoCore enables this new pro= cess by
+providing areas on [TianoCore
+Bugzill= a](https://bugzilla.tianocore.org) to track both specification
+updates and reference implementations and new repositories under
[TianoCore GitHub](https://github.com/tianocore) dedica= ted to hold "code
first".
+
+# TianoCore Bugzilla
+
+[TianoCore Bugzilla](bugzilla.tianocore.org) has a product catego= ries
+for
+  * ACPI Specification
+  * UEFI Shell Specification
+  * UEFI Plat= form Initialization Distribution Packaging Specification
+ &n= bsp;* UEFI Platform Initialization Specification Specification
+  * UEFI Specification
+
+Each product = category has separate components for
+  * Specification<= br class=3D"">+  * Reference implementation
+
+# TianoCore GitHub
+
+Reference impleme= ntations targeting the EDK II open source project
+are held i= n branches in the
+[edk2-staging](https://github.com/tianocor= e/edk2-staging)
+repository.
+
+A= dditional repositories for implementing reference features in
+additional open source projects can be added in the future, as required.<= br class=3D"">+
+Specification text changes are held within t= he affected source
+repository, using the GitHub flavor of ma= rkdown, in a file (or split
+across several files) with .md s= uffix.  Multiple files are required
+if changes impact m= ultiple specifications or if the specification is
+large and = is easier to maintain if the changes are split across multiple
files.
+<= br class=3D"">+* NOTE: This one may break down where we have a specificatio= n change
+affecting
+  multiple specificat= ions, but at that point we can track it with
+multiple
+  TianoCore Bugzilla entries.
+
+= ## Specification Text Template
+
+The following= is a template of specification text changes using the
+GitHu= b flavor of markdown.  The title and complete description of the
+specification changes must be provided in the specification text<= br class=3D"">+along with the name and version of the specification the cha= nge
+applies.  The `Status` of the specification change = always starts in
+the `Draft` state and is updated based on f= eedback from the industry
+standard forums.  The content= s of the specification text are required
+to use the [Creativ= e Commons Attribution 4.0
+International](https://spdx.org/li= censes/CC-BY-4.0.html)
+license using a `SPDX-License-Identif= ier` statement.
+
+```
+# Title: = [Must be Filled In]
+
+# Status: [Status]
+
+[Status] must be one of the following:
+* Draft
+* Submitted to industry standard forum
+* Accepted by industry standard forum
+* Accepted b= y industry standard forum with modifications
+* Rejected by i= ndustry standard forum
+
+# Document: [Title an= d Version]
+
+Here are some examples of [Title = and Version]:
+* UEFI Specification Version 2.8
+* ACPI Specification Version 6.3
+* UEFI Shell Specificatio= n Version 2.2
+* UEFI Platform Initialization Specification V= ersion 1.7
+* UEFI Platform Initialization Distribution Packa= ging Specification
+Version 1.1
+
+# License
+
+SPDX-License-Identifier: CC-BY-4= .0
+
+# Submitter: [TianoCore Community](https:= //www.tianocore.org)
+
+# Summary of the change=
+
+Required Section
+
+# Benefits of the change
+
+Required Se= ction
+
+# Impact of the change
+=
+Required Section
+
+# Detailed = description of the change [normative updates]
+
+Required Section
+
+# Special Instructions+
+Optional Section
+```
+
+# Intended workflow
+
+= The entity initiating a specification change enters a Bugzilla in the
+appropriate area of [TianoCore Bugzilla](bugzilla.tianocore.org).=
+This entry contains the outline of the change, and the full= initial draft
text is attached.
<= blockquote type=3D"cite" class=3D"">+
+If multiple specificat= ion updates are interdependent, especially if
+between differ= ent specifications, then multiple Bugzilla entries should be
=
created.
+T= hese Bugzilla entries *must* be linked together with dependencies.
+
+After the Bugzillas have been created, new branches= should be created
+in the relevant repositories for each Bug= zilla.  The branch names
+must use the following format = where #### is the Bugzilla ID and
+<Brief Description> = is an optional description of the change.
+
+ &= nbsp;  BZ####-<Brief Description>
+
+If multiple Bugzilla entries must coexist on a single branch, one o= f
+them is designated the _top-level_, with dependencies prop= erly
+tracked. That Bugzilla is be the one naming the branch.=
+
+# Source Code
+
+In order to ensure draft code does not accidentally leak into
+production use, and to signify when the changeover from draft to
+final happens, *all* new or modified[1] identifiers must be prefix= ed with
the relevant BZ#### identifiers.
+
+* [1] Modified= in a non-backwards-compatible way. If, for example, a
statically
+ &nbs= p;    sized array is grown - this does not need to be p= refixed. But a tag in a
+      comme= nt would be *highly* recommended.
+
+## File na= mes
+
+New public header files require the pref= ix (i.e.
`Bz1234MyNewProtocol.h`).
+Private header files do not need the= prefix.
+
+## Contents
+
+The tagging must follow the coding style used by each affected code=
base.
+Examples:
+
+| Released in spec | Dr= aft version in tree | Comment |
+| ---    &nbs= p;         | ---   &= nbsp;           &nbs= p;   | ---     |
+| `Funct= ionName`   | `Bz1234FunctionName`  |     = ;    |
+| `HEADER_MACRO`   | `B= Z1234_HEADER_MACRO` |         |
+
+For data structures or enums, any new or non-ba= ckwards-compatible
+structs or fields require a prefix. As ab= ove, growing an existing
+array in an existing struct require= s no prefix.
+
+| Released in spec   =    | Draft version in tree | Comment     = ;          |
+| ---            =        | ---     &nb= sp;            =  | ---           &nb= sp;       |
+| `typedef SO= ME_STRUCT` | `BZ1234_SOME_STRUCT`  | Typedef only [2]
|
+| `StructF= ield`         | `Bz1234StructField`=   | In existing struct[3] |
+| `typedef SOME_ENUM`=   | `BZ1234_SOME_ENUM`    | Typedef only [2]
|
+| `EnumValue`           = ;| `BzEnumValue`         | In exist= ing enum[3]   |
+
+* [2] If the struc= t or enum definition is separate from the typedef in the
public
+  =     header, the definition does not need the prefix.+* [3] Individual fields in newly added struct or enum do not n= eed prefix,
the
+      struct or enum alread= y carried the prefix.
+
+Variable prefixes indi= cating global scope ('g' or 'm') go before the BZ
prefix.
+
+| Released in spec | Draft version in tree | Comment |
+| = ---             = ; | ---           &n= bsp;       | ---     = ;|
+| `gSomeGuid`      | `gBz1234Som= eGuid`     |        =  |
+
+Local identifiers, including module-= global ones (m-prefixed) do not
+require a BZ prefix.
--
2.21.0.windows.1







IMPORTAN= T NOTICE: The contents of this email and any attachments are confidential a= nd may also be privileged. If you are not the intended recipient, please no= tify the sender immediately and do not disclose the contents to any other p= erson, use it for any purpose, or store or copy the information in any medi= um. Thank you.

--Apple-Mail=_72CF44A8-FB35-456C-8347-20299B4715F1--