On Sep 2, 2020, at 12:06 PM, Matthew Carlson < matthewfcarlson@... >
wrote:








Andrew:









I think leveraging the existing edksetup is a great idea. Using the
existing EDK_TOOL_PATH variable could work but it seems clunky. Since the
pip module wouldn't be a path, it seems strange to put a boolean value in
a variable meant to hold a path. I definitely think that the scripts could
print whether they're using the pip modules or the in-source tools. Since
Lazlo suggested that pip will be the default, we could have the in-source
modules notify of the fact that you're using the in-source modules. An
additional feature for the pip module could be printing the version that
they are (since you can use the pip infrastructure to query the version of
a given module within a python script). Another option would be simply
trying the pip module first and then falling back to the in-source module.
There would be a slight speed penalty (likely around 10ms) but since this
would only apply to trim and build, it should have relatively low impact.









Lazlo:




Thank you for the excellent summary of the different pieces of the
discussion along with the links. To answer your first point, I think what
a developer does with their pip module is largely up to them. They could
do a virtual environment, they could just do what the requirements state,
or pip install from a checked out basetools.I do think there are some
variables that the virtual environment sets up that would be a good signal
whether you're in a virtual environment or not. I agree with your approach
of basetools development going into the out of edk2 repo and the
importance of making sure package maintainers test and validate their
areas with the new setup. I would personally try to get this early into
the development cycle, (just after this next stable tag this week) to give
the community and developers the most amount of time to get used to
things. A trial period of one release makes sense.









I also agree that the gateway is important in maintaining cohesion between
the new and the old. Hopefully that's nearing completion.









Hopefully other stewards will weigh in but otherwise we'll move ahead with
a proposed solution in patches next week.









-Matthew Carlson













On Wed, Sep 2, 2020 at 1:49 AM Laszlo Ersek < lersek@... > wrote:

On 09/02/20 02:49, Andrew Fish via groups.io ( http://groups.io/ ) wrote:

On Sep 1, 2020, at 4:35 PM, Matthew Carlson < matthewfcarlson@...

wrote:

Hello all,

A recent topic on the RFC mailing list went out and the work on moving

Basetools/Sources/Python to a separate repo has started. See the RFC
conversation here: https://edk2.groups.io/g/rfc/topic/74009714#270 < https://edk2.groups.io/g/rfc/topic/74009714#270

The repo in question is here: https://github.com/tianocore/edk2-basetools

< https://github.com/tianocore/edk2-basetools >

The current plan is shortly after the stable tag is created, a series

of patches will come into edk2 that redirects the build system into the
new python module as well as adds additional documentation. You can see a
sample of this work here: https://github.com/matthewfcarlson/edk2 < https://github.com/matthewfcarlson/edk2

as this has a branch that has the work required to use the basetools pip

module. The patches won't delete the Basetools/Sources/Python folder but
will allow users to select between them. After a certain grace period, the
python folder will be deleted and the pip module will be the de facto way
of using basetools.

Three questions need to be answered:

1. After the patches that enable the pip module land, how long should

the grace period be?

2. During the grace period, should basetools commits land in both

places or just in the edk2-basetools directory?

3. How should the user be able to select which basetools to use (the

one in EDK2 or the pip module)? Currently the approach being considered is
a simple environmental variable? One of the key considerations is
transparency since it won't be apparent what is being used for a
particular build without some sort of mechanism to notify the developer.
With two seperate versions of Basetools, it becomes very easy for the
version of basetools you're using to not be the one you expect.

Matthew,

I’ll throw out some current developer centric ideas.

1) If you `source edksetup.sh` (edksetup.bat) you get the current

behavior, and you add an argument you get the pip flavor? So maybe
`edksetup.bat pip-basetools`?

2) We have similar issues to this with env variables and the build

command dumps them out when it runs. Can we use the current EDK_TOOL_PATH?
Or maybe add an extra print to show that the pip module is being used?

I've skimmed:

- the earlier discussion linked above (rooted at < https://edk2.groups.io/g/rfc/message/270

),

- the even earlier comments in the "Discussion: Basetools a separate repo"
thread on edk2-devel:

