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

Re: Questions for all candidates: decentralization of power

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.
> 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; and in practice, it is a matter of "ask and get" currently. I.e., if
you're a Debian Developer, that is all the justification you need to be
able to get commit access.

As anecdotal evidence, I can submit that when I asked for my webwml
access, the webmaster who was CC'ed to ack the request first asked me
"what do you need it for", since he didn't recognize my name. When he
found out that I was, in fact, a Debian Developer, the response was
something like (paraphrasing) "Oh, sorry, didn't know that -- yeah,
sure, no problem then".

Given that, and given that there is a benefit to be had to have the
group of 'webwml access' users be distinct from the group of 'Debian
Developers' (with this setup it is possible to give people access
to the website who are /not/ Debian Developers, which is done on a
regular basis; and with this setup, only people who wish to actually use
their access will have it, which has security benefits), I don't think
there is a problem with this.

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

This is not necessarily true.

Buildd time is not an unlimited resource; if a maintainer of a
high-priority package keeps requesting rebuilds of his package without
going through the proper channels (i.e., "the people who take care of
autobuilders and/or the architecture in question), that developer may
starve out buildd time for other packages, thereby growing the queue,
increasing frustration with other people, and making life harder for the
porters who have to deal with a growing buildd backlog.

Of course, any damage is correctable, given unlimited time and
resources, but we don't have that. I believe it is not unfair to say
that people who run amok with the wanna-build database can do a lot of
damage to a particular port.

> Is there any legitimate reason that wanna-build access should be
> restricted to any group smaller than the entirety of gid 800
> membership?

There was.

Until about a month ago (if I'm not mistaken), wanna-build used a
libdb-based database for every suite for every architecture, on which it
would perform a _database-level_ lock for each and every access to the
wanna-build database, even if it was only for reading. This would mean
that if one user tried to read from the wanna-build database of a
particular architecture, every other user would have to wait to read or
write until that first user was ready. In other words: even if you were
just trying to figure out what the state of your package was, you could
be interfering with the smooth processing of the autobuilder network.

Given how the wanna-build database has never been one of the most
high-performance databases, and given how buildd just stops trying if it
can't access the database for a given number of times in a row, thereby
introducing database inconsistencies, I think that restricting access
was not uncalled for.

Note that this was not a mere theoretical possibility; I personally have
on one occasion stalled m68k autobuilding for about an hour because I
didn't notice I was still holding the lock (with something like
"wanna-build --list=building | less"...).

Now if you would call this kind of database design "a bug", then I would
completely agree with you. I don't know why it was done this way, and
the person who originally made that decision (Roman Hodek) is not even a
Debian Developer anymore; he significantly reduced his involvement in
Debian even before I had done my first-ever Debian installation, so...

Of course, this bug has now been fixed: rather than using a libdb-based
database, wanna-build is now running off a postgresql database. As such,
it might be prudent to investigate whether giving regular developers
read-access to that database could be doable (it might be difficult,
given that wanna-build runs on a restricted host currently, or it might
be simple; this is something for the wanna-build team to look into). But
I don't think it's unfair to wait a while until all the issues have been
dealt with before thinking about giving the developer body access to the

Also, I don't think handing out read-write access by default would be
the best option; it is not unreasonable to assume that people who do not
understand how buildd works could make mistakes that others then have to
clean up. Since most requests on the debian-wb-team mailinglist are
acted upon fairly quickly IME, I don't think that matters much, either.

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

Can you expand a bit here what you mean by "oppressing the freedom of
other developers"? I find it hard to understand what your complaint is,
and therefore difficult to formulate an answer.

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

I see basically four questions in this one:

- Should core teams (and/or the tech-ctte) be allowed to self-appoint
  without oversight?
- Should core teams (and/or the tech-ctte) be allowed to self-appoint
  with oversight?
- Should teams have the power to exclude anyone who does not get along
  with them?
- Should teams be allowed to exclude anyone who does not agree with
  their approaches?

Allow me to reply to them separately:

- Should teams (and/or the TC) be allowed to self-appoint without

No. However, there's a difference between 'oversight' and 'broadcasting
your reasons'. When asked for their reasoning, teams should give it, and
that reasoning should make sense; however, since volunteers for a team
are often not found in heaps, I don't think it's a major problem if
teams just announce that "J. Random Developer" is now a member of "Team
Bar", provided they give their reasoning if someone asks.

- Should teams (and/or the TC) be allowed to self-appoint with

Yes. If there are ways for us to say "your reasoning really doesn't make
sense, please go back and try again," and there are ways for volunteers
to let themselves known, then I don't think there's anything wrong, in
principle, with a team choosing its new members itself.

There are certain kinds of teams that really should not have people who
are not competent enough to join it. For example, while I'm sure that
active Debian Developers understand how to package a piece of software,
I'm not at all sure that all active Debian Developers have experience as
a system administrator. I am also confident that there are many people
out there who *think* they are competent system administrators, but who
in fact aren't.

