Thank you for the discussion on this. I propose to go ahead and add a
new ~ubuntu-sru-uploaders team that can upload to any main or universe
package in any stable release in the usual way, but not to the
development release. The team would owned and managed by the DMB through
the usual application process. I believe the DMB has the remit to do
this, so I'm now asking for a DMB vote.
My reasoning is as follows:
* We have a number of people who want to upload SRUs for packages in
main, but haven't yet got core dev. But I am confident in granting
some of them this new ~ubuntu-sru-uploaders membership, and their
contributions would be valuable to the project, speed up SRUs that get
unnecessarily delayed at the moment, and unblock sponsors.
* SRU uploads would still need to have the bug fixed in a development
release first. No change in process there. ~ubuntu-sru-uploaders
generally won't be able to do this directly and will need sponsorship.
However, I still think ~ubuntu-sru-uploaders would be valuable.
They'll only get stuck in the sponsorship queue once, instead of for
each SRU. If there's review feedback from ~ubuntu-sru, or if a
security upload trumps the SRU, then the loop will be tighter and thus
quicker.
* I think that this also provides smaller steps and more exposure to
Ubuntu development for contributors to work their way up.
* I feel that as long as we have core dev, MOTU and PPU separate, it
doesn't make any sense to grant core dev to applicants who need to
upload SRUs to main and who understand Ubuntu development processes.
If we did this, then why have MOTU and PPU at all, instead of just
making them all core devs? By definition, as long these divisions
exist, we must have some differing requirements and criteria in
granting applications. And as long as we do that, there are always
going to be applicants to whom we are not confident in granting core
dev, but are confident in their SRU uploads. I don't see any other
path that is self-consistent other than to remove the distinction and
make everyone binary (upload anything or upload nothing). I don't have
any particular objection to considering that idea either. I do think
that either we must remove the divisions or we must accept that some
worthy contributors will not be able to upload because we don't have
ACL lines drawn finely enough. Since we aren't considering removing
the divisions right now, ~ubuntu-sru-uploader seems like a much
easier, less disruptive and less objectionable path to making ACLs
finer in order to better get contributions from a group I think is
significant enough for this to be worth it.
If we don't agree to this, then I think I'm going to be stuck. I believe
there will be applicants to whom I will be reluctant to grant core dev
(so will be -1), would be confident in granting ~ubuntu-sru-uploader but
will be unable to do so.
In answer to some concerns in response to feedback:
* I believe that it is as straightforward to implement this as a
packageset. The DMB would create the team and the TB would tweak
(once) the ACL bits for us like they do for new PPU uploaders today.
If it later turns out to be less straightforward, then I will want to
rethink my proposal.
* I believe there are multiple contributors ready for this status today,
who currently get blocked, so it would immediately be useful. There
has been positive feedback from STS that they would like this.
* I don't think this would increase the burden on ~ubuntu-sru at all. I
think we should only give this to people we trust can do SRUs
correctly and with high quality, and have a track record in doing so.
I'm only looking to remove requirements that clearly don't apply to
SRUs, but do to core devs. If, in the DMB's judgement of the
requirements that are left, a candidate doesn't meet them, then I'd
encourage the DMB to vote -1 for SRU uploader anyway.
DMB members: please vote on creating ~ubuntu-sru-uploaders by responding
to this thread. Further discussion, including opinions from non-DMB, is
always welcome.
rbasak: +1
