On Fri, Jun 22, 2007 at 11:03:50AM +0200, Marc 'HE' Brockschmidt wrote: > Anthony Towns <aj@azure.humbug.org.au> writes: > > 1) A new keyring will be created, called the "Debian maintainers keyring". > > It will be initially maintained in alioth subversion using the jetring > > tool, with commit priveleges initially assigned to: > > * the Debian Account Managers (Joerg Jaspert, James Troup) > > * the New-maintainer Front Desk (Christoph Berg, Marc Brockschmidt, > > Brian Nelson) > *cough* It would have been nice to inform people that you are planning > to involve them in something like this :) Having commit access doesn't imply an obligation to make use of it. > > 2) The initial policy for an individual to be included in the keyring > > will be: > > * that at least one Debian developer (preferable more) is willing > > to advocate for the applicant's inclusion, in particular to the > > fact that the applicant is technically competent and good to work > > with. > I would like to change this to "at least two", simply because I believe > that this shouldn't be an actual problem for active maintainers. Seems reasonable. Anyone think otherwise? > > 3) The initial policy for removals for the keyring will be under any of the > > following circumstances: > > * the individual has become a Debian developer > > * the individual has not annually reconfirmed their interest > > * multiple Debian developers have requested the individual's > > removal for non-spurious reasons; eg, due to problematic > > uploads, unfixed bugs, or being unreasonably difficult to > > work with. > This part is broken and shouldn't end up in a final proposal. We need to > decide on actual rules, otherwise this can lead to endless flamewars. I disagree; just as there aren't specific rules for accepting people (just developers advocating the applicant), there shouldn't be specific rules for removing people (just developers requesting their removal). We expect developers to understand the project in some depth, I don't think it's asking a lot to expect them to understand the consequences of their actions in advocating a maintainer's acceptance or removal. If you'd like to work out specific rules for either case and propose an amendment, you can, of course. > I'm not too happy with this part. My idea was always to allow people > upload rights for individual packages that have been checked once by a > full DD - and even that doesn't make me happy. If every upload is checked once by a full DD, you have the existing sponsorship process. If the package is checked once by a full DD, with later uploads being allowed automatically, you've got this process -- with the initial check process ending with "a DD adds the debian maintainter to the uploaders/maintainer field, and uploads the package to unstable". > The average (in)competence of DDs is what makes me believe that non-DDs > shouldn't get to upload whatever software they would like to > package. If you're trying to get rid of all the DDs who make (frequent) mistakes, then I guess I should be one of the first on the chopping block. IMO, and YMMV, the number of mistakes you make doesn't really matter very much, it's the amount your mistakes affect others, which you can minimise either by not making mistakes in the first place, or by fixing your mistakes afterwards. One way in which sponsorship works badly is that it imposes a large cost to getting the person who made the mistake to fix it -- they need to find a sponsor, coordinate with that sponsor, and the sponsor needs to independently verify the changes. > Anyway, something more constructive: I think that from a QA point of > view, allowing DMs to only upload packages that were once checked by > some trustworthy person is a lot better than your proposal. I'm a bit tired of dividing DDs into "trustworthy" and not, so I'm more inclined to just let every DD have the same level of trust. If you want to define a subset of trustworthy people, and propose an amendment, you can, of course. If you're not meaning to distinguish trustworthy and untrustworthy DDs, but just that you want to start with nobody pre-authorised and require all authorisation to not start until the GR passes, and not to use existing entries in Uploaders/Maintainer to authorise people, that's a different discussion. That behaviour's somewhat implied already -- *a* new upload would be needed after the appropriate changes to dak are made anyway; it'd be possible to require a "X-Allow-DM-Upload: yes" header or something as well, to be completely explicity. I don't have any real opinion on what makes more sense. Cheers, aj
Attachment:
signature.asc
Description: Digital signature