@@ -74,10 +74,38 @@ like Personal packagesets and OEM metapackage packagesets.
7474 A DMB member then needs to judge the description against the requested change
7575 and may apply the change if they decide it is warranted.
7676
77- * ** {ref}` seeds ` based Packagesets** are instead * mostly* defined by what is
78- seeded for a particular Ubuntu variant. That is not strictly only and exactly
79- the content of an ISO or image, but might also include related supported seeds
80- that represent common use cases that are not default installed.
77+ * ** {ref}` seeds ` based Packagesets** are instead defined by what is
78+ generally seeded and supported for a particular Ubuntu variant or has a
79+ direct relation to a seed named in the desciption.
80+ One has to be careful as there are exceptions that force a seed based
81+ packageset seeds to not be just equal to the seed.
82+ defies the purpose (See below about details on these cases).
83+ * These packagesets used to be fully generated based on
84+ [ this code] ( https://code.launchpad.net/~developer-membership-board/+git/packageset )
85+ and the logic tries to detect how sources are shared between flavours to
86+ remove those. But that has proven to cause to cause too many exceptions.
87+ Therefore they have - for now - become defined by the seeds, but modified
88+ manually on request.
89+ * While currently not automated, the DMB still aims for * eventual
90+ consistency* . A seed based packageset should converge to be based on the
91+ seed, plus exceptions (previously maintained in the script in git).
92+ Just like packagesets based on a logical definition converge on the text
93+ of their definition.
94+ * Common reasons for exceptions to a pure seed = packageset approach are:
95+ * Consider to remove a package from a set if is is in the related seed, but
96+ so central and impactful, that adding it would effectively make the
97+ Packageset to require core-developer permission level. That would defy
98+ the purpose of being a stepping stone for upload permissions as on one
99+ could join until the could get core-developer rights anyway.
100+ Examples of that would be: grub2, systemd, or cloud-init.
101+ * Consider to remove a package from a set if it is also claimed by other
102+ seeds or common use case. In that case it often, but not always, is only
103+ updated by Ubuntu core-developers.
104+ Examples of that would be: vim, dhcpcd or tzdata
105+ * Consider to add a package to a set if it is not in the seeds, but such a
106+ common use case for the Packageset that the same set of people that care
107+ about the rest is likely to also maintain these packages.
108+ Examples of that would be: docker.io
81109
82110* ** Personal Packagesets** are used where an individual has a special reason for
83111 upload rights to a large number of packages that the DMB expects to need to
@@ -107,50 +135,6 @@ like Personal packagesets and OEM metapackage packagesets.
107135
108136### Why are seed based Packagesets not generated?
109137
110- These used to be fully generated based on
111- [ this code] ( https://code.launchpad.net/~developer-membership-board/+git/packageset )
112- and the logic how sources are shared between flavours. But that has proven to
113- cause too many rough edge cases. Therefore text above says "Mostly" as there
114- are often are a few packages that make sense to be added or removed when
115- compared to the pure list that would come out of the seeds to make it more
116- practical.
117-
118- Such cases could be:
119-
120- * Consider to remove a package from a set if is is in the related seed, but so
121- central and impactful, that adding it would effectively make the Packageset to
122- require core-developer permission level. This not only reduces impact, it also
123- avoids that all Packagesets are very hard to join as they need core-dev
124- like requirements to join as an uploader.
125-
126- * Consider to remove a package from a set if it is also claimed by other seeds.
127- In that case it often, but not always, is only updated by Ubuntu core-developers.
128-
129- * Consider to add a package to a set if it is not in the seeds, but such a
130- common use case for the Packageset that the same set of people that care
131- about the rest is likely to also maintain these packages.
132-
133- If in doubt it is worthwhile to compare a few sets of data to make decisions
134- what might need to be added or dropped from a Packageset. Here an example
135- for the ubuntu-server team:
136-
137- * Fetch the current Packageset like ` ./edit-acl query --series resolute --packageset ubuntu-server `
138- * Look at the seeds
139- * To do so fetch [ ubuntu seeds] ( https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/ )
140- and [ platform seeds] ( https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/tree/ ) ,
141- to then check for anything related to server.
142- * Or check the [ germinated output] ( https://ubuntu-archive-team.ubuntu.com/germinate-output/ubuntu.resolute/ )
143- for an artifact you are interested in.
144- * Yet one has to admit that seeds are hard to read, because they are expanded by
145- dependencies and evaluated for various slightly different artifacts.
146- Gladly what you need to compare, is often nicely approximated by checking what
147- a team with the a related responsibility is subscribed to. And if they are
148- not subscribed despite being in the germinated seed it would often be a case
149- of overlapping responsibilities that suggest core-developer rights anyway.
150- Therefore consider ` curl --silent http://reports.qa.ubuntu.com/m-r-package-team-mapping.json | jq -r '."ubuntu-server"[]' `
151- to be the most simple solution.
152- * Out of such a three way comparison in an example of 2025 we generated and discussed [ this list] ( https://lists.ubuntu.com/archives/devel-permissions/2025-September/002906.html )
153-
154138(dmb-modify-packagesets)=
155139## How to modify a Packageset
156140
0 commit comments