-
Notifications
You must be signed in to change notification settings - Fork 57
WIP: DMB add package set handling to official content #364
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
I've worked through the links, references, spelling checks and a bit more on the phrasing. Should now be ready for review - marking as such... |
8454d21 to
b924467
Compare
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
Co-authored-by: Benjamin Drung <[email protected]>
Suggested-by: Benjamin Drung <[email protected]> Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
b924467 to
1899462
Compare
Signed-off-by: Christian Ehrhardt <[email protected]>
Signed-off-by: Christian Ehrhardt <[email protected]>
|
Fixed the broken redirection (thanks Sally), improved a bad paragraph that I found and added a flowchart to explain the basic data relation visually. Rebased and re-pushed |
|
@basak I was hoping you'd have a chance for this (plus my potential follow up) before our DMB meeting on Monday 19th, so that afterwards I could update and act on the package list for server accordingly. I hope that just means you are busy and not totally opposed on how I tried to describe the split for logical/seeded lists :-) |
basak
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry, I thought I'd already submitted this review :-/
|
|
||
| ```{note} | ||
| This page is about how to create and modify a package set. | ||
| The related info about how to become a developers that is an uploaders |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The plurals "developers" and "uploaders" in this sentence don't parse for me. How about "Related information about how to become an uploader of a package set can be found..." if that's what you mean?
| @@ -0,0 +1,241 @@ | |||
| (dmb-manage-package-sets)= | |||
| # DMB Manage Package Sets | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Traditionally packageset has been an unhyphenated combined proper noun to me with no space. It seems unnatural to me to see it as "package set" with a space. This applies in many areas of this PR I think, but I'll only mention it once. I don't really mind if you want to consistently use it this way in all documentation but thought I'd mention it.
| upload permissions to such a set. | ||
|
|
||
| Being per release allows them to evolve over time as Ubuntu changes, without | ||
| such changes affecting the maintenance of existing releases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "allow" is generous. I always assumed that it's because the meaning of a source package can change between release (eg. the git package used to mean some other software like a radio thing a long time ago), so therefore semantically a packageset must apply to a specific release. But it's in practice always a pain - apart from the git example, I can't think of any time we'd want to actually apply a packageset differently between series.
| * The grouping of those packages needs to make logical sense. | ||
|
|
||
| The application process to {ref}`dmb-become-package-set-uploader` is similar | ||
| to all other developer upload right applications. In this case applying to a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I try to avoid "right", since that sounds to me like something people should have like "human rights" or "right of way". I prefer "permission" or "access". But I'm not precious about this. For documentation we should settle on something consistent.
| ## Two types of package sets | ||
|
|
||
| Historically there are two kinds of package sets, those that mostly reflect | ||
| seeds and those that are logically defined by their description. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a couple of other types now (from https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Special_packagesets): personal glob-based packagesets, and the Canonical oem metapackage sets.
|
|
||
| * Consider to add a package to a set if it is not in the seeds, but such a | ||
| common use case for the package set that the same set of people that care | ||
| about the rest is likely to also maintain these packages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This third case would be a departure from our current norm and make it more difficult to switch to automatic maintenance of this type of packageset in the future. Are we sure we want to do this?
What happens if the package is then seeded somewhere else that has its own seed-based packageset? Should it end up in both automatically generated packagesets?
|
|
||
| ### How to modify a Package set definition | ||
|
|
||
| * If necessary, we can modify the description later on following a full DMB vote. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably this is only for logical-type packagesets? It should be mentioned that the DMB should consider if the new definition would remain appropriate for both 1) the set of packages in the packageset, and if they should be adjusted; 2) the set of uploaders to the packageset, and if they should be adjusted.
Description
While discussing the changes to the server package set we realized we'd like to document that there are two types, logical (defined by description) and seed based package sets. In the long past seed based lists were generated, but that had issues, but-rot and also sometimes one wanted to add/remove some. Therefore for now this described how non-generated lists can be maintained better by describing how the DMB wants to treat them.
While getting to that I found that we didn't yet leverage the related content out of the staging area, it was still as it was in the wiki without any rewrite.
The following is picking, placing and overhauling what I think would be useful to have.
And then adding the explanation and examples how seed based sets could be checked