I’ve been asked by the Ubuntu Technical Board following a discussion I had about snapd a few meetings ago to draft an official policy regarding adding daemons to the desktop-common seed.
It almost seems obvious that there should be some sort of policy for adding daemons to the seed that we all (including Ubuntu Desktop) pull in. But, there is not one at the moment, and any Ubuntu Core Developer (or anyone who might have commit access otherwise) can add things there. I will draft actual wording Soon, but here is what the procedure should be for additions or removals in my opinion:
An email needs to be sent to the ubuntu-release mailing list with the rationale for adding or removing the daemon, details about the package itself. (Is it in Main or Universe? How large is the package? What about runtime dependencies?)
An “aging period” of one week should be allowed for flavors or the Desktop Team to reply with an objection, if they have any. (If clarification is required, that shouldn’t extend the time.)
After that aging period, assuming no blocking objections have been raised, it can be committed to the branch with a link to the mailing list thread.
Does anyone think this should be tweaked?
If not, I’ll draft something more formal and send it to the TB mailing list tomorrow or the next day.
Given the negative impact an unexpected addition to a common seed could have, I think there should actually be a similar process in place to add anything to such seeds.
I think there should actually be a similar process in place to add anything to such seeds.
I asked @vorlon in #ubuntu-meeting-2 (after the TB meeting) why we decided on it being daemons instead of all packages for this proposal (it’s been over a month and we’ve had a release…) and he cited the reason I brought this up in the first place (snapd being added without anyone being asked first) among other things.
I would be curious to hear your full (more formal (than IRC)) thoughts on this, @vorlon.
I’m in favor of having a process established. I don’t see any issues with what has been proposed. The only concern might be the 1 week vs if someone misses this on the mailing list (email volume, etc).
I think this hits the highlights of what such a policy should be.
I think 1 week should be long enough to wait for objections before making the change, but that if the goal is we want unanimity among the flavors, later objections should be grounds for a revert as well. (Having to wait longer than 1 week for objections means potentially slowing down development during the cycle; and this is on ubuntu-release, which is not high-traffic at all.)
By the time a package is a candidate for inclusion in desktop-common, it’s already in main or has an approved Main Inclusion Request. There should be no reason to re-adjudicate this among the desktop flavors, since the question here is one of desktop-common vs. some other ubuntu-desktop-specific seed.
If the intent is that any desktop flavor can veto a package’s inclusion, perhaps state that explicitly (“blocking objection” seems a bit opaque?)
I have no strong opinion about whether non-daemon additions to desktop-common should also follow the same policy. Perhaps such changes should also be announced on ubuntu-release, but should not necessarily require a waiting period (if someone objects, it should always just be a revert away).
