Hey all, As a slight distraction from other discussions going on, I'd like to throw a couple of ideas out there for consideration, particularly with debconf coming up and a chance for many of us to discuss things in person. First, the "Debian Maintainers" concept, ie giving limited upload access to people prior to, or instead of, them becoming developers. For this to be useful, the process should be lightweight, but still provide a good means of ensuring we (and our users) can maintain our trust in the packages that get uploaded. I think the process should involve: - automated application process - as close as feasible to automated keyring maintenance - policies developed by consensus and implemented individually by developers, in a similar manner to policies for sponsored uploads at present, rather than an individual or group setting policy or approving applications (like DAM or NEW processing) - minimal requirements: gpg keyring signed by either one or two developers, recommendation by a developer, use of existing fields such as "Maintainer:" and "Uploaders:" to control access, no provision for uploaders to do NMUs or upload NEW packages etc Both Joerg (DAM) and James (DAM, DSA, ftpmaster, keyring-maint) objected to me pushing ahead with this a couple of months ago [0], and not much was achieved after it was discussed at debconf last year either, ttbomk. My best summary of Joerg's objections are: - having me be pushy about it, particularly in the lead up to a DPL election in which I'm a candidate, doesn't work - there isn't a sufficiently concrete plan - it's taking over some of the DAM role (in principle if not precisely in practice) so should be done with DAM's approval and support - there should be a general consideration of other DD priveleges (voting, machine access, @debian.org addresses) and having more granular control of those too Personally, I'd rather leave a general consideration of other priveleges until after we've tried generalising uploads and seeing how (if) that works, which makes me pretty reluctant to worry about the last point; and I'd like to think that you don't need to have a DAM hat (or approval) to work on improving this area of Debian, so while I certainly respect Joerg's opinion (which is why I'm trying to paraphrase and reply to it!), I'd rather that only be due to his experience and insight wrt helping newbies join Debian satisfactorily, than his current position in the project. James hasn't made his particular objections clear, apart from that it should go through keyring-maint. The thread following [0] includes various criticisms and responses too. So, the reason I call it a "GR concept" is that I think a reasonable approach would be to work out a "concrete plan" over the next few weeks, and hopefully come up with something that has a demonstrable consensus behind it, rather than just a pushy DPL candidate, a couple of cabal members, or whatever. Whatever happens, it won't be perfect, but surely we can think of and implement *something* better than what we've currently got within a few weeks. [0] http://lists.debian.org/debian-project/2007/03/msg00074.html Another thought. Sam's written about having more people in our core teams a few times, and no doubt will have more to say in the future; but a single person can only focus on helping one or two teams at any one time, and there's no limit to the number of teams that can have problems. Maybe it's worth thinking about a more general solution than DPL intervention for helping teams that have calcified to grow and improve. My idea was to have an annual round where any DD could nominate themselves to join any team -- DSA, ftpmaster, maintenance of some particular package, www team, whatever. Acceptance would be automatic, provided: * no more than three people are joining the team (if so, the existing team can select three, or the DPL can if the existing team don't) * the role isn't "core", or the person isn't already involved in two or more other "core" roles (eg, ftpmaster assistant isn't core, ftpmaster is; release assistant isn't, release manager is) * the person can demonstrate some minimal existing competence in the area * the person is willing to agree in writing to make every reasonable effort to work with the existing team (which the DPL will enumerate on request) (That's intended to be in *addition* to the existing members of a team finding people to join in and help, not instead of it.) That has two major prerequisites in order to work: that we're *all* willing to give up some of the control we're used to exercising over our domain within Debian (whether that be a package or some infrastructure or a role or whatever); and that we expect all developers individually to be willing to work productively in a team and that we're willing and able to deal with people who are a destructive influence in teams. Doing that by GR would help people understand how they can expect this to be dealt with in future, and would offer the reassurance that the project isn't out on a vendetta against a few maligned groups, but is really trying to do something that's fair on *everyone* in order to improve the project. Hey, why not? A third idea: instead of having delegates or a committee or whatever to decide amongst disputes, how about randomly selecting a jury from DDs and having their word (on who's right, on what punishment is plausible) be absolutely final, with no appeal, ever? Cheers, aj
Attachment:
signature.asc
Description: Digital signature