Re: Questions for all candidates: decentralization of power
On Thu, Apr 01, 2010 at 01:45:45PM +0900, Charles Plessy wrote: If it is not an export or a license violation that a member of the FTP team inspects a package, then I do not think it is for any other member of the project. I am not proposing to give a read access to the NEW queue for any other purpose. I think that what we are doing now puts us in very safe legal ground. I fear what could happen when some litigious copyright holder accuses us of illegally redistributing their software and our reponse is, We just copied it to one other machine so that we could make it available to our entire membership. If because you do not trust the other DDs to respect the rules, that packages in the NEW queue must not be resdistributed before they are accepted, then yes, you have to do the work alone. It doesn't take long processing NEW to realize that many DDs cannot be trusted to make sure that all of the code they are uploading is legally redistributable. If we do not think that the DDs respect the rules (http://www.debian.org/devel/dmup, in which we could add a note about NEW packages before opening up the mirror), how can we tell our users that our system is secure? The problem is also one of accountability. If the DD screws up and eventually an ftp-master or a mirror owner or DPL or SPI or someone else is the one getting sued, can the person getting sued hold the DD accountable? stew signature.asc Description: Digital signature
Re: Questions for all candidates: decentralization of power
Le Thu, Apr 01, 2010 at 11:53:47AM -0400, Mike O'Connor a écrit : It doesn't take long processing NEW to realize that many DDs cannot be trusted to make sure that all of the code they are uploading is legally redistributable. I also think that we need to review the NEW uploads. But this is not what I discuss here. I propose to let all DDs look what is in the NEW queue. (This would of course help to review the NEW uploads). The problem is also one of accountability. If the DD screws up and eventually an ftp-master or a mirror owner or DPL or SPI or someone else is the one getting sued, can the person getting sued hold the DD accountable? “Screwing up” here would be for a DD to log in on the ftpmaster mirror, take a package from the NEW queue, and redistribute it in parallel to the Debian archive. I think that the claim that some people can be sued if some DD screwed up is vague, and is really difficult to discuss factually. I think that if the NEW queue in the ftp-master mirror is readable for all the DDs, there is no risk for the DPL, his delegates, or the sponsor of the provider of the ftp-master mirror machine and connectivity to be sued. Have a nice day, -- Charles -- 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/20100401162702.ga19...@kunpuu.plessy.org
Re: Questions for all candidates: decentralization of power
I also think that we need to review the NEW uploads. But this is not what I discuss here. I propose to let all DDs look what is in the NEW queue. (This would of course help to review the NEW uploads). If there is ever any legal fun around this, it is a *HUGE* difference if you can say Only people who really have need have access before the check is finished or Everyone who feels like it and happens to be a DD at that time has access. I think that the claim that some people can be sued if some DD screwed up is vague, and is really difficult to discuss factually. I think that if the NEW queue in the ftp-master mirror is readable for all the DDs, there is no risk for the DPL, his delegates, or the sponsor of the provider of the ftp-master mirror machine and connectivity to be sued. And on what base do you ground that? -- bye, Joerg Maybe, just once, someone will call me 'Sir' without adding, 'You're making a scene.' -- 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/87mxxnufdb@gkar.ganneff.de
Re: Questions for all candidates: decentralization of power
On Sun, Mar 21, 2010 at 12:46:44AM +0900, Charles Plessy wrote: Dear Clint, I also think that there are many restricted operations that should be opened. Write access to our website, chosing the priority and section of our pacakges, triggering bin-NMUs, designating new members, inspecting new packages submitted to our archive, ??? You do get to choose the priority and section which your packages belong to, though the ftp team can override your choice. When we do override your choice, you get an email inviting discussion about it. I can't think of any instance where the ftp team and maintainers haven't been able to come to an agreement about where the packages belong. The alternative option, where DDs are given write access to the dak database doesn't seem worth the security issues for the small benefit(?) of avoiding having this discussion with the ftp team. Inspecting new packages which haven't cleared NEW has potential legal problems. We don't want to be in the position where we are distributing software that might not be legal for us to distribute. Our trend has been to increase the amount of info about the packages we make available on http://ftp-master.debian.org/new.html (currently down), but we have to stop short of potentially illegally distributing software. For people that want to help with the process of auditing packages in NEW, The ftp team is looking for new members, our most recent solicitation being here: http://lists.debian.org/debian-devel-announce/2010/03/msg3.html stew signature.asc Description: Digital signature
Re: Questions for all candidates: decentralization of power
Le Wed, Mar 31, 2010 at 12:00:05PM -0400, Mike O'Connor a écrit : You do get to choose the priority and section which your packages belong to, though the ftp team can override your choice. When we do override your choice, you get an email inviting discussion about it. I can't think of any instance where the ftp team and maintainers haven't been able to come to an agreement about where the packages belong. The alternative option, where DDs are given write access to the dak database doesn't seem worth the security issues for the small benefit(?) of avoiding having this discussion with the ftp team. Inspecting new packages which haven't cleared NEW has potential legal problems. We don't want to be in the position where we are distributing software that might not be legal for us to distribute. Our trend has been to increase the amount of info about the packages we make available on http://ftp-master.debian.org/new.html (currently down), but we have to stop short of potentially illegally distributing software. For people that want to help with the process of auditing packages in NEW, The ftp team is looking for new members, our most recent solicitation being here: http://lists.debian.org/debian-devel-announce/2010/03/msg3.html Hi Mike, you give three interesting examples on how the FTP team is isolating itself. 1) By a combination of (self-appointed?) authority and technical design, the package section splitting becomes a private tool of the FTP team. Apart from a couple of usual examples, sections are not much useful nowardays, and they are getting reimplemented in parallel through debtags, tasks, or meta-packages (just like our website is being reimplemented on wiki.d.o or alioth.d.o, etc.). I think that one of the causes is that it is not directly under the project's responsibility. What is your vision of the package sections? Where is the big picture? Why the maintainers should even care about them if everything in the design reminds them that sections are not their business, except for saving a bit of your time at the first upload? 2) We can not export software without doing some procedures, but what is the definition of an export? If it is not an export when a DD appointed by a DD delegated by the DPL logs in from outside the USA to inspect a package, then I think that the DPL or the Project can delegate all DDs equally the possibility to do this inspection and write in a NEW package's ITP bug what they think about its copyright and how it is summarised for Debian. Again, the line is currently drawn in a way that increases your workload. That is your choice. 3) The FTP team is looking for people, but you left my propositions to help with the NEW queue unanswered. Whatever your opinion on me as a person, you choice was to discard some help with no justification. In my opinion, the perimeter of the FTP team is not well defined, and has a tendency grow with self-appointed new responsibilities (like the lintian checks at upload for instance). I am not surprised that your team is running out of manpower frequently. Debian needs to trust more its maintainers, and shift from control to resilience over errors. This requires some infrastructural work, but I think that it is worth the effort. Cheers, -- Charles -- 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/20100401015807.gb16...@kunpuu.plessy.org
Re: Questions for all candidates: decentralization of power
On Thu, Apr 01, 2010 at 10:58:07AM +0900, Charles Plessy wrote: Hi Mike, you give three interesting examples on how the FTP team is isolating itself. 1) By a combination of (self-appointed?) authority and technical design, the package section splitting becomes a private tool of the FTP team. I'm not familiar with how the package sections came to be. I'll reluctantly take your word for it. Apart from a couple of usual examples, sections are not much useful nowardays, and they are getting reimplemented in parallel through debtags, tasks, or meta-packages Agreed. (just like our website is being reimplemented on wiki.d.o or alioth.d.o, etc.). I didn't know about this. I think that one of the causes is that it is not directly under the project's responsibility. I'm not sure what you mean by this. Having the packages in the distro grouped by secitions isn't the repsonsibility of the distro? What is your vision of the package sections? Where is the big picture? Its a way of categorizing packages to facilitate browsing through or searching for packages in debian. Its not much more than this. I think that once debtags is farther along, they could replace sections completely. Why the maintainers should even care about them if everything in the design reminds them that sections are not their business, except for saving a bit of your time at the first upload? I don't understand what you mean here at all. I'm not sure what time is being saved. If you don't want to care about them, you can probably ignore them. Some people don't, the ftp team makes sure there are sane choices being made in the cases where maintainers haven't cared enough. IfIf there is a package in an incorrect section or with the wrong priority, please just file a bug against ftp.debian.org and it will get fixed. Opening up write access to the database that maintains the archive to all developers just so that they can change sections (something that you yourself characterize as not much useful anyway) seems like something that is not worth the security risk. 2) We can not export software without doing some procedures, but what is the definition of an export? If it is not an export when a DD appointed by a DD delegated by the DPL logs in from outside the USA to inspect a package, then I think that the DPL or the Project can delegate all DDs equally the possibility to do this inspection and write in a NEW package's ITP bug what they think about its copyright and how it is summarised for Debian. Again, the line is currently drawn in a way that increases your workload. That is your choice. The issue I was talking about had nothing to do with software crossing state lines. It had to do with violating license agreements. I'm not familiar with any procedures we must do before exporting software that you are alluding to. The issue that I was talking about would be when the license of a piece of software prohibits us from legally distributing the software at all, or if distributing the software might include a legal burden we don't want to carry. For instance, if someone were to upload software such as opera or adobe flash or skype which has explicit licenses which prohibit any redistribution, we cannot allow the ftp-master machine to become a point of redistribution. For this reason, we don't allow the software to be copied off of the ftp-master machine until we've audited it with respect to software licenses. If we were to do what it seems like you want (correct me if I'm wrong about what you'd want). We'd have to either open up the ftp-master machine to all developers, which worries me from a security standpoint, or we'd have to be willing to distribute potentially non-redistributable software off the machine to developers, which would worry me from a legal standoint. 3) The FTP team is looking for people, but you left my propositions to help with the NEW queue unanswered. If there were propositions that we aren't already discussing. I missed them. I'm sorry. Whatever your opinion on me as a person, you choice was to discard some help with no justification. Sorry. I mussed have missed something. I don't think there is any reason to discuss my opinion of you as a person, lets please drop that, its irrelevant. I don't know what help you are offering that I'm discarding with no justification. The ONLY thing I've done so far was to justify. In my opinion, the perimeter of the FTP team is not well defined, and has a tendency grow with self-appointed new responsibilities (like the lintian checks at upload for instance). How do you think it should be defined then? I am not surprised that your team is running out of manpower frequently. I'm not either. But I get the feeling that we have differing opinions about why that is. It seems to me that we don't retain members becuase there is a lot of very very tedious, often thankless work that often puts you in the position
Re: Questions for all candidates: decentralization of power
Le Wed, Mar 31, 2010 at 11:24:50PM -0400, Mike O'Connor a écrit : The issue I was talking about had nothing to do with software crossing state lines. It had to do with violating license agreements. I'm not familiar with any procedures we must do before exporting software that you are alluding to. If we were to do what it seems like you want (correct me if I'm wrong about what you'd want). We'd have to either open up the ftp-master machine to all developers, which worries me from a security standpoint, or we'd have to be willing to distribute potentially non-redistributable software off the machine to developers, which would worry me from a legal standoint. What I would like is at least read access of the NEW queue in the mirror of ftp-master, and to my knowledge the last reason that was given to deny it is the USA crypto export rules: http://lists.debian.org/20090308040721.ga16...@dario.dodds.net If it is not an export or a license violation that a member of the FTP team inspects a package, then I do not think it is for any other member of the project. I am not proposing to give a read access to the NEW queue for any other purpose. In the past I have tried to seed a peer review process of the packages in NEW (http://wiki.debian.org/CopyrightReview), when the backlog was of hundreds of packages. I detected some problems, which were corrected before the FTP team processed the package. In one case, the maintainer even completely retracted the package. I hope that all of this saved some of your time. But I could only do this of packages that were available on mentors.d.n or in a VCS, because of the restriction on the read access to the NEW queue on the ftpmaster mirror. If because you do not trust the other DDs to respect the rules, that packages in the NEW queue must not be resdistributed before they are accepted, then yes, you have to do the work alone. If we do not think that the DDs respect the rules (http://www.debian.org/devel/dmup, in which we could add a note about NEW packages before opening up the mirror), how can we tell our users that our system is secure? Have a nice day, -- Charles -- 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/20100401044545.ga17...@kunpuu.plessy.org
Re: Questions for all candidates: decentralization of power
On Mon, Mar 29, 2010 at 04:42:22PM -0300, Margarita Manterola wrote: whoever is delegated by the DPL to do this) goes around imposing members to teams, or switching members willy-nilly, it would definitely lead to a lot of frustration and resignations. I think that's probably fine. ftpmaster did not want Joerg to be promoted, and when he was, without approval of the team, Anthony Towns quit. I think that the common feeling is that this is an improvement. Joerg does more and better work than Anthony did. Was there a better way of handling the situation that would have been less traumatic for everyone involved? Possibly. Would it have been better to stick with the status quo for fear of attrition or bad feelings? I really don't think so. So, I once again turn the question to you, since this was what I intended to ask before, but didn't get the reply I wanted. If you were elected DPL, how would you go about supervising team membership? Well, I am not running for DPL so I have not spent time planning changes that I will not be able to make. I imagine that I would not do very much on day one. The idea of formally re-delegating when the DPL role changes hands appeals to me a bit, but if I were going to only renew all existing delegations for the sake of setting precedent, I am unsure whether that is valuable. In general, I would try to move things in a few directions at once: more people on core teams, less power for core teams, more cooperative atmosphere, more empowerment for the lowly DD. If I thought that someone would be an asset on a core team, or if someone suggested to me that someone else would be an asset on a core team, I would likely explore that option. I would not try to make surprise delegations; the episode with debian-policy tells me that that would not work out well. Depending on the situation, I might ask the target team for feedback, but I would not ask their permission. I absolutely would not allow core teams to invite people, whether they had personal relationships with those people or not. In addition, I think I would probably delegate all DDs to be able to edit the website. It seems clear that I have not convinced anyone who did not already agree with me that making people ask for that access is a bad thing or even significant, but is. It is a bad thing, and it matters. Hopefully this would prove a point. -- 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/20100330152055.ga23...@scru.org
Re: Questions for all candidates: decentralization of power
On Sun, Mar 28, 2010 at 3:41 PM, Clint Adams sch...@debian.org wrote: Well, in the paid employment part of my life, I have been put in positions where I have needed to work with people I disliked, and it is not considered professional to refuse on those grounds. Indeed, I guess most of us have gone through similar situations. The difference is mainly what you are already emphasizing: in paid employment, you get paid for your work. In volunteer work, you do it because you want to, nobody can force you to work with someone you don't like, you can just walk away and stop working on that area of the project. Would you consider it appropriate me to refuse to acknowledge bugs or patches from anyone I consider to be a bad person? If not, why would it be appropriate for someone to refuse to collaborate in other ways? I don't think that refusing to fix a bug is comparable to refusing to work on the same team as someone else. We theoretically all want good things for Debian here, even if we disagree on most of the details. Letting groups of people with privileged access maintain their own membership creates a power imbalance that I believe has led to much trouble in the past. I think it forms cliques and cabals, and encourages territoriality. Do you disagree? No, I don't disagree. I would very much prefer that all teams were open and that even taking into account personal differences people could be able to work together towards a common goal. However, I realize that it's not an easy problem to solve, because if the DPL (or whoever is delegated by the DPL to do this) goes around imposing members to teams, or switching members willy-nilly, it would definitely lead to a lot of frustration and resignations. I think that the DPL can talk to the involved parties and make some recommendations, but anything more forceful would be received with a lot of resistance and lead to loss of people. So, I once again turn the question to you, since this was what I intended to ask before, but didn't get the reply I wanted. If you were elected DPL, how would you go about supervising team membership? -- 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/e8bbf0361003291242xeb129cbr4a60b78cfc3a6...@mail.gmail.com
Re: Questions for all candidates: decentralization of power
Clint Adams sch...@debian.org writes: Well, in the paid employment part of my life, I have been put in positions where I have needed to work with people I disliked, and it is not considered professional to refuse on those grounds. In Debian I receive bug reports from people I might dislike, but I treat those just the same as I do from anyone else. Don't you think this conflicts somewhat both with Debian being a volunteer project and with the overall goal that a lot of us have to have fun doing Debian work? (Which, even if not a universally-accepted goal, certainly makes it easier to find more resources.) I'd much rather try to apply the standard Fidonet/Usenet advice: do not intentionally offend, and do not be too easily offended. There are some significant differences between professional behavior for which I'm being paid, and what I do in my free time. While there aren't many people involved in Debian who would fall into that category for me, there have been a small handful who I'm not willing to work closely with unless I'm being paid to do so and hence have some compensation for the amount of time, energy, and emotional drain involved. Would you consider it appropriate me to refuse to acknowledge bugs or patches from anyone I consider to be a bad person? If not, why would it be appropriate for someone to refuse to collaborate in other ways? Some forms of collaboration are considerably closer than others. Bugs and patches tend to be mostly one-time interactions at a distance, not real time, and involving only a few back-and-forth exchanges. That's a lot different than working with someone regularly on tasks for months or years at a time. There are a lot of behaviors that I can easily tolerate in the course of a bug discussion or patch exchange that would drain me of emotional energy and resources if I were putting up with them for months on end. It's a question of energy for me. If I have to devote energy to working with people who are active emotional drains, that's energy that's not going to improving Debian or doing other things I find worthwhile, and if that balance gets too out of whack, I'll just stop doing things for Debian. The net result is that the project as a whole ends up with fewer resources and more problems. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87zl1qew3a@windlord.stanford.edu
Re: Questions for all candidates: decentralization of power
On Wed, Mar 24, 2010 at 01:51:45PM -0300, Margarita Manterola wrote: 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. Well, in the paid employment part of my life, I have been put in positions where I have needed to work with people I disliked, and it is not considered professional to refuse on those grounds. In Debian I receive bug reports from people I might dislike, but I treat those just the same as I do from anyone else. Would you consider it appropriate me to refuse to acknowledge bugs or patches from anyone I consider to be a bad person? If not, why would it be appropriate for someone to refuse to collaborate in other ways? We theoretically all want good things for Debian here, even if we disagree on most of the details. Letting groups of people with privileged access maintain their own membership creates a power imbalance that I believe has led to much trouble in the past. I think it forms cliques and cabals, and encourages territoriality. Do you disagree? -- 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/20100328184107.ga21...@scru.org
Re: Questions for all candidates: decentralization of power
* Wouter Verhelst (wou...@debian.org) [100319 22:57]: On Fri, Mar 19, 2010 at 10:36:53PM +0100, Wouter Verhelst wrote: On Fri, Mar 19, 2010 at 06:44:23PM +, Clint Adams wrote: 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. [...snip history...] 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. It was pointed out to me on IRC by a member of the Debian sysadmin team that this has in fact already happened: buildd.debian.org, aka cimarosa.debian.org, is not a restricted host, and the wanna-build database is not restricted; every DD is able to access the database. Write-access is limited for the reasons Wouter pointed out above. Also, read-access to the security suites (which list not yet published packages) is limited for obvious reasons. Sometimes we need to change priorities of packages to e.g. get a transition done, or to avoid a starving situation (like now, we just lost one mips buildd due to a failing harddisk). If we prioritize certain packages this means other packages obviously get less priority. One needs to follow the relevant IRC channels plus lists to know how the situation currently is - sometimes we have enough spare ressources and packages can be easily tried a second and third time, and sometimes not. On the other hand, I don't believe that there are requests which are not dealt with in short time frame. (And if someone shows good judgement on requests it could easily mean that he'll probably get sufficient access rights soon.) Also note that while the above is true, the DSA team tells me that cimarosa is currently rather starved for IO; so while you can access the database, that does not mean necessarily mean you should, unless you've got a good reason to, since overusing it might interfere with the smooth functioning of the buildd network (and we don't want that, right?) If someone is seriously interessted in helping us with buildd / wanna-build, please just tell so. :) Andi -- 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/20100324090058.gq19...@mails.so.argh.org
Re: Questions for all candidates: decentralization of power
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
Re: Questions for all candidates: decentralization of power
On 19/03/10 at 22:57 +0100, Wouter Verhelst wrote: On Fri, Mar 19, 2010 at 10:36:53PM +0100, Wouter Verhelst wrote: On Fri, Mar 19, 2010 at 06:44:23PM +, Clint Adams wrote: 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. [...snip history...] 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. It was pointed out to me on IRC by a member of the Debian sysadmin team that this has in fact already happened: buildd.debian.org, aka cimarosa.debian.org, is not a restricted host, and the wanna-build database is not restricted; every DD is able to access the database. Also, the public part (as in: not the security builds, for example) is imported into UDD (wannabuild table). -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- 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/20100320065537.ga2...@xanadu.blop.info
Re: Questions for all candidates: decentralization of power
On Saturday 20 March 2010, Wouter Verhelst wrote: It is of course reasonable to require that people familiarize themselves with how things are set up before being given access. But beyond that, if they are Debian Developers, getting access to the webwml repository is a no-brainer, AIUI. If I'm mistaken, then please do enlighten me. No, you're not. But IMO it's still a valid reason not to grant access by default, as was suggested. -- 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/201003201310.58958.elen...@planet.nl
Re: Questions for all candidates: decentralization of power
Le Fri, Mar 19, 2010 at 06:44:23PM +, Clint Adams a écrit : 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. 2) wanna-build access is restricted 3) An ftpmaster cabal 4) The tech-ctte has the power to appoint its own members. 5) Is there any part of Debian that should be restricted to a small subset of developers, and if so why? Dear Clint, I also think that there are many restricted operations that should be opened. Write access to our website, chosing the priority and section of our pacakges, triggering bin-NMUs, designating new members, inspecting new packages submitted to our archive, … I see two possible reasons to keep some restrictions. a) Social. Just writing that we think that restrictions must be lifted is not enough; we need to be convincing. If a majority of DDs agree to open only a part of the infrastructure, I think that it is better to accept the remainig restrictions, and re-open the discussion in one or two years later when we can show the benefits. b) Security: if one DD account is compromised, some mechanisms can limit the harm caused by intruders. For instance, there could be a temporisation system that delays for a couple of hours the effect of some commands, and I would agree to have a restricted number of persons with the ability to bypass this temporisation, for instance when some critical dysfunctions have to be corrected immediately. Lastly, I think that we need some referees for our technical disagreements, and the technical comittee fits well that role. If I am elected DPL, I will ping its members and ask them if they would like to leave their seat to fresh persons. I do not think that it is a bad thing that the comittee is not elected. Its role is not to proportionaly represent currents of opinion within Debian, but in contrary to make decisions that reflect the Project's consensus. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100320154644.ga2...@kunpuu.plessy.org
Re: Questions for all candidates: decentralization of power
Hi Charles, Am Sa, 20.03.2010, 16:46, schrieb Charles Plessy: Lastly, I think that we need some referees for our technical disagreements, and the technical comittee fits well that role. If I am elected DPL, I will ping its members and ask them if they would like to leave their seat to fresh persons. I do not think that it is a bad thing that the comittee is not elected. Its role is not to proportionaly represent currents of opinion within Debian, but in contrary to make decisions that reflect the Project's consensus. I'm not sure I understand you correctly here. Are you saying that you will -- if elected DPL -- suggest the current members of the technical comittee to step back just for the sake of having new people in their seats? Hauke -- 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/0b6cda2373208258ed9b32cb0bc9f7ee.squir...@webmail.jhr-online.de
Re: Questions for all candidates: decentralization of power
On Fri, Mar 19, 2010 at 06:44:23PM +, 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
Re: Questions for all candidates: decentralization of power
Charles Plessy ple...@debian.org writes: Lastly, I think that we need some referees for our technical disagreements, and the technical comittee fits well that role. If I am elected DPL, I will ping its members and ask them if they would like to leave their seat to fresh persons. I'm a little bit confused about why you would do this. Could you explain more what the motivation would be? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87bpeibyri@windlord.stanford.edu
Re: Questions for all candidates: decentralization of power
Stefano Zacchiroli wrote: [ 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 :-) ] No, there is not. The website is rebuilt (as needed) every 8 hours based on whatever is in CVS at that time. -- 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/201003202022.46903.elen...@planet.nl
Re: Questions for all candidates: decentralization of power
Le Sat, Mar 20, 2010 at 05:59:35PM +0100, Jan Hauke Rahm a écrit : I'm not sure I understand you correctly here. Are you saying that you will -- if elected DPL -- suggest the current members of the technical comittee to step back just for the sake of having new people in their seats? Le Sat, Mar 20, 2010 at 12:04:33PM -0700, Russ Allbery a écrit : I'm a little bit confused about why you would do this. Could you explain more what the motivation would be? Hi, I think that a good ping email contains an invitation to think about one's involvement in the future. People may forsee a reduction of the time they can give to Debian, or they are increasingly interested in other activities within Debian. Unless we think that nobody else than the current members are qualified for the task, I think that it is useful to remind them that they are free to pass the baton if they wish. I will not propose to the chairman of the technical comittee to rotate a member who has answered to the ping. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100321030437.ge31...@kunpuu.plessy.org
Re: Questions for all candidates: decentralization of power
On Fri, 19 Mar 2010, Clint Adams wrote: 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. [...] If there are decisions which are less-than-stellar, the proper method to address them is to have a GR under 4.1.4. Is there any legitimate reason why core teams should be allowed to select their own members with or without external oversight? In the case of the CTTE, §4.1.3 and §4.1.4 allows the developers to have oversight over all of the decisions that the CTTE takes, including membership in the CTTE. Don Armstrong -- NASCAR is a Yankee conspiracy to keep you all placated so the South won't rise again. -- http://www.questionablecontent.net/view.php?comic=327 http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20100319194619.gt4...@teltox.donarmstrong.com
Re: Questions for all candidates: decentralization of power
On Fri, Mar 19, 2010 at 06:44:23PM +, 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
Re: Questions for all candidates: decentralization of power
On Fri, Mar 19, 2010 at 10:36:53PM +0100, Wouter Verhelst wrote: On Fri, Mar 19, 2010 at 06:44:23PM +, Clint Adams wrote: 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. [...snip history...] 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. It was pointed out to me on IRC by a member of the Debian sysadmin team that this has in fact already happened: buildd.debian.org, aka cimarosa.debian.org, is not a restricted host, and the wanna-build database is not restricted; every DD is able to access the database. Since I'm in the set of users who has the ability to read from this database anyway, I didn't notice; apologies for the honest mistake. Also note that while the above is true, the DSA team tells me that cimarosa is currently rather starved for IO; so while you can access the database, that does not mean necessarily mean you should, unless you've got a good reason to, since overusing it might interfere with the smooth functioning of the buildd network (and we don't want that, right?) Regards, -- 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 signature.asc Description: Digital signature
Re: Questions for all candidates: decentralization of power
Wouter Verhelst wrote: 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. It's not quite true that there is absolutely no reason to limit access. As with most things, there are a some things that someone who wants to edit the website needs to be aware of. Having additional people committed to improving the website would be very welcome. Having people randomly stomp over it because they have an idea and making chances without being aware of context and e.g. impact on translations would be bad. Note that a lot of the people who currently have access are (non-DD) translators. -- 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/201003192329.31621.elen...@planet.nl