https://edk2.groups.io/g/devel/message/57482
http://mid.mail-archive.com/734D49CCEBEEF84792F5B80ED585239D5C5019CE@SHSMSX104.ccr.corp.intel.com


If I still understand / remember correctly, the way at least *I* would use
the new feature is the following:

- set up a new virtual python environment,

- either install the new pip module "permanently" in the virtual
environment, or else install it in "editable mode" from a git checkout
(but *still* in the virtual environment)

- build edk2 with the virtual environment active

That is, for me anyway, the key distinguishing factor would be that I'd be
in a python virtual environment where this particular python module
existed / were installed.

Does this answer question (3)? Because, in my case anyway, I wouldn't have
to be *notified* about using the separate basetools repo vs. using the one
resident in edk2 -- instead, I'd have to *activate* the separate basetools
repo myself, as first step. So if that activation brings some queriable
feature into the environment (sets a new environment variable or makes a
new python package appear in the environment), then I think it's good
enough -- the usual tools that I run then can query these artifacts.

In short (I guess): commands should use the in-tree variant, unless I
activate the virtual environment that has the basetools PIP module
installed.

I think it would be fine to require that, *if* someone intends to activate
such a python virtual environment, *then* they do so *before* running
"edksetup.sh". So "edksetup.sh" could check for the python env having the
external basetools repo / module active. Hopefully that would be "early
enough".


Regarding the grace period -- questions (1) and (2):

- The patches introducing the new feature to edk2 should be posted to the
list. These patches should also add a warning to "edksetup.sh" that urges
the developer to use the out-of-tree basetools repo / PIP module, in case
"edksetup.sh" determines the current choice is the in-tree variant (that
is, the virtual env is inactive, or does not contain the new PIP module)

- While the patches are pending approval, BaseTools development is put on
hold (no fixes, no features).

- For every package (subsystem) listed in Maintainers.txt, in *both* edk2
*and* edk2-platfomrs, at least one "M" person is required to report back
with a Tested-by, meaning that they built said package successfully with
the new PIP module.

- When this feedback is complete, the patch is merged, and the new PIP
module becomes the default build system (see the edksetup.sh warning
described above).

- Optimally, the above (= comprehensive testing feedback, and merging)
would occur *early* in the development cycle (just after the last stable
tag).

- Going forward, bug reports and feature requests are only addressed in
the new (out-of-tree) module. If someone reports that they have to switch
back, *temporarily*, for whatever reason, to the in-tree variant, and the
in-tree variant no longer builds edk2 for them, then such issues can be
resolved on a case-by-case basis, *after* the issue is reported. Point
being, we make the out-of-tree system the new default because of the
comprehensive and strict initial testing requirements (see above); after
which the old system is preserved for a while only as a fallback. If the
fallback proves lacking later on (but still during the grace period), then
the community works to resolve the issue in one of two ways: either help
the issue reporter eliminate their need to use the fallback in the first
place, or backport the subject bugfix/feature to the fallback.

- After the *next* stable release (which still contains both the fallback
and the support for the out-of-tree PIP module), the fallback is removed.

Ultimately this would make the grace period almost one full development
cycle, in which cycle the new system should be tested comprehensively, and
become the default, near the beginning of the period.

This is just my proposal. Some of the other stewards are temporarily away;
I'd suggest waiting for their feedback too.

To finish up, I would like to highlight something from the earlier RFC:

"""
Contribution/Dev Process:
Since this is a separate repo, it will follow a slightly different
contribution and code review process.
1.      Github PR process will be used for contributions and code review
feedback
a.      The yet to be released “Tianocore PR archiver” will be used to
send to a dedicated list for basetools patch review archive
2.      PRs will only be committed if they keep linear history (no merge
commits)
3.      The PR review must be approved by at least 2 members of the
basetools team (not including the author)
4.      The PR must pass all automated checks
a.      Formatting/style
b.      Unit tests
c.      Code coverage (can’t commit change that would decrease overall %)
d.      DCO enforcement - https://probot.github.io/apps/dco/
e.      See other python requirements from the Python coding standard
5.      Github Issues will be used for non-security sensitive
bugs/issues/feature requests
"""

