From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by mx.groups.io with SMTP id smtpd.web10.352.1584990353384352536 for ; Mon, 23 Mar 2020 12:05:53 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=P8/pZQrA; spf=pass (domain: nuviainc.com, ip: 209.85.128.65, mailfrom: leif@nuviainc.com) Received: by mail-wm1-f65.google.com with SMTP id c187so616377wme.1 for ; Mon, 23 Mar 2020 12:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=C56Hu6M0Nbw+4u4iDPLWXquBTcSptTo+8HR1epj5aWU=; b=P8/pZQrAnVughjbkuscEBQC0UFbJEANmTRcDBMT6gl0RQiahJVU0PbjacczjMHJR99 IhsJyfZb9Y++GWs81Ofmnm9SG4NyegfgQnmGKZCGq0Awp2fYsQZw9Vas0Eb7IowgdN8j cjtu0DaRJ3+oKw6OAi7UMl3KGYgRBwP4qs2XG5YqR6AAYHDEiOMwkTAzaIBwFwWrXKVI Jua3UNT/MX9usDZN7v4v0ul5i6gKugjtsRdIUJFgqdBSXLV+NH893Qqw4NbDEOL5r/17 agccecsv8u5/igSM85MoyKk9Vx5xtFagdl1kH9foGJnlGlXkJBJHn2RSMd7FQtBjM7Id EsiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=C56Hu6M0Nbw+4u4iDPLWXquBTcSptTo+8HR1epj5aWU=; b=KIDfDPrMXY//xGe1hY8oveLh6VE0zIlCYBurt/7oJ8Oc41nwTScRjnEOkBZFNiVfaV IZ6HD7/ITg70IiUwBw4yktJyoKTHbcduNc85qr0/5Hnp0vsjAE86HcOHhQKB8eqj3zDn Eqxx2XV8B933sASQ60JkQ0Y59i28xrWfwZj3A/SYN1K+RJP7iDKlPsFLwQ5aJjAy0/KP 34/0hZ1akdvY6PFUdu46UbYoRaMgu9K8GRNuT1xbUm/dzgLQN4p5SSQ4v43CZ/RzhmvB hV09spMCl/PxnEo+U78xEOL3a2NIotltPMVTehUQhavaUDiI1nSBB6dNW3On89tc6474 c+zA== X-Gm-Message-State: ANhLgQ0FILlaLYO4BQG/9hP0jd52aRp5aRD7mjQ4NtOEAF/zVBVIcSqW mZn8B6+rCAyk0vpEK1m13LOFmdV2gjSpSWb36BadG8CsVKpvFVxds263XVfw7s8PzK1p7UpQ6iK wmOZXbfaPEEVtYh/y818XKf6JxsotWuvL2CSPMkSxCteHW7juVz6kUdgXxTVDqYQ= X-Google-Smtp-Source: ADFU+vuVemmmf5qVKgYjwLgT3J87Tx5818B/EijxeNQZZzKJF+stHj6kkBcgWq9iBtL8z0/tBxXRGA== X-Received: by 2002:a1c:7418:: with SMTP id p24mr858655wmc.138.1584990350336; Mon, 23 Mar 2020 12:05:50 -0700 (PDT) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id g2sm25997502wrs.42.2020.03.23.12.05.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Mar 2020 12:05:49 -0700 (PDT) Date: Mon, 23 Mar 2020 19:05:48 +0000 From: "Leif Lindholm" To: devel@edk2.groups.io, rfc@edk2.groups.io Cc: Felix Polyudov , Mark Doran , Andrew Fish , Laszlo Ersek , Michael D Kinney Subject: [RFCv2] code-first process for UEFI-forum specifications Message-ID: <20200323190548.GF22097@bivouac.eciton.net> MIME-Version: 1.0 User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Changes to v2 of this proposal: - Feedback from Laszlo[a] and Mike[b] incorporated. - I opted to view Mike's responses to Laszlo's questions as accepted, as no follow-up was made. Feedback from Felix[c] *not* incorporated, as while I agree with all of it, I am not convinced that information should go here, but should instead reside with the UEFI Forum. (This text documents the public part of the process - it would cause me slight impedance mismatch to have it also document the non-public part.) [a] https://edk2.groups.io/g/devel/message/53422 [b] https://edk2.groups.io/g/devel/message/53738 [c] https://edk2.groups.io/g/devel/message/54453 / Leif --- 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.org 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, in the Github flavour of markdown, in a file (or split across several files) with .md suffix. (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) Reference implementations targeting EDK2 will be held in branches on edk2-staging. 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 multiple 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. But a tag in a comment would be *highly* recommended. ### File names New public header files need 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 codebase. 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. | `typedef SOME_STRUCT` | `BZ1234_SOME_STRUCT` | Typedef only [2] | | `StructField` | `Bz1234StructField` | In existing struct[3] | | `typedef SOME_ENUM` | `BZ1234_SOME_ENUM` | Typedef only [2] | [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 typedefd struct do not need prefix, the struct already carried the prefix. Variable prefixes indicating global scope ('g' or 'm') go before the BZ prefix. | `gSomeGuid` | `gBz1234SomeGuid` | | Local identifiers, including module-global ones (m-prefixed) do not require a BZ prefix.