Re: [all candidates] Return to the desert island (cont.)
Bart Martens ba...@debian.org writes: On Wed, Mar 20, 2013 at 09:27:58AM +0100, Wouter Verhelst wrote: You can use flashplugin-nonfree to download a piece of software that has a nonfree license, which is then installed on your system; the result is that you now have a system which has some non-DFSG-free software installed. To be able to reach this situation on a system that only has main enabled would be utterly wrong. You can use pidgin-facebookchat to talk to a non-free service; but whatever you do, the result will *never* be that you end up with a system which has some non-DFSG-free software installed. As such, I don't think it's necessary that you not be able to reach this on a system that only has main enabled. OK, you seem to draw the line where non-free is installed or not on the local system. That makes somewhat sense to me. But then the part which require software outside of the distribution to either build or function in debian-policy should be replaced by something like which causes software outside of the distribution to be installed on the local system. What one uses a particular piece of software for, to access a non-free service or anything else, is none of our business. Is it sad that non-free services exist? Yes. Is it bad that we have free software in main, that allows users to extract their data from these services? Definitely not. Is it bad that we have free software that allows users to communicate with non-free services? Nope. We have plenty of software in main that allow things like this, and that's a good thing. Our task is to allow our users to get things done. As long as the software we distribute is free, it does not matter much whether it requires a non-free service or not - we do not distribute the service. By installing software that talks to a non-free service, the system remains Free, that's where our jurisdiction ends. We can, and we should encourage using free services, but whatever a particular software talks to, does not affect its classification according to the DFSG. The whole cloud stuff is a whole different can of worms. -- |8] -- 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/87li9b8y7l@galadriel.madhouse-project.org
[all candidates] delegation
Hi all, One of the key role of the DPL is to delegate. What are your intention in this regard? Do you think that the current teams and roles are well filled? Or would you like to change some of the people currently holding a position? Why (not) changing anything? Cheers, Thomas P.S: I have read the history, and didn't find anyone asking this. If I missed it, then sorry... -- 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/51507354.1050...@debian.org
[all candidates] Removing or limiting DD rights?
Hi guys, First of all, thanks to all three of you standing in the DPL election this year. I know it's a daunting task! :-) I've already seen some debate about how we could/should attract more contributors, which is a perennial question in Debian. I personally don't think we're ever likely to solve that issue permanently, but it's clearly something that's always going to be very important for us. I have a related question, but more on the opposite end of the spectrum I suppose: Are we strict enough with our existing contributors? When we're trying to work together as best we can to make the Universal Operating System happen, what could/should we do with contributors who hinder our work? Sometimes that hindrance is inadvertent, sometimes it seems deliberate. At other times it looks like we have developers who are just not paying attention to what they're doing or who just don't care about the goals of the project. Occasionally we see direct action to censure or even expel DDs, but these are only ever in the most blatant of cases. By the time that happens, large amounts of damage may be done to the project: delayed releases, lost users, loss of motivation for other contributors. I'm wondering: is this something that you think is a real problem, and if so what do you think we could do about it? -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- 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/20130325162223.ga11...@einval.com
Re: [all candidates] delegation
On 25/03/13 at 23:55 +0800, Thomas Goirand wrote: Hi all, One of the key role of the DPL is to delegate. What are your intention in this regard? Do you think that the current teams and roles are well filled? Or would you like to change some of the people currently holding a position? Why (not) changing anything? Hi, Our teams are generally working very well. Are they well filled? They are surely filled by very qualified people, but not all the teams have a lot of spare manpower. If elected, one of my first tasks will be to do a status check of our core teams, to: - understand who is active currently, who is going to be active in a year, who is active but would like to step down, ... - encourage the teams to think about possible new members, so that they can be contacted and trained early. (I will not go through every team (including all packaging teams), but instead focus on the teams that have the ability, when malfunctionning, to severely harm the project.) In his platform, Moray writes: | I would also like us to take a more pre-emptive approach to such issues | by encouraging more turnover of members between different teams I think that most teams require quite specific skills, and most team members like what they do. So I'm not going to force or encourage people to move to other teams. However, I think that it is important that our teams are sufficiently staffed so that one can leave a team without feeling guilty. Lucas -- 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/20130325162417.ga9...@xanadu.blop.info