Point (1a) is a pre-requisite for merging the edk2 patches!

We cannot make the new system the default unless its development process
is integrated with the github-to-email gateway (webhook).

Thanks!
Laszlo

On Sep 2, 2020, at 12:06 PM, Matthew Carlson <matthewfcarlson@...> wrote:

Andrew:

I think leveraging the existing edksetup is a great idea. Using the existing EDK_TOOL_PATH variable could work but it seems clunky. Since the pip module wouldn't be a path, it seems strange to put a boolean value in a variable meant to hold a path. I definitely think that the scripts could print whether they're using the pip modules or the in-source tools. Since Lazlo suggested that pip will be the default, we could have the in-source modules notify of the fact that you're using the in-source modules. An additional feature for the pip module could be printing the version that they are (since you can use the pip infrastructure to query the version of a given module within a python script). Another option would be simply trying the pip module first and then falling back to the in-source module. There would be a slight speed penalty (likely around 10ms) but since this would only apply to trim and build, it should have relatively low impact.

Lazlo:
Thank you for the excellent summary of the different pieces of the discussion along with the links. To answer your first point, I think what a developer does with their pip module is largely up to them. They could do a virtual environment, they could just do what the requirements state, or pip install from a checked out basetools.I do think there are some variables that the virtual environment sets up that would be a good signal whether you're in a virtual environment or not. I agree with your approach of basetools development going into the out of edk2 repo and the importance of making sure package maintainers test and validate their areas with the new setup. I would personally try to get this early into the development cycle, (just after this next stable tag this week) to give the community and developers the most amount of time to get used to things. A trial period of one release makes sense.

I also agree that the gateway is important in maintaining cohesion between the new and the old. Hopefully that's nearing completion.

Hopefully other stewards will weigh in but otherwise we'll move ahead with a proposed solution in patches next week.

-Matthew Carlson


On Wed, Sep 2, 2020 at 1:49 AM Laszlo Ersek <lersek@... <mailto:lersek@...>> wrote:
On 09/02/20 02:49, Andrew Fish via groups.io <http://groups.io/> wrote:

On Sep 1, 2020, at 4:35 PM, Matthew Carlson <matthewfcarlson@... <mailto:matthewfcarlson@...>> wrote:

Hello all,

A recent topic on the RFC mailing list went out and the work on moving Basetools/Sources/Python to a separate repo has started. See the RFC conversation here: https://edk2.groups.io/g/rfc/topic/74009714#270

The repo in question is here: https://github.com/tianocore/edk2-basetools

The current plan is shortly after the stable tag is created, a series of patches will come into edk2 that redirects the build system into the new python module as well as adds additional documentation. You can see a sample of this work here: https://github.com/matthewfcarlson/edk2 as this has a branch that has the work required to use the basetools pip module. The patches won't delete the Basetools/Sources/Python folder but will allow users to select between them. After a certain grace period, the python folder will be deleted and the pip module will be the de facto way of using basetools.

Three questions need to be answered:

1. After the patches that enable the pip module land, how long should the grace period be?
2. During the grace period, should basetools commits land in both places or just in the edk2-basetools directory?
3. How should the user be able to select which basetools to use (the one in EDK2 or the pip module)? Currently the approach being considered is a simple environmental variable? One of the key considerations is transparency since it won't be apparent what is being used for a particular build without some sort of mechanism to notify the developer. With two seperate versions of Basetools, it becomes very easy for the version of basetools you're using to not be the one you expect.

Matthew,

I’ll throw out some current developer centric ideas.

1) If you `source edksetup.sh` (edksetup.bat) you get the current behavior, and you add an argument you get the pip flavor? So maybe `edksetup.bat pip-basetools`?
2) We have similar issues to this with env variables and the build command dumps them out when it runs. Can we use the current EDK_TOOL_PATH? Or maybe add an extra print to show that the pip module is being used?

I've skimmed:

