From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web09.15329.1579545748488075782 for ; Mon, 20 Jan 2020 10:42:28 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Hl+jF43V; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579545747; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V+Veru3xtuVALhEIz2bOxweDDLkEgddZZbXLzu2F+rA=; b=Hl+jF43V5R9l4r1pCvrdFjrkdEls7Fz2z+PQxguDQoTa21ewtUizc81wj474vm84za7gCX K/fHLywCjc72I7OCGlFHJpodxZfsqAOwseReg2JRGmzyshocDpogPsr/n2NtMNgjLKxZEp uNUUnsx75g95nlYwJfV5kt8PsPAVaVk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-314-2iv64fIrNFuxUiBaYbDnbA-1; Mon, 20 Jan 2020 13:42:25 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BC6C48017CC; Mon, 20 Jan 2020 18:42:24 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-50.ams2.redhat.com [10.36.117.50]) by smtp.corp.redhat.com (Postfix) with ESMTP id B41AC5C1BB; Mon, 20 Jan 2020 18:42:23 +0000 (UTC) Subject: Re: [edk2-rfc] [RFC] code-first process for UEFI-forum specifications To: rfc@edk2.groups.io, leif@nuviainc.com, devel@edk2.groups.io References: <20200120165852.GU15141@bivouac.eciton.net> From: "Laszlo Ersek" Message-ID: Date: Mon, 20 Jan 2020 19:42:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200120165852.GU15141@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-MC-Unique: 2iv64fIrNFuxUiBaYbDnbA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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