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

Two GR concepts for dicussion

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

	- 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?


Attachment: signature.asc
Description: Digital signature

Reply to: