public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Felix Polyudov" <felixp@ami.com>
To: "rfc@edk2.groups.io" <rfc@edk2.groups.io>,
	"'leif@nuviainc.com'" <leif@nuviainc.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Subject: Re: [edk2-rfc] [RFC] code-first process for UEFI-forum specifications
Date: Fri, 14 Feb 2020 15:29:38 +0000	[thread overview]
Message-ID: <9333E191E0D52B4999CE63A99BA663A003FFBE929A@atlms1.us.megatrends.com> (raw)
In-Reply-To: <20200120165852.GU15141@bivouac.eciton.net>

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.

  parent reply	other threads:[~2020-02-14 15:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-20 16:58 [RFC] code-first process for UEFI-forum specifications Leif Lindholm
2020-01-20 18:42 ` [edk2-rfc] " Laszlo Ersek
2020-02-04 19:23   ` [edk2-devel] " Michael D Kinney
2020-02-14 15:29 ` Felix Polyudov [this message]
2020-03-11 15:52   ` Samer El-Haj-Mahmoud
2020-03-11 16:02     ` Leif Lindholm
2020-03-11 16:31       ` Samer El-Haj-Mahmoud
2020-03-11 16:49         ` Doran, Mark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9333E191E0D52B4999CE63A99BA663A003FFBE929A@atlms1.us.megatrends.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox