Re: Questions for all candidates: decentralization of power
Hi!
On Fri, Mar 19, 2010 at 3:44 PM, Clint Adams <schizo@debian.org> wrote:
> 5) Is there any part of Debian that should be restricted
> to a small subset of developers, and if so why?
So, I've taken quite a while to ponder about these questions,
particularly this last one. Several people have already replied with
particular reasons of why a certain service should be less than open.
My general take on the issue is that through the NM process, we can
only assure that a DD knows how to package, how to handle bugs and how
to do uploads. We can't assure that every DD knows how to handle the
wanna-build queue, how to use wml, or whatever special knowledge is
needed for a certain task.
With that in mind, I think that if the policy to get access is simply
"ask and you are granted it", it's basically the same as if everybody
had access, with the benefit that you know who is it that is
interested in working on some part, and you can make sure that they at
least have the pointers to where the documentation is located. A part
of Debian with such a policy could not be said to be "restricted" to a
subset of developers, but only "currently involving" a subset of
developers.
As long as an open policy is kept and response to requests is fast
enough, I don't mind having to ask to get access to a certain part to
which I want to contribute. However, if only certain people who
belong to certain circles can work on a part of Debian, then we are
probably falling into elitism, and we should inspect that to check
what's going on.
But also, yes, there are parts of Debian that should be restricted.
Even without taking security into account, I think it would be
extremely chaotic if we all had root in all the Debian machines. Or,
if we all had it but wanted to avoid chaos, we'd need to agree on a
group of people that actually take the decisions regarding the setups,
and refrain from changing stuff to each one's liking, thus having a
restricted group that takes the decisions.
Now to the specific cases you asked about:
> 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?
As I said, given than the policy here is "ask and you get it", I
don't see anything wrong. It's also good to know that you don't need
to be a DD (i.e. know about packaging) in order to be able to
contribute to the website, which makes this example even less
restricted. The legitimate reason can simply be being to be able to
know who's working on what, and make sure they are aware of how the
work on the website is done.
> 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?
Others with much more knowledge about this than me have already
explained the reasons of why it was so closed in the past and how it
has improved in the present. Even if no "uncorrectable" damage can be
done, by messing up with the wanna-build queue, someone could hog the
buildds, and thus it's important to know that people with write access
know what they are doing. This doesn't mean that we should have a
closed circle of "wanna-build" gurus, but that to get access you
should at least show interest in what's going on.
> 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?
As others, I have no idea what you are pointing at here. I'd say that
it is normal that some DDs are more trusted than others, but
specifically because they have earned that trust. I cannot figure out
in what situation someone is more trusted without having earned such
trust. Or what it has to do with the mirror pulse.
> 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 think that the main reason for this is that it would be extremely
annoying for everyone involved if it was done otherwise. It'd be
annoying for the team to have to be supervised or have members imposed
on them, and it would be annoying for whoever is in the role of
supervising, to have to decide or oversee upon new team members.
In the case of the tech ctte that you mention as an example, changing
the way the members are appointed would mean changing the
constitution. It could be done through an annual, or maybe biennial,
vote on the members, if the developer body agrees to such a change.
However, the tech ctte has been underused for as long as I've been in
Debian, so I don't think too many people would really care about this.
For other core teams that are delegated by the DPL, each team has a
different process to appoint new members, probably related to the way
they work internally. Sometimes they have assignments that the
prospective members have to complete, sometimes it's just the fact
that someone has shown interest in participating. They cannot
automatically extend the previous delegations to new team members, but
they definitely can choose who they want to work with.
I'd very much like to know how _you_ think that it should be done,
because even if I don't like the "We have to like you in order for you
to work with us" clause, I don't think it would be productive if the
DPL, or someone in a similar role, started appointing new members to
the teams and forcing people that don't like each other to work
together.
--
Besos,
Marga
Reply to: