Refresh the existing Snapd special case documentation#542
Refresh the existing Snapd special case documentation#542ernestl wants to merge 5 commits intoubuntu:mainfrom
Conversation
|
The path is |
enr0n
left a comment
There was a problem hiding this comment.
I left an initial, incomplete review.
I have a couple of general impressions that apply to the whole document, and may not be explicitly called out already:
- There is a lot of additional information that is outside the scope of SRU. E.g. about development releases, point releases, sponsorship, etc. I am not sure this belongs. The larger this document is, the harder it is to review and agree on exactly what exceptions have been granted.
- Certain information seems duplicated or redundant in places. E.g. the point about a single SRU bug. It would be helpful to try and consolidate information and not repeat things.
| All SnapD releases, regardless of the exact category, are required to comply | ||
| with the same thorough QA process. | ||
|
|
||
| Deviations requiring sign-off |
There was a problem hiding this comment.
When you say "requiring sign-off" here, do you mean "needs an approved SRU exception" (i.e. this document)?
| - Flexibility during the development cycle (LTS or otherwise) to release major | ||
| or minor releases between feature freeze and BETA freeze. In general SnapD | ||
| releases may land in stable Ubuntu releases at any time which makes strictly | ||
| adhering to the feature freeze counterproductive. |
There was a problem hiding this comment.
The development cycle is out of scope for SRU. I don't think this should be mentioned in this document. It might give the impression that this document is granting a standing freeze exception, which the SRU team does not have authority over.
| - Flexibility with `LTS point releases | ||
| <https://wiki.ubuntu.com/PointReleaseProcess>`_ to release up to the release | ||
| date minus 14 days. |
There was a problem hiding this comment.
Ditto here. Point releases are out of scope of the SRU team, and are handled by the release team.
| - The SRU will be done with a single process bug, instead of individual bug | ||
| reports for individual bug fixes. |
There was a problem hiding this comment.
As a point of clarity - any bug that you include the changelog for the upload is expected to have an SRU template, and is expected to be verified in the normal process.
Having a single bug for snapd SRUs seems reasonable though. I just want to point this out because it was a source of confusion on the recent SRU.
I am not sure the document needs to be changed to reflect this point, but maybe it would be helpful to say "The SRU may be done with a single process bug. Any additional bugs referenced in the changelog are expected to follow standard SRU procedure" or something. Up to you.
There was a problem hiding this comment.
Hm, maybe this is already explained below. But then it makes me wonder if there is some redundancy throughout this document related to process.
| - Sponsors must review the SnapD source package and resulting deb packages in the | ||
| SnapD Team owned *ppa:snappy-dev/image* and sponsors upload to *-unapproved* | ||
| queue from where the SRU team takes over, including further reviews. | ||
| - Sponsors, the Ubuntu Release Team, and the SRU Team are not required to review | ||
| all source changes, only those related to packaging and systemd/service | ||
| integration. These changes must be clearly identified in the SRU bug. |
There was a problem hiding this comment.
Similar to above. Since this document is about SRUs, we should keep the scope limited to SRU.
|
|
||
| .. _ref_sru_template: | ||
|
|
||
| SRU Template |
There was a problem hiding this comment.
The below doesn't look like a typical SRU template. Please be sure to use the standard sections (Impact, Test Plan, Where problems could occur).
Of particular importance in this case, in my opinion, is the test plan. I would like it to be very clear what testing exactly the SRU team should expect, and how/where we can see the results.
There was a problem hiding this comment.
I guess that's below in "Final Testing Feedback." So, please re-format it in the usual SRU template for clarity.
| The SRU should be done with a single process bug, instead of individual bug | ||
| reports for individual bug fixes. Individual bugs should be referenced in the | ||
| changelog, and each bug needs to be independently verified and commented on for | ||
| the SRU to be considered complete. Refer to the :ref:`SRU template | ||
| <ref_sru_template>` for details about the required documentation. |
There was a problem hiding this comment.
This information (the note about a single process bug) is mentioned a few times. Can we try to consolidate?
Description
BACKGROUND:
Snapd team was asked to refresh the existing Snapd special case documentation (last updated 2016-05-12).
We have now completed the refresh, and completed snapd internal reviews as well as reviews by select members of the Ubuntu Development Team and SRU team.
As documented, the Technical Board delegated approval of Snapd SRU Special Case Documentation to the SRU team.
See: https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#snapd
However, we have been advised that it would be best again run it past the Technical Board for approval to be sure everyone remains up to date with the exceptions and its implications which is discussed in more detail in the updated document.
REQUEST:
We have been advised to open a documentation PR, as a good way to present the replacement document to all reviewers and the Technical Board.
Initial work was done in launchpad:
This version was discussed by the technical board, then we had a meeting including representatives from TB, SRU team, Ubuntu Team and Snapd Team on 24 March. We agreed conceptual changes.
This includes the attempt capturing at the agreed conceptual changes.
This rendering of V2 shows the conceptual changes relative to V1 highlighted: https://drive.google.com/file/d/1fPx1niZlmx4PtgCLgIzb7HidL8PacXv5/view?usp=drive_link
Snapd Jira: https://warthogs.atlassian.net/browse/SNAPDENG-36648
Needs internal approval from:
Requires external approval from:
Issue
#543
Checklist
Additional notes (optional)
Add any extra information or context that reviewers may need to know. This could include testing instructions, screenshots, or links to related discussions.
Thank you for contributing to the Ubuntu Project documentation!