DMB add package set handling to official content #364
Conversation
cpaelzer
requested review from
athos-ribeiro,
julian-klode,
lvoytek,
rkratky,
s-makin and
utkarsh2102
as code owners
|
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... |
cpaelzer
force-pushed
the
dmb-add-package-set-handling
branch
2 times, most recently
from
b924467 to
1899462
Compare
|
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
basak
left a comment
There was a problem hiding this comment.
I'm sorry, I thought I'd already submitted this review :-/
|
|
||
| * 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.
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?
There was a problem hiding this comment.
I see your point, but that is an aspect I oppose and worth for discussion in the DMB as a whole.
Due to the lack of volunteers to bring automation into a non-rough state my stance here is that I've given up on automation of this for now. I have seen and can think of so many special cases that I'd assume even if automation is created again, it should only create a list of suggestions what should be added/removed to then be discussed.
To be clear - I will be happy to change the rules if that ever changes and we have a truly reliable codified approach to this that we want to rely on.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Co-authored-by: Benjamin Drung <bdrung@ubuntu.com>
Suggested-by: Benjamin Drung <bdrung@ubuntu.com> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Co-authored-by: Robie Basak <robie.basak@ubuntu.com> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
This reworks the former change, the intention was to make it consistent and review has shown that the single word form is preferred. Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
cpaelzer
force-pushed
the
dmb-add-package-set-handling
branch
from
8b21d36 to
380d0a3
Compare
|
We had two pre-reviews (thanks!) and I handled all feedback that came up. I'll mark it as non-draft to reflect that and will try to insert it into the Agenda for discussion, landing and then unblocking any dependent acting. |
cpaelzer
changed the title
|
@s-makin I've added your findings, could you please re-check if anything else is left - that way we might have your pre-ack so we can merge it if we agree at the DMB meeting as-is or with non-huge changes. |
5 participants
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