|
# Overview
|
|
# Overview
|
|
|
|
|
|
This page sets out TC LI's process for using the Forge as part of the normal ETSI CR process.
|
|
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:
|
|
It consists of the following stages:
|
|
|
|
|
|
- [Overview](#overview)
|
|
* [Overview](#overview)
|
|
- [Preparing for a meeting](#preparing-for-a-meeting)
|
|
* [Preparing for a meeting](#preparing-for-a-meeting)
|
|
- [Drafting a CR](#drafting-a-cr)
|
|
* [Drafting a CR](#drafting-a-cr)
|
|
- [Submitting a CR to a meeting](#submitting-a-cr-to-a-meeting)
|
|
* [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)
|
|
* [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-meeting treatment of agreed CRs](#post-meeting-treatment-of-agreed-crs)
|
|
- [Post-plenary procedures](#post-plenary-procedures)
|
|
* [Post-plenary procedures](#post-plenary-procedures)
|
|
|
|
|
|
# Preparing for a meeting
|
|
# 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 [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):
|
|
The branch name follows the [branching convention](Conventions/Branching-convention):
|
|
|
|
|
|
meeting/{meeting title}/
|
|
```plaintext
|
|
|
|
meeting/{meeting title}/
|
|
|
|
```
|
|
|
|
|
|
> **Example**:
|
|
> **Example**:
|
|
>
|
|
>
|
|
> CRs considered at **LI#61** (2022-09-20) may be agreed at that meeting.
|
|
> 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`
|
|
> 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.
|
|
> 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
|
|
# 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) 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.
|
|
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.
|
|
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).
|
|
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}
|
|
```plaintext
|
|
|
|
{deliverable} CR {CR number} – {CR title}
|
|
|
|
```
|
|
|
|
|
|
The MR should also have the following settings:
|
|
The MR should also have the following settings:
|
|
|
|
|
... | @@ -46,82 +51,99 @@ The MR should also have the following settings: |
... | @@ -46,82 +51,99 @@ The MR should also have the following settings: |
|
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.
|
|
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**
|
|
> **EXAMPLE**
|
|
>
|
|
>
|
|
> A [CR Author](Process/CR-Authors) wishes to contribute a CR to **TS 103 280** for **LI#60**.
|
|
> 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**.
|
|
> 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**.
|
|
> The CR will be considered at the next plenary meeting, **LI#60**.
|
|
>
|
|
>
|
|
> Given this information, the [CR Author](Process/CR-Authors) creates the following:
|
|
> Given this information, the [CR Author](Process/CR-Authors) creates the following:
|
|
>
|
|
>
|
|
> A new CR branch:
|
|
> A new CR branch:
|
|
> * Name: `cr/103280/0987`
|
|
>
|
|
> * Baseline: `meeting/LI60`
|
|
> * Name: `cr/103280/0987`
|
|
>
|
|
> * Baseline: `meeting/LI60`
|
|
|
|
>
|
|
> A new MR:
|
|
> A new MR:
|
|
> * Source branch: `cr/103280/0987`
|
|
>
|
|
> * Target branch: `meeting/LI60`
|
|
> * Source branch: `cr/103280/0987`
|
|
> * Title: `"TS 103 280 CR0987 – My proposed change"`
|
|
> * Target branch: `meeting/LI60`
|
|
|
|
> * Title: `"TS 103 280 CR0987 – My proposed change"`
|
|
> * Assignee: The CR author
|
|
> * Assignee: The CR author
|
|
> * Delete source branch when merge request is accepted: **No**
|
|
> * Delete source branch when merge request is accepted: **No**
|
|
> * Squash commits when merge request is accepted: **Yes**
|
|
> * Squash commits when merge request is accepted: **Yes**
|
|
|
|
|
|
|
|
|
|
# Submitting a CR to a meeting
|
|
# 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.
|
|
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).
|
|
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).
|
|
|
|
|
|
|
|
For consistency, the CR contributor should adopt the following convention for entering these details into the "Other comments" box:
|
|
|
|
|
|
|
|
* Include a link to the Merge Request, with the Merge Request number as the display text
|
|
|
|
* Include a link to the latest commit in the CR branch, with the hash of the commit as the display text.
|
|
|
|
|
|
|
|
An example is given below:
|
|
|
|
|
|
|
|
![image](uploads/c3faf3660e79df93360ce6fec36be228/image.png)
|
|
|
|
|
|
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.
|
|
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.
|
|
> There is an experimental tool provided for delegates to generate change-marked text from Forge MRs - contact [@canterburym](/rep/canterburym) to find out more.
|
|
|
|
|
|
# Consideration of the CR at the meeting
|
|
# 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.
|
|
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.
|
|
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.
|
|
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.
|
|
> 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
|
|
# 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:
|
|
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 branch is **not deleted**.
|
|
* Source commits **are squashed**.
|
|
* 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.
|
|
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:
|
|
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
|
|
* 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
|
|
* 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).
|
|
* 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.
|
|
* 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.
|
|
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
|
|
# 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:
|
|
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**.
|
|
* Source branch **is deleted**.
|
|
|
|
* Source commits **are not squashed**.
|
|
|
|
|
|
> IMPORTANT! this is the opposite to the settings used by the CRs themselves.
|
|
> 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):
|
|
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 for each deliverable agreed for publication at the plenary meeting
|
|
* A tag indicating the output of 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.
|
|
> 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.
|
|
The [Maintainer](Process/Maintainers) removes the meeting branch and any remaining CR branches.
|
|
|
|
|
|
>**EXAMPLE**
|
|
> **EXAMPLE** After **LI#60**, new versions of **TS 102 232-1** and **TS 102 232-5** are agreed for publication.
|
|
> After **LI#60**, new versions of **TS 102 232-1** and **TS 102 232-5** are agreed for publication.
|
|
>
|
|
>
|
|
|
|
> **TS 102 232-1** is agreed at **3.27.1**, and **TS 102 232-5** is agreed at **3.16.1**.
|
|
> **TS 102 232-1** is agreed at **3.27.1**, and **TS 102 232-5** is agreed at **3.16.1**.
|
|
>
|
|
>
|
|
> After merging the `meeting/LI60` meeting branch back into `main`, the [Maintainer](Process/Maintainers) creates the following tags for the head commit:
|
|
> After merging the `meeting/LI60` 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/LI60`
|
|
> * A tag for the meeting output named `output/LI60`
|
|
> * A tag for the newly-published TS 102 232-1 spec named `spec/102232-1/3.27.1`
|
|
> * A tag for the newly-published TS 102 232-1 spec named `spec/102232-1/3.27.1`
|
|
> * A tag for the newly-published TS 102 232-5 spec named `spec/102232-5/3.16.1` |
|
> * A tag for the newly-published TS 102 232-5 spec named `spec/102232-5/3.16.1` |
|
|
|
\ No newline at end of file |