- the earlier discussion linked above (rooted at <https://edk2.groups.io/g/rfc/message/270>),

- the even earlier comments in the "Discussion: Basetools a separate repo" thread on edk2-devel:

https://edk2.groups.io/g/devel/message/57482
http://mid.mail-archive.com/734D49CCEBEEF84792F5B80ED585239D5C5019CE@SHSMSX104.ccr.corp.intel.com

If I still understand / remember correctly, the way at least *I* would use the new feature is the following:

- set up a new virtual python environment,

- either install the new pip module "permanently" in the virtual environment, or else install it in "editable mode" from a git checkout (but *still* in the virtual environment)

- build edk2 with the virtual environment active

That is, for me anyway, the key distinguishing factor would be that I'd be in a python virtual environment where this particular python module existed / were installed.

Does this answer question (3)? Because, in my case anyway, I wouldn't have to be *notified* about using the separate basetools repo vs. using the one resident in edk2 -- instead, I'd have to *activate* the separate basetools repo myself, as first step. So if that activation brings some queriable feature into the environment (sets a new environment variable or makes a new python package appear in the environment), then I think it's good enough -- the usual tools that I run then can query these artifacts.

In short (I guess): commands should use the in-tree variant, unless I activate the virtual environment that has the basetools PIP module installed.

I think it would be fine to require that, *if* someone intends to activate such a python virtual environment, *then* they do so *before* running "edksetup.sh". So "edksetup.sh" could check for the python env having the external basetools repo / module active. Hopefully that would be "early enough".


Regarding the grace period -- questions (1) and (2):

- The patches introducing the new feature to edk2 should be posted to the list. These patches should also add a warning to "edksetup.sh" that urges the developer to use the out-of-tree basetools repo / PIP module, in case "edksetup.sh" determines the current choice is the in-tree variant (that is, the virtual env is inactive, or does not contain the new PIP module)

- While the patches are pending approval, BaseTools development is put on hold (no fixes, no features).

- For every package (subsystem) listed in Maintainers.txt, in *both* edk2 *and* edk2-platfomrs, at least one "M" person is required to report back with a Tested-by, meaning that they built said package successfully with the new PIP module.

- When this feedback is complete, the patch is merged, and the new PIP module becomes the default build system (see the edksetup.sh warning described above).

- Optimally, the above (= comprehensive testing feedback, and merging) would occur *early* in the development cycle (just after the last stable tag).

- Going forward, bug reports and feature requests are only addressed in the new (out-of-tree) module. If someone reports that they have to switch back, *temporarily*, for whatever reason, to the in-tree variant, and the in-tree variant no longer builds edk2 for them, then such issues can be resolved on a case-by-case basis, *after* the issue is reported. Point being, we make the out-of-tree system the new default because of the comprehensive and strict initial testing requirements (see above); after which the old system is preserved for a while only as a fallback. If the fallback proves lacking later on (but still during the grace period), then the community works to resolve the issue in one of two ways: either help the issue reporter eliminate their need to use the fallback in the first place, or backport the subject bugfix/feature to the fallback.

- After the *next* stable release (which still contains both the fallback and the support for the out-of-tree PIP module), the fallback is removed.

Ultimately this would make the grace period almost one full development cycle, in which cycle the new system should be tested comprehensively, and become the default, near the beginning of the period.

This is just my proposal. Some of the other stewards are temporarily away; I'd suggest waiting for their feedback too.

To finish up, I would like to highlight something from the earlier RFC:

"""
Contribution/Dev Process:
Since this is a separate repo, it will follow a slightly different contribution and code review process.
1. Github PR process will be used for contributions and code review feedback
a. The yet to be released “Tianocore PR archiver” will be used to send to a dedicated list for basetools patch review archive
2. PRs will only be committed if they keep linear history (no merge commits)
3. The PR review must be approved by at least 2 members of the basetools team (not including the author)
4. The PR must pass all automated checks
a. Formatting/style
b. Unit tests
c. Code coverage (can’t commit change that would decrease overall %)
d. DCO enforcement - https://probot.github.io/apps/dco/
e. See other python requirements from the Python coding standard
5. Github Issues will be used for non-security sensitive bugs/issues/feature requests
"""

Point (1a) is a pre-requisite for merging the edk2 patches!

We cannot make the new system the default unless its development process is integrated with the github-to-email gateway (webhook).

Thanks!
Laszlo

On 09/02/20 02:49, Andrew Fish via groups.io wrote:

On Sep 1, 2020, at 4:35 PM, Matthew Carlson <matthewfcarlson@...>

wrote:

Hello all,

A recent topic on the RFC mailing list went out and the work on moving

Basetools/Sources/Python to a separate repo has started. See the RFC
conversation here: https://edk2.groups.io/g/rfc/topic/74009714#270 <
https://edk2.groups.io/g/rfc/topic/74009714#270>

The repo in question is here:

https://github.com/tianocore/edk2-basetools <
https://github.com/tianocore/edk2-basetools>

The current plan is shortly after the stable tag is created, a series

of patches will come into edk2 that redirects the build system into the new
python module as well as adds additional documentation. You can see a
sample of this work here: https://github.com/matthewfcarlson/edk2 <
https://github.com/matthewfcarlson/edk2> as this has a branch that has
the work required to use the basetools pip module. The patches won't delete
the Basetools/Sources/Python folder but will allow users to select between
them. After a certain grace period, the python folder will be deleted and
the pip module will be the de facto way of using basetools.

Three questions need to be answered:

1. After the patches that enable the pip module land, how long should

the grace period be?

2. During the grace period, should basetools commits land in both

places or just in the edk2-basetools directory?

3. How should the user be able to select which basetools to use (the

one in EDK2 or the pip module)? Currently the approach being considered is
a simple environmental variable? One of the key considerations is
transparency since it won't be apparent what is being used for a particular
build without some sort of mechanism to notify the developer. With two
seperate versions of Basetools, it becomes very easy for the version of
basetools you're using to not be the one you expect.

Matthew,

I’ll throw out some current developer centric ideas.

1) If you `source edksetup.sh` (edksetup.bat) you get the current

