[RFC] code-first process for UEFI-forum specifications

[RFC] code-first process for UEFI-forum specifications

[Leif Lindholm]

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.

Re: [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

[Laszlo Ersek]

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

Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

[Michael D Kinney]

Leif,

A few comments included below.

Thanks,

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On
> Behalf Of Laszlo Ersek
> Sent: Monday, January 20, 2020 10:42 AM
> To: rfc@edk2.groups.io; leif@nuviainc.com;
> devel@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first
> process for UEFI-forum specifications
> 
> 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.
> 

I recommend we use MarkDown.  GitHub flavored MarkDown
may be a good choice so an ECR can be viewed from the
web view of GitHub.  This also support text based patch
reviews of the ECR content.

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

I recommend using branches in the existing edk2-staging
repository for changes that only impact EDK II firmware
components/tools.

> >
> >
> > ## 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?)
> >

It would be good to clarify when the BZ### prefix is required
and not required and to describe a few more use cases.  Here 
are a few.  I am sure this list will be expanded when real
examples are implemented.

1) New/modified interfaces require prefix.
  a) New structures.  Only top level struct require a prefix.  Fields and sub structures do not.
2) New public header file names need prefix (e.g. Bz0001MyNewProtocol.h)
3) New GUID global variables need a prefix (e.g. gBz0001MyNewProtocolGuid)
4) Adding a field, enum, or #define to existing interface require a prefix
5) Internal interfaces and implementation elements do not need a prefix.

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

I prefer Alternative 1 to follow EDK II C Coding Standard.

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

Re: [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

[Felix Polyudov]

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.

Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

[Samer El-Haj-Mahmoud]

Has there been any progress on this "code-first process" proposal? Any timeline on when we should expect it to be launched?

Thanks,
--Samer


-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Felix Polyudov via Groups.Io
Sent: Friday, February 14, 2020 10:30 AM
To: rfc@edk2.groups.io; 'leif@nuviainc.com' <leif@nuviainc.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

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.



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.

Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

[Leif Lindholm]

Hi Samer,

I had, perhaps excessively, been waiting for more feedback.

I promised Mike yesterday that I will rework based on feedback and
send out next week at the latest. If people have no further comments
then, we can adopt the process and start using it.

Regards,

Leif

On Wed, Mar 11, 2020 at 15:52:07 +0000, Samer El-Haj-Mahmoud wrote:
> Has there been any progress on this "code-first process" proposal? Any timeline on when we should expect it to be launched?
> 
> Thanks,
> --Samer
> 
> 
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Felix Polyudov via Groups.Io
> Sent: Friday, February 14, 2020 10:30 AM
> To: rfc@edk2.groups.io; 'leif@nuviainc.com' <leif@nuviainc.com>; devel@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications
> 
> 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.
> 
> 
> 
> 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.

Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

[Samer El-Haj-Mahmoud]

Thanks Leif.

As far as I know, the main feedback I heard is "when will this start?"... So, the sooner the better .. Thanks for taking the lead and driving!



-----Original Message-----
From: Leif Lindholm <leif@nuviainc.com>
Sent: Wednesday, March 11, 2020 12:03 PM
To: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: devel@edk2.groups.io; Felixp@ami.com; rfc@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

Hi Samer,

I had, perhaps excessively, been waiting for more feedback.

I promised Mike yesterday that I will rework based on feedback and send out next week at the latest. If people have no further comments then, we can adopt the process and start using it.

Regards,

Leif

On Wed, Mar 11, 2020 at 15:52:07 +0000, Samer El-Haj-Mahmoud wrote:
> Has there been any progress on this "code-first process" proposal? Any timeline on when we should expect it to be launched?
>
> Thanks,
> --Samer
>
>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Felix
> Polyudov via Groups.Io
> Sent: Friday, February 14, 2020 10:30 AM
> To: rfc@edk2.groups.io; 'leif@nuviainc.com' <leif@nuviainc.com>;
> devel@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for
> UEFI-forum specifications
>
> 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.
>
> 
>
> 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.
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.

Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

[Doran, Mark]

The one thing we don't have in hand for this is a template into which we can put prospective ECR submission material that is collected as part of the code-first process.

We could just use the ECR template that is used for regular proposals with the UEFI Work Groups.  However, the thought was to add some verbiage that template which effectively says: anything put in the proposed ECR template comes with permission to give ownership and rights in that content to the UEFI Forum so that it can publish the material as part of the specs under the same rights as all the other spec material there.

Since TianoCore doesn't have a legal team per se, we're having Intel legal work something like that with a view to contributing that to the community for review and hopefully adoption in short order.

That said, I don't think we need to wait on the template to begin using a code-first approach for things we would ultimately like to end up in the formal specs once code is "done".  We really only need that template at the point that the ECR content is also done, meaning reflective of sufficiently completed code work.

If we do start assembling content that looks like ECR fodder in parallel with code development, I'd suggest that we keep track of who is putting words into that fodder so that when it gets moved into the template prior to formal submission as an ECR we can get assurance from those people that they are OK with the T's & C's in the template.

Fundamentally we just need to make sure that everyone contributing to the development of one of these code first things is OK with spec description stuff being incorporated into a UEFI document under UEFI T's & C's as the end product.  UEFI T's & C's are designed to make sure that anyone can read the spec just for the asking and that there are no undesired IP complications (as there have been in some other standards) for people that choose to implement to the specs.

--
Cheers,

Mark.

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer El-Haj-Mahmoud
Sent: Wednesday, March 11, 2020 9:32 AM
To: Leif Lindholm <leif@nuviainc.com>
Cc: devel@edk2.groups.io; Felixp@ami.com; rfc@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

Thanks Leif.

As far as I know, the main feedback I heard is "when will this start?"... So, the sooner the better .. Thanks for taking the lead and driving!



-----Original Message-----
From: Leif Lindholm <leif@nuviainc.com>
Sent: Wednesday, March 11, 2020 12:03 PM
To: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: devel@edk2.groups.io; Felixp@ami.com; rfc@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

Hi Samer,

I had, perhaps excessively, been waiting for more feedback.

I promised Mike yesterday that I will rework based on feedback and send out next week at the latest. If people have no further comments then, we can adopt the process and start using it.

Regards,

Leif

On Wed, Mar 11, 2020 at 15:52:07 +0000, Samer El-Haj-Mahmoud wrote:
> Has there been any progress on this "code-first process" proposal? Any timeline on when we should expect it to be launched?
>
> Thanks,
> --Samer
>
>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Felix 
> Polyudov via Groups.Io
> Sent: Friday, February 14, 2020 10:30 AM
> To: rfc@edk2.groups.io; 'leif@nuviainc.com' <leif@nuviainc.com>; 
> devel@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for 
> UEFI-forum specifications
>
> 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.
>
> 
>
> 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.
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.