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 z...@{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
signature.asc
Description: Digital signature