On Fri, Mar 19, 2010 at 06:44:23PM +0000, Clint Adams wrote:
> I had meant to send three sets of questions on Thursday morning, but
> things kept coming up, so I will send an unfinished one now.
Well, thanks anyhow, this is a heck of a question! I start answering by
exposing what I think should be the general principle governing our
infrastructure, then I'll delve in your specific questions.
Let's start thinking at the package maintenance model. Each package has
either a single maintainer or a maintenance team; nevertheless all DDs
can upload all packages of the archive. In such a potentially anarchic
model, it is the sense or responsibility that keeps things going
well. While I personally *can* NMU, say, an X.org driver or a Common
Lisp library (of both I know very little), I generally don't do that
unless I'm sure I know what I'm doing (e.g. I'm fixing some packaging
issue which has nothing to do with the specific nature of the package).
That model can also be found in VCS (not only Debian's) where a lot of
people have commit write access, but each one has only knowledge/duties
on specific code areas. (In fact I've been pushing for adopting a
similar model for packaging several years ago [1], with not so much
success. Nevertheless there are some packages in the archive to whose
VCS any DD can commit; a recent wonderful example I've actually used
exploited is "dctrl-tools", see its README.Debian.)
I believe we should adopt such a model in most of our project technical
activities. When I my platform I mention that I believe we should
"diminish strong package ownership", it is this model applied to
packaging. Having it applied elsewhere is a worthwhile goal too (mind
you, a goal that the DPL alone has not necessarily the powers to
achieve, though).
[1] http://upsilon.cc/~zack/blog/posts/2007/08/DD_wide_commit_on_alioth/
There are a couple of issues with generalizing this model though. First
of all I do not believe it is fully general (see my answer to question
(3)). Additionally, if we want this model to spread more, we need ways
to counter abuses and we need to be credible in applying them.
I stress the latter point because with package maintenance we have a bad
track record in dealing with maintainers which do not reply or generally
do not maintain their packages properly anymore. Will we be able to
counter the equivalent of those problems in other project area? I don't
know, but it is worth trying.
> 1) 114 people have commit access to webwml. Given that version
> control makes it easy to undo changes, minimizing risk and impact, are
> there any legitimate reasons why this repository should be restricted
> to a group any smaller than the whole of gid 800?
No. However I surely don't want to see commit/editing "battles" going
prime time on www.debian.org. That website is meant to be our face on
the web, it deserves more caution than that. So, while DD-wide commit
access write is probably fine, the act of "uploading" the result of
commits should be more conscious. That does not necessarily mean that it
should be restricted, but it should be clear that it has an important
effect (as much as it is clear the difference between committing to a
package VCS and uploading the resulting package to the archive).
It has been observed in this thread that one need to know what he/she is
doing when committing. Sure, but that is the case also when doing an
NMU. The point is giving out responsibilities and make people aware of
the results of their actions, eventually blocking them a posteriori.
[ Disclaimer: I don't know the technical setup of www.d.o, so I don't
know if there is a different between commit time and publish time.
Until I fix this ignorance of mine, that would surely block me from
committing, for instance :-) ]
> 2) wanna-build access is restricted to a small number of developers,
> but there is no uncorrectable damage that can be caused by someone
> making mistakes. Is there any legitimate reason that wanna-build
> access should be restricted to any group smaller than the entirety of
> gid 800 membership?
No, not in principle.
There might be technical reasons though. Wouter for instance has
detailed the technical reason for that to exist in the past. It occurs
to me that until the buildd queue guarantee some form of fairness
(i.e. all packages eventually get a chance to be built) having lots of
DDs scheduling arbitrarily builds can starve certain batches of packages
and/or architectures. And in such a case, there will be no single DD to
blame: a chaotic set of individual well-meant actions can have a bad
effect, and past history shows that just sending out announcements like
"please don't do X until ..." don't work.
In case there are technical reasons (i.e. bugs) that block opening up
some access restrictions, I believe we should advertise them and then
have as high priorities the fix of those bugs. That, however, does not
magically make the bug go away.
> 3) An ftpmaster cabal of times long past used to use the phrase
> "mirror pulse" to justify oppressing the freedom of other developers,
> but we do not hear those words used much anymore. However, the word
> "trusted" has continued its prevalence in situations where one
> developer is considered better than another. Is there any legitimate
> reason why one DD should be considered more "trusted" than another
> without having earned such trust?
I too don't get the reference to the past, but the general question is
clear. My answer to that is "no".
Still, I don't want to confuse trust with task assignments. For
instance, DPL delegates get assigned specific tasks and while they are
not more trusted than others, they are responsible for the tasks
assigned to them. In some specific cases, tasks come with extra
requirements, such as specific skills. In a project as big as Debian, I
surely don't want for instance every DD to be a member of DSA, partly
because not all of us are expected to have sysadm skills, partly due to
the least privilege principles. I admit that the only other similar
example that comes to my mind is keyring maint, because it controls the
security flow between the project and final users.
> 4) The tech-ctte has the power to appoint its own members. I do not
> know why they should be allowed to self-manage when their judgment on
> the issues raised to them has often been less-than-stellar. It is
> also accepted that core teams should have the same power, and one
> common claim is that the team members have the right to exclude anyone
> who does not get along with them or agree with their approaches. Is
> there any legitimate reason why core teams should be allowed to select
> their own members with or without external oversight?
You seem to be assuming here that self-team-appointment is a special
case. In fact, I don't see it as any different than package maintenance:
I won't simply go and add myself as an Uploader of a package, I
generally _ask_ the current maintainer or team and, with their
agreement, I add myself. In general, it is a sane strategy and the
"getting along together" is an implicit part of it (at maintainer
discretion).
In the case of core teams I admit that it sounds odd at a times. First
of all it is not always clear which (part of) the core teams are DPL
delegates and which are not. About that, I've written in my platform my
intention of clarifying that, to have it clear(er) to everybody under
which authority someone is acting as part of a core team. This is not a
political nitpick or anything, it is just a way of having things written
down straight: I don't think blurry power assignments are any good for
our project.
With that is clear, I believe there is nothing wrong with team
self-assignments (of non delegates, by definition) as long as the
entrance rules are clear and as long as they do not "cause harm" to the
project. An example of causing harm would be a lot of work that need to
be done by a specific team, a lot of people willing to join the team,
and the work staying there undone. That would be a situation in which
the DPL should intervene, possibly changing delegations.
The case of CTTE is special, since it is carved in the stone of our
constitution. About the "less-than-stellar judgements" I just note that
DDs have the power to undo/change any CTTE change by the means of a GR;
people that believe the CTTE made wrong choices in specific cases,
should have used that mechanism.
> 5) Is there any part of Debian that should be restricted to a small
> subset of developers, and if so why?
Wrapping up, I believe that with a few security exceptions, there should
be none. To get from here to there however, we might need to solve
technical problems and, more importantly, to decide on how to deal with
people that abuse of their rights.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature