[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Maintainers GR Proposal - Use Cases

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

  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

·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgp9Y9Tca805_.pgp
Description: PGP signature

Reply to: