From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by mx.groups.io with SMTP id smtpd.web09.13651.1579539536191709350 for ; Mon, 20 Jan 2020 08:58:56 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=eE/1IiD5; spf=pass (domain: nuviainc.com, ip: 209.85.221.68, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f68.google.com with SMTP id b6so242671wrq.0 for ; Mon, 20 Jan 2020 08:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=sqzAa4KxkvfoYitrD+LwDKza31uEppO0bUoYfo31Dak=; b=eE/1IiD5THbCEV6rfCg9DLVmsilUYbwC/luCiyUAbQ/D7PaGBPKKEq2JyVX6bBhxak Rw3krXe/IVXm8sw/QLd1xy0YuKL3iXmkDz7nuHm3bxVmrtGDCOTAabQVIQlMjVnR1jX4 PrPxJW/V3vROpdJ/AGS7ijczv/L9c3mG4M+JCs2V0VgUPyi7Vis9oCS7Z8fsiM5s2W/f AjNjCpsh4sli44L2/Uf1ykRbc6CnKF7eYVvuHOlFMn+GTbKG95gd9zd43lP/lJy3/kGQ ep2oUMN9zSVJqJXIzAmFzUqTkC51hVcDT8nutl3yjo1aceNz4KaV7sm9RGL6hh0u4UYC X3Yg== 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:subject:message-id:mime-version :content-disposition:user-agent; bh=sqzAa4KxkvfoYitrD+LwDKza31uEppO0bUoYfo31Dak=; b=XRx9H+FdqQpkKa/KsrH7EgE9ogQrsyEBApikf8UtKLEiQJMD+1jDwefvr/XdkaT3+l 9wEyS8wA24vKZ2N4K4LQ00ivEPDHtlq7Tx9Id/yW6ATTe+V5do0Sk2MvDvDF1RNZ3ISu O6fgSaMAZ11xCtQqL26f4Ag6t950NEE6xvrMxcnlBqIY9xKeBvgzBw9DKWP/K3JRwbED ifGmm95VoavpJu7o76dF0iPZe32732WRBsJ2zhiPzSBdJwd7m1yMF8Q34+821Z0ThIvg NE6buX4GYo18ILqRPGkU7acc1xpSRgfHolNhldTZCaF0TAlu1njD+i4eLeAKJ2Nn+cso afbA== X-Gm-Message-State: APjAAAUbpwly/UcI0EShgwvODc35lX3eB0MJRvApJ4PSG3iys+DYnlVn wRV/VaIt5tnfiNyNFBXxIFcwAp5EhDYVNjbBH8k9CgXfE5vRdIWC5BVq5+Ep1/Xlu35mT/KY2IP dmNyVT778xSfeVzKU1HdSUnlZ0hkmqpKeRdqV6TPIF9VRgwbt25E2WFcPK2/7XlI= X-Google-Smtp-Source: APXvYqzX5I4M7gO/x0djeK61HFsAhJ/sM746jVcHoPgoN+vDqJRN5Ohcnhy+s8chR4qTFvVfqfQerA== X-Received: by 2002:a5d:480b:: with SMTP id l11mr412841wrq.129.1579539534338; Mon, 20 Jan 2020 08:58:54 -0800 (PST) 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 y6sm46934845wrl.17.2020.01.20.08.58.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jan 2020 08:58:53 -0800 (PST) Date: Mon, 20 Jan 2020 16:58:52 +0000 From: "Leif Lindholm" To: devel@edk2.groups.io, rfc@edk2.groups.io Subject: [RFC] code-first process for UEFI-forum specifications Message-ID: <20200120165852.GU15141@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 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.