Hi! On Fri, Mar 19, 2010 at 3:44 PM, Clint Adams <sch...@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 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e8bbf0361003240951y8697efl2f939ce1f2d50...@mail.gmail.com