behavior, and you add an argument you get the pip flavor? So maybe
`edksetup.bat pip-basetools`?

2) We have similar issues to this with env variables and the build

command dumps them out when it runs. Can we use the current EDK_TOOL_PATH?
Or maybe add an extra print to show that the pip module is being used?

I've skimmed:

- the earlier discussion linked above (rooted at <
https://edk2.groups.io/g/rfc/message/270>),

- the even earlier comments in the "Discussion: Basetools a separate repo"
thread on edk2-devel:

https://edk2.groups.io/g/devel/message/57482

http://mid.mail-archive.com/734D49CCEBEEF84792F5B80ED585239D5C5019CE@SHSMSX104.ccr.corp.intel.com

If I still understand / remember correctly, the way at least *I* would use
the new feature is the following:

- set up a new virtual python environment,

- either install the new pip module "permanently" in the virtual
environment, or else install it in "editable mode" from a git checkout (but
*still* in the virtual environment)

- build edk2 with the virtual environment active

That is, for me anyway, the key distinguishing factor would be that I'd be
in a python virtual environment where this particular python module existed
/ were installed.

Does this answer question (3)? Because, in my case anyway, I wouldn't have
to be *notified* about using the separate basetools repo vs. using the one
resident in edk2 -- instead, I'd have to *activate* the separate basetools
repo myself, as first step. So if that activation brings some queriable
feature into the environment (sets a new environment variable or makes a
new python package appear in the environment), then I think it's good
enough -- the usual tools that I run then can query these artifacts.

In short (I guess): commands should use the in-tree variant, unless I
activate the virtual environment that has the basetools PIP module
installed.

I think it would be fine to require that, *if* someone intends to activate
such a python virtual environment, *then* they do so *before* running
"edksetup.sh". So "edksetup.sh" could check for the python env having the
external basetools repo / module active. Hopefully that would be "early
enough".


Regarding the grace period -- questions (1) and (2):

- The patches introducing the new feature to edk2 should be posted to the
list. These patches should also add a warning to "edksetup.sh" that urges
the developer to use the out-of-tree basetools repo / PIP module, in case
"edksetup.sh" determines the current choice is the in-tree variant (that
is, the virtual env is inactive, or does not contain the new PIP module)

- While the patches are pending approval, BaseTools development is put on
hold (no fixes, no features).

- For every package (subsystem) listed in Maintainers.txt, in *both* edk2
*and* edk2-platfomrs, at least one "M" person is required to report back
with a Tested-by, meaning that they built said package successfully with
the new PIP module.

- When this feedback is complete, the patch is merged, and the new PIP
module becomes the default build system (see the edksetup.sh warning
described above).

- Optimally, the above (= comprehensive testing feedback, and merging)
would occur *early* in the development cycle (just after the last stable
tag).

- Going forward, bug reports and feature requests are only addressed in
the new (out-of-tree) module. If someone reports that they have to switch
back, *temporarily*, for whatever reason, to the in-tree variant, and the
in-tree variant no longer builds edk2 for them, then such issues can be
resolved on a case-by-case basis, *after* the issue is reported. Point
being, we make the out-of-tree system the new default because of the
comprehensive and strict initial testing requirements (see above); after
which the old system is preserved for a while only as a fallback. If the
fallback proves lacking later on (but still during the grace period), then
the community works to resolve the issue in one of two ways: either help
the issue reporter eliminate their need to use the fallback in the first
place, or backport the subject bugfix/feature to the fallback.

- After the *next* stable release (which still contains both the fallback
and the support for the out-of-tree PIP module), the fallback is removed.

Ultimately this would make the grace period almost one full development
cycle, in which cycle the new system should be tested comprehensively, and
become the default, near the beginning of the period.

This is just my proposal. Some of the other stewards are temporarily away;
I'd suggest waiting for their feedback too.

To finish up, I would like to highlight something from the earlier RFC:

"""
Contribution/Dev Process:
Since this is a separate repo, it will follow a slightly different
contribution and code review process.
1. Github PR process will be used for contributions and code review
feedback
a. The yet to be released “Tianocore PR archiver” will be used to
send to a dedicated list for basetools patch review archive
2. PRs will only be committed if they keep linear history (no merge
commits)
3. The PR review must be approved by at least 2 members of the
basetools team (not including the author)
4. The PR must pass all automated checks
a. Formatting/style
b. Unit tests
c. Code coverage (can’t commit change that would decrease overall %)
d. DCO enforcement - https://probot.github.io/apps/dco/
e. See other python requirements from the Python coding standard
5. Github Issues will be used for non-security sensitive
bugs/issues/feature requests
"""

Point (1a) is a pre-requisite for merging the edk2 patches!

We cannot make the new system the default unless its development process
is integrated with the github-to-email gateway (webhook).

Thanks!
Laszlo

-----Original Message-----
From: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Sent: Monday, August 10, 2020 11:37 AM
To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>; rfc@edk2.groups.io
Cc: Laszlo Ersek <lersek@...>; Andrew Fish <afish@...>; Leif Lindholm <leif@...>; Samer El-Haj-
Mahmoud <Samer.El-Haj-Mahmoud@...>
Subject: RE: [edk2-devel] [Wiki][Patch V2] Add EDK II Code First Process Wiki Page

Mike,

Looks good as a starting point!

Acked-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>


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."

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

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

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

- If the change includes some graphics, is there any guidance on inclusion of the graphics files in the repository?

Thanks,
--Samer

-----Original Message-----
From: devel@edk2.groups.io <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
<michael.d.kinney@...>; rfc@edk2.groups.io
Cc: Laszlo Ersek <lersek@...>; Andrew Fish <afish@...>;
Leif Lindholm <leif@...>
Subject: Re: [edk2-devel] [Wiki][Patch V2] Add EDK II Code First Process
Wiki Page

A version of this Wiki page is also provided here for review:

https://github.com/mdkinney/edk2/wiki/EDK-II-Code-First-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 <lersek@...>; Andrew Fish <afish@...>;
Leif Lindholm <leif@...>
Subject: [edk2-devel] [Wiki][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 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.

Cc: Laszlo Ersek <lersek@...>
Cc: Andrew Fish <afish@...>
Cc: Leif Lindholm <leif@...>
Signed-off-by: Michael D Kinney <michael.d.kinney@...>
---
EDK-II-Code-First-Process.md | 182
+++++++++++++++++++++++++++++++++++
1 file changed, 182 insertions(+)
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 @@
+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 change

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 "code
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 required.
+
+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 multiple

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 draft

text is attached.

+
+If multiple specification updates are interdependent, especially if
+between different specifications, then multiple Bugzilla entries should 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
+<Brief Description> is an optional description of the change.
+
+ BZ####-<Brief Description>
+
+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 in the

public

+ header, the definition does not need the prefix.
+* [3] Individual fields in newly added struct or enum do not need prefix,

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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential 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.

-----Original Message-----
From: devel@edk2.groups.io <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
<michael.d.kinney@...>; rfc@edk2.groups.io
Cc: Laszlo Ersek <lersek@...>; Andrew Fish <afish@...>;
Leif Lindholm <leif@...>
Subject: Re: [edk2-devel] [Wiki][Patch V2] Add EDK II Code First Process
Wiki Page

A version of this Wiki page is also provided here for review:

https://github.com/mdkinney/edk2/wiki/EDK-II-Code-First-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 <lersek@...>; Andrew Fish <afish@...>;
Leif Lindholm <leif@...>
Subject: [edk2-devel] [Wiki][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 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.

Cc: Laszlo Ersek <lersek@...>
Cc: Andrew Fish <afish@...>
Cc: Leif Lindholm <leif@...>
Signed-off-by: Michael D Kinney <michael.d.kinney@...>
---
EDK-II-Code-First-Process.md | 182
+++++++++++++++++++++++++++++++++++
1 file changed, 182 insertions(+)
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 @@
+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 change

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 "code
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 required.
+
+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 multiple

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 draft

text is attached.

+
+If multiple specification updates are interdependent, especially if
+between different specifications, then multiple Bugzilla entries should 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
+<Brief Description> is an optional description of the change.
+
+ BZ####-<Brief Description>
+
+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 in the

public

+ header, the definition does not need the prefix.
+* [3] Individual fields in newly added struct or enum do not need prefix,

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

-----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 <lersek@...>; Andrew Fish <afish@...>; Leif Lindholm <leif@...>
Subject: [edk2-devel] [Wiki][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 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.

Cc: Laszlo Ersek <lersek@...>
Cc: Andrew Fish <afish@...>
Cc: Leif Lindholm <leif@...>
Signed-off-by: Michael D Kinney <michael.d.kinney@...>
---
EDK-II-Code-First-Process.md | 182 +++++++++++++++++++++++++++++++++++
1 file changed, 182 insertions(+)
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 @@
+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 change 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 "code 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 required.
+
+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 multiple 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 draft text is attached.
+
+If multiple specification updates are interdependent, especially if between
+different specifications, then multiple Bugzilla entries should 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 <Brief Description> is an optional
+description of the change.
+
+ BZ####-<Brief Description>
+
+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 in the public
+ header, the definition does not need the prefix.
+* [3] Individual fields in newly added struct or enum do not need prefix, 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

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Artem Shchygel
Sent: Monday, August 3, 2020 1:24 PM
To: Laszlo Ersek <lersek@...>; rfc@edk2.groups.io
Subject: Re: [edk2-rfc] Git commit message RFC

On Sat, Aug 1, 2020 at 03:47 PM, Laszlo Ersek wrote:

On 08/01/20 00:19, Artem Shchygel wrote:

Hi, All

In this RFC we're proposing slight changes to Git commit message format to

make it more informative and more friendly for automation tools.

Here is the list of changes proposed

1. Start subject line with the tag that describes nature of the commit. List

of tags is as follows:

- **fix:** For commits that are fixing the bug
- **feat:** For commits that introduce a new feature
- **imp:** For commits that introduce improvement of the existing code

logic without changing functionality

- **doc:** For commits that don't change code logic but deal with

documentation (including adding comments, fix spelling, etc.)

- **style:** For commits that don't change code logic but deal with coding

style (indents, whitespaces, etc.)

- **chore:** For commits that don't affect output target (like changes to

CI scripts)

Having tagged commits will help closed source maintainers to decide which

commits to cherry-pick for projects that are in "maintenance mode" as opposite
to "active development mode"

Hints are very welcome, but not in subject lines. Please use

Name: value
Name: value # comment

style tags near the end of the commit messages instead.

Here are the reasons I believe subject line tags should be in subject line:
1. It is expected for those tags to be mandatory. This requirement will force committer to think one more time about what
commit changes are about. This may (hopefully) lead to more structured commits, where fixes, improvements, features and
style changes are not mixed together. But when you try to make something mandatory it's better to minimize the
friction/cognitive load for actually doing the thing. From this point of view short tag in subject line is easier to add
than separate line with "Name: value" in the commit body, which for trivial changes may even not be there.
2. I believe these tags, while certainly be machine-friendly still have some human-readable value. For example we can
easily say that commits marked as doc/style/chore have no regression impact even if the commit itself is pretty large. We
can also assume that "fix" commits will be smaller and easier to merge/backport than "feat" or "imp" commits.

Subject lines are primarily for human readers. And because edk2 has long
filenames, and we're supposed to include package names and component
names in subject lines, hardly any space is left for actual meaningful
subjects. CVE identifiers are the only exceptions (they *should* be
mentioned in subjects lines; and PatchCheck.py already permits more
characters in subjects that contain CVE identifiers).

2. Remove "Package/Module" reference from subject line. Since subject line

length is limited it's better to be allocated for commit description which is
more important

I'm opposed to this. "Package/Module" is the absolute key by which I
orient myself for determining impact / maintainership relevance /
regression risk. I regularly browse the git history for new commits, and
I entirely orient myself after the Package/Module prefixes.

As you've said above adding "Package/Module" description leave almost no space for meaningful subjects, practically
rendering them useless. Add to that the fact that this information is redundant in the sense, that it's already included
in changed files paths. Now I'm obviously don't know actual workflow maintainers use to perform their tasks, so it's hard
to come up with replacements. But filtering commits changing files in folders of the particular interest can be easily
done with git log command if you work with actual repo. If you look for particular folders in email inbox I think there is
the way to have email subject include "Package/Module" reference, while not having it in the commit subject line

3. Remove "CVE" number from subject line for the same reason. CVE number (if

present) should be placed on separate line after long description (see example
below)

I agree that mentioning CVE IDs in subject lines is an exceptions. I
could let go of that, if contributors were *very* disciplined about
stating CVE IDs properly in commit messages.

I think including CVE reference (which you probably can't easily type right off your head, but have to look it up) takes
the same amount of discipline regardless of whether it's included in the subject line or on the separate line in commit's
body

4. Add optional tag to the long description. List of tags is as follows:
- **[BREAKING CHANGE]:** For commits that break backward compatibility
- **[SECURITY FIX]:** For commits that fix known security vulnerability

Explicitly stating such traits is very welcome (even if not with this
specific format, perhaps) in commit message bodies.

The format of optional tag is flexible, any suggestions are welcome

5. Move bugzilla reference to separate line after long description and

(possible) CVE line (see example below). This move follows the logic of
evaluation of commit nature (read subject, if unclear read long description,
if still unclear see bugzilla)

Bugzilla numbers should already be stated as:

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129

or

Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2129

or

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2129

tags.

We're not proposing format changes for bugzilla references, just their placement in the commit body. Instead of being in
first lines we propose to move them to the last lines

An example would be:
```
imp: Short one line description of change

Several lines of
description for the
change.

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1000

Signed-off-by: Contributor Name <contributor@...>
Reviewed-by: Reviewer Name <reviewer@...>
```

A CVE example would be:
```
fix: Short one line description of change

[SECURITY FIX]: Several lines of
description for the
change.

CVE-2018-12180

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2000

Signed-off-by: Contributor Name <contributor@...>
Reviewed-by: Reviewer Name <reviewer@...>
```

I entirely support including as much information as possible in commit
messages; if we can do that in machine readable format, that's even
better. But subject lines are not the place; the commit message bodies are.

I recommend the "Name: value" and "Name: value # comment" formats, but
don't insist on those.

What really matters to me is that we don't litter subject lines with
machine-readable artifacts.

Obviously: this is just my personal opinion.

Thanks
Laszlo

Thank you for taking your time to review our proposal. Your comments allowed me to express our intentions more clearly

Artem