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 database. 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 oversight? 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 oversight? 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 self-appointing. 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 situation. 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 audited. 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 that. In principle, however, I do agree with you that the default should be openness where it makes sense. HTH, -- 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. http://www.schneier.com/blog/archives/2009/01/biometrics.html
Attachment:
signature.asc
Description: Digital signature