|
|
# Overview
|
|
|
This page sets out TC LI's process for using the Forge as part of the normal ETSI CR process.
|
|
|
|
|
|
It consists of the following stages:
|
|
|
|
|
|
- [Overview](#overview)
|
|
|
- [Preparing for a meeting](#preparing-for-a-meeting)
|
|
|
- [Drafting a CR](#drafting-a-cr)
|
|
|
- [Submitting a CR to a meeting](#submitting-a-cr-to-a-meeting)
|
|
|
- [Consideration of the CR at the meeting](#consideration-of-the-cr-at-the-meeting)
|
|
|
- [Post-meeting treatment of agreed CRs](#post-meeting-treatment-of-agreed-crs)
|
|
|
- [Post-plenary procedures](#post-plenary-procedures)
|
|
|
|
|
|
# Preparing for a meeting
|
|
|
The [Maintainer](Process/Maintainers) creates a [meeting branch](Conventions/Branching-convention) that represents the baseline for a plenary meeting at which a given set CRs will be agreed.
|
|
|
|
|
|
The branch name follows the [branching convention](Conventions/Branching-convention):
|
|
|
|
|
|
meeting/{meeting title}/
|
|
|
|
|
|
> **Example**:
|
|
|
>
|
|
|
> CRs considered at **LI#61** (2022-09-20) may be agreed at that meeting.
|
|
|
>
|
|
|
> Before **LI#61** the [Maintainer](Process/Maintainers) therefore creates a branch called `meeting/LI61`
|
|
|
>
|
|
|
> CRs considered at a rapportuers meeting **LI#-Rap#59** (2022-08-22) cannot be agreed there, as rapportuers meetings do not have decision power. These CRs will also be considered at **LI#60**. The [Maintainer](Process/Maintainers) does not need to create an additional meeting branch, so long as the plenary branch for **LI#60** already exists.
|
|
|
|
|
|
|
|
|
# Drafting a CR
|
|
|
The [CR Author](Process/CR-Authors) reserves a CR on the [ETSI portal](https://portal.etsi.org/#/), after having obtained a CR number from the TCLI Technical Officer.
|
|
|
|
|
|
The [CR Author](Process/CR-Authors) creates a branch specific to their CR, following the branching convention given in clause 4.2.
|
|
|
cr/[deliverable]/[CR number]. This branch is created using the appropriate meeting branch (rather than `main`) as a baseline.
|
|
|
|
|
|
The [CR Author](Process/CR-Authors) immediately creates a Merge Request (MR) for the new branch, targeting the same meeting branch. The [CR Author](Process/CR-Authors) gives the MR a title using the [rendering conventions](Conventions/Rendering-conventions).
|
|
|
|
|
|
{deliverable} CR {CR number} – {CR title}
|
|
|
|
|
|
The MR should also have the following settings:
|
|
|
|
|
|
* Assignee set to the [CR Author](Process/CR-Authors) by clicking the "Assign to me" button
|
|
|
* Source branch is **not deleted**.
|
|
|
* Source commits **are squashed**.
|
|
|
|
|
|
The [CR Author](Process/CR-Authors) (and any collaborating parties) commits the desired changes to their branch. Changes made to the CR branch are visible to anyone with access to the ETSI Forge. Delegates may comment on and, if appropriate, contribute to, the changes in the CR branch.
|
|
|
|
|
|
> **EXAMPLE**
|
|
|
>
|
|
|
> A [CR Author](Process/CR-Authors) wishes to contribute a CR to **TS 103 280** for **LI#60**.
|
|
|
> They reserve a document on the portal, and are assigned CR number **987**.
|
|
|
>
|
|
|
> The CR will be considered at the next plenary meeting, **LI#60**.
|
|
|
>
|
|
|
> Given this information, the [CR Author](Process/CR-Authors) creates the following:
|
|
|
>
|
|
|
> A new CR branch:
|
|
|
> * Name: `cr/103280/0987`
|
|
|
> * Baseline: `meeting/LI60`
|
|
|
>
|
|
|
> A new MR:
|
|
|
> * Source branch: `cr/103280/0987`
|
|
|
> * Target branch: `meeting/LI60`
|
|
|
> * Title: `"TS 103 280 CR0987 – My proposed change"`
|
|
|
> * Assignee: The CR author
|
|
|
> * Delete source branch when merge request is accepted: **No**
|
|
|
> * Squash commits when merge request is accepted: **Yes**
|
|
|
|
|
|
|
|
|
# Submitting a CR to a meeting
|
|
|
The [CR Author](Process/CR-Authors) should ensure that the current commit passes any [automated syntax and drafting rule](Automated-checking) checks before submitting the CR for consideration by the meeting. CRs which do not pass automated checking may be accepted at the discretion of the Chair.
|
|
|
|
|
|
When ready for submission, the CR contributor prepares a CR form as per the existing ETSI TC LI CR process. The [CR Author](Process/CR-Authors) places a link to both the MR and the latest commit in their CR branch in the "Other comments" section of the [CR form](Conventions/CR-form-conventions).
|
|
|
|
|
|
The [CR Author](Process/CR-Authors) includes the changes to the formal language schema as part of the CR form, using change-marked text as per the existing ETSI process. [CR Author](Process/CR-Authors)s are strongly encouraged to generate this change-marked text from the Forge, rather than attempting to keep the CR Form and Forge MR aligned manually.
|
|
|
|
|
|
> There is an experimental tool provided for delegates to generate change-marked text from Forge MRs - contact @canterburym to find out more.
|
|
|
|
|
|
# Consideration of the CR at the meeting
|
|
|
The [CR Author](Process/CR-Authors) presents both the CR form and the associated changes in the ETSI Forge to the meeting.
|
|
|
|
|
|
If the [CR Author](Process/CR-Authors) decides to revise the contribution, they makes any necessary changes by making additional commits to the CR branch. Draft CR forms may be created following the procedures above, and the uploaded to the drafts folder following the existing ETSI process.
|
|
|
|
|
|
CRs should pass automated checking before being accepted by the meeting, with exceptions being made at the Chair's discretion.
|
|
|
|
|
|
> Special attention should be given to CRs which fail the automated merge test check. This indicates that two or more CRs conflict with each other. In some cases this is unavoidable (e.g. if two CRs both add parameters to the same structure), but [CR Author](Process/CR-Authors)s should ensure that any unavoidable merge conflicts are resolved prior to agreement.
|
|
|
|
|
|
|
|
|
# Post-meeting treatment of agreed CRs
|
|
|
Once the TC LI plenary meeting is finished, the [Maintainer](Process/Maintainers) accepts the MR for each agreed CR. Before doings to, the [Maintainer](Process/Maintainers) checks that the MR has the following settings, amending them if necessary:
|
|
|
|
|
|
* Source branch is **not deleted**.
|
|
|
* Source commits **are squashed**.
|
|
|
|
|
|
After merging, the [Maintainer](Process/Maintainers) then resolves any merge conflicts, seeking assistance from [CR Authors](CR-Authors) and other delegates where necessary.
|
|
|
|
|
|
The [Maintainer](Process/Maintainers) then performs the following post-meeting steps by pushing the necessary commits directly to the meeting branch:
|
|
|
* Object Identifiers for any ASN.1 modules that contain changes are incremented
|
|
|
* XSD version tags in XSD namespaces of any XSD schemas that contain changes are incremented
|
|
|
* ASN.1 Structures with new or changes tags are checked to ensure tag numbers are sequential (unless otherwise agreed).
|
|
|
* Any contraventions of the [drafting rules](Conventions/Drafting-rules) are corrected.
|
|
|
|
|
|
The meeting branch now contains a corrected set of CRs that can be used to generate a draft version of the specification.
|
|
|
|
|
|
# Post-plenary procedures
|
|
|
Once the changes are confirmed by SA and the new version of the spec is published, the [Maintainer](Process/Maintainers) merges the agreed meeting branch into the relevant release branch with the following settings:
|
|
|
* Source branch **is deleted**.
|
|
|
* Source commits **are not squashed**.
|
|
|
> IMPORTANT! this is the opposite to the settings used by the CRs themselves.
|
|
|
>
|
|
|
The [Maintainer](Process/Maintainers) tags the head of the main branch following the [tagging convention](Conventions/Tagging-convention):
|
|
|
* A tag for each deliverable agreed for publication at the plenary meeting
|
|
|
* A tag indicating the output of the plenary meeting
|
|
|
|
|
|
> These tags make it easy to retrieve or compare specific versions of a specification, or the output of specific meetings.
|
|
|
|
|
|
The [Maintainer](Process/Maintainers) removes the meeting branch and any remaining CR branches.
|
|
|
|
|
|
>**EXAMPLE**
|
|
|
> After **SA#93e**, new versions of **TS 33.128** are agreed for publication.
|
|
|
>
|
|
|
> A Release 16 version >is agreed at **16.7.0**, and a Release 17 version is agreed at **17.2.0**.
|
|
|
>
|
|
|
> After merging the `meeting/SA93e` meeting branch back into `main`, the [Maintainer](Process/Maintainers) creates the following tags for the head commit:
|
|
|
> * A tag for the meeting output named `output/SA93e`
|
|
|
> * A tag for the newly-published TS 33.128 r17 spec, named `spec/33128/17.2.0`
|
|
|
> * A tag for the meeting output named `spec/33128/16.7.0` |