Leif,

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 goup as an
Engineering Change Request (ECR), and voted on. For the UEFI Forum, this is a
change in workflow, not a change in process.

I think it would be good to add more details regarding the interaction between edk2 and UEFI forum.
Here is what I suggest:
Each specification update Bugzilla ticket must have a sponsor. A sponsor is a person or a company that will be presenting change request to the UEFI forum.
A sponsor has to be identified early in the process. Preferably along with Buzilla ticket creation.
It is sponsor's responsibility to officially submit ECR to the UEFI forum by creating a mantis ticket with a Bugzilla link.
There are two reasons to create mantis ticket early in the process:
- Creation of the ticket exposes the effort to the UEFI forum thus enabling early feedback from the members(via Bugzilla), which may reduce number of iterations in the
implement --> get feedback --> re-implement cycle.
- edk2 effort will be taken into consideration while scheduling future specification releases


Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.

On 01/20/20 17:58, Leif Lindholm wrote:

This is a proposal for 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 goup 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 will enable this new process by providing areas on
https://bugzilla.tianocore.org/ to track both specification updates and
reference implementations and new repositories under
https://github.com/tianocore/ dedicated to hold "code first".


## Bugzilla

bugzilla.tianocore.oorg will have a product category each for

s/oorg/org/

* ACPI Specification
* PI Specification
* UEFI Specification

Each product category will have a separate components for
* Specification
* Reference implementation


## Github
New repositories will be added for holding the text changes and the source code.

Specification text changes will be held within the affected source repository.

This seems to require that the specifications be available as something
"patchable" (e.g. GitBook source code), and offered in some public git repo.

(This one may break down where we have a specification change affecting multiple
specifications, but at that point we can track it with multiple BZ entries)

Initially, edk2-spec-update will be created to hold the reference
implementations. Additional repositories for implementing reference features in
additional open source projects can be added in the future, as required.


## Intended workflow
The entity initiating a specifiation update raises a Bugzilla in the appropriate
area in bugzilla.tianocore.org. This entry contains the outline of the change,
and the full initial draft text is attached.

How does this play together with *patches* for specs (see above)?
Attaching patches to BZs is not good practice. Should we attach complete
renderings of the patched (huge) specs?

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 BZs have been created, new branches should be created in the relevant
repositories for each bugzilla - the branch names should be BZ####, where ####
describes the bugzilla ID assigned, optionally followed by a '-' and something
more descriptive. If multipls bugzilla entries must coexist on a single branch,

s/multipls/multiple/

one of them is designated the 'top-level', with dependencies properly tracked.
That BZ will 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 need to be prefixed with the relevant BZ####.

[1] Modified in a non-backwards-compatible way. If, for example, a statically
sized array is grown - this does not need to be prefixed. (Question: but a
tag in a comment?)

The tagging must follow the coding style used by each affected codebase.
Examples:

| Released in spec | Draft version in tree | Comment |
| --- | --- | --- |
| FunctionName | Bz1234FunctionName | EDK2 |
| function_name | bz1234_function_name | Linux |
| HEADER_MACRO | BZ1234_HEADER_MACRO | EDK2, Linux |

Alternative 1)
Variable prefixes indicating global scope ('g' or 'm') go before the BZ prefix.

Alternative 2)
Variable prefixes indicating global scope ('g' or 'm') go after the BZ prefix.

Sounds good to me in general.

I think we'll have to work out the nuances of the coding style in
practice, while actually developing such additions. I can't name
anything specific that's missing from the proposal, but I'm quite sure
we'll find corner cases in practice.

Thanks
Laszlo

This is a proposal for 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 goup 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 will enable this new process by providing areas on
https://bugzilla.tianocore.org/ to track both specification updates and
reference implementations and new repositories under
https://github.com/tianocore/ dedicated to hold "code first".


## Bugzilla

bugzilla.tianocore.oorg will have a product category each for
* ACPI Specification
* PI Specification
* UEFI Specification

Each product category will have a separate components for
* Specification
* Reference implementation


## Github
New repositories will be added for holding the text changes and the source code.

Specification text changes will be held within the affected source repository.
(This one may break down where we have a specification change affecting multiple
specifications, but at that point we can track it with multiple BZ entries)

Initially, edk2-spec-update will be created to hold the reference
implementations. Additional repositories for implementing reference features in
additional open source projects can be added in the future, as required.


## Intended workflow
The entity initiating a specifiation update raises a Bugzilla in the appropriate
area in 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 BZs have been created, new branches should be created in the relevant
repositories for each bugzilla - the branch names should be BZ####, where ####
describes the bugzilla ID assigned, optionally followed by a '-' and something
more descriptive. If multipls bugzilla entries must coexist on a single branch,
one of them is designated the 'top-level', with dependencies properly tracked.
That BZ will 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 need to be prefixed with the relevant BZ####.

[1] Modified in a non-backwards-compatible way. If, for example, a statically
sized array is grown - this does not need to be prefixed. (Question: but a
tag in a comment?)

The tagging must follow the coding style used by each affected codebase.
Examples:

| Released in spec | Draft version in tree | Comment |
| --- | --- | --- |
| FunctionName | Bz1234FunctionName | EDK2 |
| function_name | bz1234_function_name | Linux |
| HEADER_MACRO | BZ1234_HEADER_MACRO | EDK2, Linux |

Alternative 1)
Variable prefixes indicating global scope ('g' or 'm') go before the BZ prefix.

Alternative 2)
Variable prefixes indicating global scope ('g' or 'm') go after the BZ prefix.