It is not unfair if the Debian system administration team looks at
incoming candidates and rejects those who are, in the opinion of the
team as a whole, not competent enough (yet?) to work on their team.
After all, if an incompetent sysadmin makes a mistake that results in a
security breach, the team as a whole will have to deal with it, and the
team as a whole will get the flak of "yet another" breach.

So as long as there is oversight to make sure that decisions are made in
a fair manner, I can live with this.

On your example of the TC: this body is supposed to be a sort of "group
of elders"; people who have a lot of experience within Debian, and can
easily see the larger picture of a particular question without having to
look up a lot of documentation. If random volunteers can join the team,
without a check of their background, that would therefore reduce the
usefulness of the committee; and while there might be several ways in
which to ensure that members of the team have the required background,
one way, and presumably the easiest, is to make the team

It could make sense to change this procedure, doing so would require a
modification to the constitution, which would require a GR; therefore,
this is by definition not something for the DPL alone to work on.

- Should teams have the power to exclude anyone who does not get along
  with them?

If that reasoning is not overused, then yes.

From our Constitution, §2.1.1:

  Nothing in this constitution imposes an obligation on anyone to do
  work for the Project. A person who does not want to do a task which
  has been delegated or assigned to them does not need to do it.
  However, they must not actively work against these rules and decisions
  properly made under them.

I believe this falls under that rule.

I'm sure you'll agree that within any project the size of Debian, there
will be people you consider friends or close friends, people you
consider just colleagues or some such, and people whom you do not like,
at all. If one is forced to work with someone from that last category
and the only two ways out are "deal with it", or "leave the team", I
guess many people will take the latter option.

If it just so happens that most members of a team really really _really_
cannot stand a particular person (because that person is a jerk, to be
frank), then not making that person part of the team, rather than
forcing the team to make the above choice (thereby reducing it to "the
jerk" rather than "the good and efficient team we had beforehand") seems
to be the most sensible course of action.

I don't know about you, but I find it important that teams work well; if
they do not work well, then things will go wrong, or they do not happen
at all. Sometimes, ensuring that a team works well requires that one
particular person is not part of the team.

So as long as this reasoning is not overused, I don't think there is
anything inherently wrong with it. If it is overused, then that is
probably indicative of the fact that something else is going on within
the team and that it is already not working well, which would be cause
for the DPL to intervene.

- Should teams be allowed to exclude anyone who does not agree with
  their approaches?

This one is a bit more difficult to answer, and really depends on the

The mere fact that someone has in the past and/or in the present been
known to criticise a team or their methods should not in no way be an
argument for the team to exclude this person. If the criticism was
offered in a constructive way, then adding this person to the team could
be an asset -- sometimes alternative opinions are a good thing.

If said criticism was uttered in a somewhat bone-headed way, with
insults or an attitude that radiates impoliteness and disrespect, or
something similar, then it would not be unreasonable for the team to
exclude that person on the basis that they would find it hard to work
with this person, as above.

Finally, if someone who disagrees with a team's current approaches were
to join the team, then of course initially, to ensure continuity, that
person may have to work under the existing approaches, at the very least
until the tools that are required for the proposed alternative methods
have been implemented, and/or these alternatives have been tested to see
if they work. If this person is not willing to do that, then that could
be a valid reason for excluding someone from a team.

> 5) Is there any part of Debian that should be restricted
> to a small subset of developers, and if so why?

In my opinion, the only good reasoning why any part of Debian might
reasonably be restricted is that there is a security risk to be had from
doing so.

For instance, since it is impossible to audit all thousands of machines
from which Debian Developers log in to debian.org machines, it is
reasonable to limit the set of "people who have root access to Debian
systems" to a smaller group of people, the machines of which can be

Similar arguments can be made for the machines who handle the archives;
we once had a breach of auric.debian.org, and AIUI the only reason the
packages on the Debian mirror network were not compromised was the fact
that the bug used to break into the machines was i386-only, whereas
auric was a sparc machine. Now I don't know how much of the following
story is correct, but the rumours that I heard said something like this:
the cracker broke into the machine of a developer, used a zero-day
exploit to gain root access, used that root access to hijack an
ssh-agent socket, and used the keys in the ssh-agent to gain access to
several debian.org machines, where they used the same zero-day exploit
to gain root access again. The exploit didn't work on sparc, so auric
was safe, but the cracker had managed to get a shell there.

It is not unsensible to restrict access to only those who actually need
it for their duties; and as long as those who want to can join a team
(given the restrictions in my above answers), I have no objection to

In principle, however, I do agree with you that the default should be
openness where it makes sense.


The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.

Attachment: signature.asc
Description: Digital signature

Reply to: