On Mon, Jun 25, 2007 at 07:45:20PM +0100, Anthony Towns wrote: > == N-M queue ================= > Authorised by: AM This one makes sense. I'd also add the sponsor in the people giving the ACK. > == Sponsored Maintainers ===== > Authorised by: Sponsor > Notes: package should generally be co-maintained by sponsor and non-DD > maintainer, with the non-DD maintainer doing most of the work If you restrict this use case to that specific case, then you won't have a lot of candidates, or worse fake ones. I co-maintain about ... 0 packages I sponsor, and I believe it's often the case. > == Upstream Maintainers ====== > Authorised by: Existing maintainer > Notes: package should be co-maintained by maintainer and upstream, upstream > generally to be expected to be uploading code changes rather than > packaging changes Again, if you require a DD to already package the software, this is quite restricting, though an interesting case that could make sense, and make Debian even more the developping platform it is already. Though, this could be quite frustrating for the upstream maintainers. Just imagine what would happened if tuomov was a DM, wanting to push ion into etch … endless trolls. > == Principled Resignations === > Authorised by: Continuing DD > Notes: voluntarily resigned from DD, so having a subset of permissions raises > no issues There is afaict 1 only person in that case ever. > == Probationary DDs ========== > Authorised by: DAM/FD > Notes: this largely serves as an alternative to delaying or rejecting > applications, and perhaps occasionally an alternative to accepting > applications that DAM/FD are uncomfortable with This sounds like case #1 to me. > == N-M Delays ================ This one suck, because NM delays are mostly fixeable, and DM will just make them not painful at all for DD, depriving the system to be fixed. This is exactly the use case I fear. That's why I'd like some efforts put in NM to fix some parts before considering DM again. As a conclusion, I don't think there is a real problem fixed with this proposal. I mean, the part where we give progressive upload rights to the NM is _great_ and can make NM queue sexy again. That rocks, and I repeated that part in my proposal to revamp some bits of NM. For the other use cases, I hardly see a dozen of people concerned, and not really that hampered in their work anyways. I mean, in every case that is not related to a NM, there is a DD that should be watching. If the package is co maintained in a SCM, it's quite easy for the DD to watch the changes, and auto-builders could be providen (with trusted environment) so that the DD would just have to sign the changes, like a buildd maintainer does. It reduces the load to the bare minimum: watching the package. And it does not require huge infrastructure changes to support ACLs and other rights managements for a handful of people. I mean some use cases may _look_ intereseting, but looking at the numbers, it looks like handwaving, with the risk to make NM stay hell forever. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgp9Y9Tca805_.pgp
Description: PGP signature