Re: Debian for third party (read: propietary) apps/vendors
Hi, On 24/03/13 at 15:47 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: There are third party vendors (read: propietary) that support the installation of their software in Debian, but mostly because selfish reasons: they need to be present everywhere for their business model to work. A clear example of this is Skype. Now there is a second class of apps/vendors which do not need to be ubiquitous for their business model to work. Most of the examples that come to my mind are CAD-related: Synopsys [0], Cadence [1] and Mentor [2] are examples of propietary vendors that give support for Linux but just on Red Hat and sometimes, Suse. And they are a PITA to make them work on Debian. This makes IT workers need to have RH/Suse/CentOS boxes even if the rest of them run Debian. Sometimes the Debian support is a *.deb made from the RPM packages with alien, but this is just a small rant :-) [0] http://www.synopsys.com/home.aspx [1] http://www.cadence.com/us/pages/default.aspx [2] http://www.mentor.com/ Now my question is: without going against the Social Contract, is there anything Debian can/should do wrt this situation? First, I'd like to extend the question a bit. - Yes, not everything is packaged in Debian - Yes, some people are providing software by other means: + Debian packages distributed outside Debian + static binary packages + scripts that download and install the whole world + etc. As Moray said, we should advertise more heavily why it's useful to package for Debian. But I think that we should also aim at making it easier to: - package that software as proper Debian packages - distribute that software inside Debian (when it is legally possible) That means: - providing more/better documentation about packaging - providing easier access paths to Debian (e.g. facilitate finding a sponsor) (I elaborated on that in other mails, so I'm not going to do it here again :) ) 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/20130329094516.ga24...@xanadu.blop.info
Re: [all candidates] delegation
Gunnar Wolf gw...@gwolf.org writes: However, this topic does raise a question: Knowledge transfer. I might be arguing on something marginally related to the vote at hand, but anyway, when delegations shift (be it due to burnout, retirement, rotation or whatever), we should make it as easy as possible to transfer the acquired knowledge from the ex-delegates to the new delegates. Yep, agreed. In some teams, there's the wizard role, someone who isn't all that active anymore, but there's knowledge in his head, and he's willing to share it. I find this a great way to not loose the knowledge, while still allowing someone to move on. Writing documentation is often seen as a boring, painful task. Yet, it is a very important thing to do. So, prospective DPLs, would you see as part of the delegation the requirement for outgoing (if possible, I know it's not always the case) and incoming delegates an obligation to check and update documentation with the latest practices? I'd encourage it, yes. But would not make it a strict requirement. I value hands-on training more than written documentation in many cases (esp. when it comes to using and working with our own tools), and in that case, if I'd have to choose whether to encourage the aforementioned wizard role or writing/updating docs, I'd go with the former. This should also apply to DPL transitions, by the way. -- |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/87obe27db3@galadriel.madhouse-project.org
Re: [all candidates] Removing or limiting DD rights?
On Thu, Mar 28, 2013 at 05:37:18PM -0400, Chris Knadle wrote: Technically the DAM has the ability to act to remove a DD (per Debian Constitution 8.1 item 2), but the information I can gather so far seems to indicate that the DAM won't expell a DD for disciplanary problems. FWIW, that is not correct. There have been other cases of member expulsions for, as you put it, disciplinary reasons, but for various good reasons not all of them are discussed publicly --- one thing is expelling a developer, another is putting that up to ever lasting public shaming on the web. DAM can and do expel for disciplinary reasons, either on their own initiative, or following up to initiatives by other project members. Whether that is done enough or not, of course, is a separate matter. That might be one explanation for the steady drop in new bug reports: That's a bit preposterous, imho, the huge popularity of some of our derivatives---which, in the general case, both benefits from our work and give back to us so that we benefit from theirs---is a much more simpler explanation of those numbers. Beware of simplistic explanation. As a bug reporter dealing with a misbehaving maintainer, this is what I would want: 1. A clear place to report the misbehavior 2. A set of guidelines maintainers should follow 3. A public dialog about the misbehavior with some Debian authority along with the misbehaving maintainer. Note on (3): In the cases I've dealt with, the misbehavior was in public bug reports, so the discussion of the misbehavior should likewise be public. On the other hand, the above are indeed reasonable community expectations. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Debian for third party (read: propietary) apps/vendors
On 29-03-13 10:45, Lucas Nussbaum wrote: As Moray said, we should advertise more heavily why it's useful to package for Debian. But I think that we should also aim at making it easier to: - package that software as proper Debian packages - distribute that software inside Debian (when it is legally possible) That means: - providing more/better documentation about packaging I agree with this. This is why I proposed[1] a while back to look into clarifying which parts of policy really only apply to packages uploaded to Debian, as opposed to packages for local use, which may have different requirements in some cases. There wasn't any response to that mail, however, which lead me to think there wasn't much interest in that proposal. - providing easier access paths to Debian (e.g. facilitate finding a sponsor) [1] https://lists.debian.org/debian-policy/2013/01/msg00081.html -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- 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/5155bc65.6010...@uter.be
Re: Debian for third party (read: propietary) apps/vendors
Wouter Verhelst w...@uter.be writes: I agree with this. This is why I proposed[1] a while back to look into clarifying which parts of policy really only apply to packages uploaded to Debian, as opposed to packages for local use, which may have different requirements in some cases. There wasn't any response to that mail, however, which lead me to think there wasn't much interest in that proposal. For the record, I'm extremely interested in doing this, but it's a lot of work and I have approximately zero time right now to work on Policy things, so I can't (at the moment) help. I probably should have said all of that instead of not saying anything; sorry! It strikes me as something that's best done as part of the long-delayed larger restructuring that we've wanted to do when changing formats. -- 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/87txnudtph@windlord.stanford.edu
Re: [all candidates] Removing or limiting DD rights?
On Friday, March 29, 2013 09:41:23, Stefano Zacchiroli wrote: On Thu, Mar 28, 2013 at 05:37:18PM -0400, Chris Knadle wrote: Technically the DAM has the ability to act to remove a DD (per Debian Constitution 8.1 item 2), but the information I can gather so far seems to indicate that the DAM won't expell a DD for disciplanary problems. FWIW, that is not correct. There have been other cases of member expulsions for, as you put it, disciplinary reasons, but for various good reasons not all of them are discussed publicly --- one thing is expelling a developer, another is putting that up to ever lasting public shaming on the web. DAM can and do expel for disciplinary reasons, either on their own initiative, or following up to initiatives by other project members. Whether that is done enough or not, of course, is a separate matter. That's fair enough, but it would likewise be incorrect to make /assumptions/ about things I know nothing about. As such, there's an issue of public perception that may need consideration. If publicly a DD consistently misbehaves and seems to get away with it for a long time, but is later quitely and privately expelled, the public perception that remains is Debian seemed to do nothing about it. Additionally this effectgively censors things such that the issue can only be discussed in the general sense; e.g. more DDs have been expelled than you are aware of, which is not useful information -- it leaves out all of the reasoning behind what a DD could theoretically be expelled for and what constitutes going too far. I simultaneously acknowledge the problem of making a DD expulsion list public; that's not exactly the kind of trophy anyone would want to obtain. That might be one explanation for the steady drop in new bug reports: That's a bit preposterous, imho, the huge popularity of some of our derivatives---which, in the general case, both benefits from our work and give back to us so that we benefit from theirs---is a much more simpler explanation of those numbers. Beware of simplistic explanation. I'm open to other theories as to the cause. I am, however, a bit surprised that you'd completely dismiss the theory I've proposed so quickly. I'll just let you know that I regularly bump into users in Debian IRC channels saying things such as I need to be involved in another bug report like I need a hole in the head. I take that as a clear signal that there's a problem. As always, I thank you for your comments. :) -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Re: Debian for third party (read: propietary) apps/vendors
On 29-03-13 18:03, Russ Allbery wrote: Wouter Verhelst w...@uter.be writes: I agree with this. This is why I proposed[1] a while back to look into clarifying which parts of policy really only apply to packages uploaded to Debian, as opposed to packages for local use, which may have different requirements in some cases. There wasn't any response to that mail, however, which lead me to think there wasn't much interest in that proposal. For the record, I'm extremely interested in doing this, but it's a lot of work and I have approximately zero time right now to work on Policy things, so I can't (at the moment) help. I probably should have said all of that instead of not saying anything; sorry! No worries. I realize it's a lot of work, and I probably don't have enough time myself, either. I did want to bring it up, and I will want to help out if we ever decide to do this, but I definitely can't do it alone. It strikes me as something that's best done as part of the long-delayed larger restructuring that we've wanted to do when changing formats. Yes, I agree. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- 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/5155d173.8090...@uter.be
Re: [all candidates] Removing or limiting DD rights?
On Fri, Mar 29, 2013 at 01:35:59PM -0400, Chris Knadle wrote: As such, there's an issue of public perception that may need consideration. […] I simultaneously acknowledge the problem of making a DD expulsion list public; that's not exactly the kind of trophy anyone would want to obtain. I wholeheartedly agree with both your points here. Which, to me, is a good indication that this is, in general, a complex problem :) I think the actual expulsion should, generally, not be publicly advertised; what I do want to be public is, in general, community backlash when deplorable social behavior is exhibited in public fora. Seeing that no one reacts to bad social behavior will give the distinct impression that the *community* accepts that behavior which is, imho, even worse than giving the impression that some authoritative police turns a blind eye on it. I'm open to other theories as to the cause. I am, however, a bit surprised that you'd completely dismiss the theory I've proposed so quickly. let you know that I regularly bump into users in Debian IRC channels saying things such as I need to be involved in another bug report like I need a hole in the head. I take that as a clear signal that there's a problem. Well, I certainly didn't mean to imply that bug report handling is not something we should look into improving. It's the causation relationship between that and the decreasing number of bug reports which seems unlikely to me. I'll be totally happy to reconsider that and I'm generally very open to reconsider my positions. But I do think that we need some concrete, scientific evidence, to prove causation in this case, and I've yet to see some of it. As always, I thank you for your comments. :) Ditto :-) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: [all candidates] Removing or limiting DD rights?
On 03/29/2013 01:46 PM, Stefano Zacchiroli wrote: On Fri, Mar 29, 2013 at 01:35:59PM -0400, Chris Knadle wrote: I'm open to other theories as to the cause. I am, however, a bit surprised that you'd completely dismiss the theory I've proposed so quickly. let you know that I regularly bump into users in Debian IRC channels saying things such as I need to be involved in another bug report like I need a hole in the head. I take that as a clear signal that there's a problem. Well, I certainly didn't mean to imply that bug report handling is not something we should look into improving. It's the causation relationship between that and the decreasing number of bug reports which seems unlikely to me. I'll be totally happy to reconsider that and I'm generally very open to reconsider my positions. But I do think that we need some concrete, scientific evidence, to prove causation in this case, and I've yet to see some of it. Do we need to scientifically prove causation here? Chris is raising a good point, and a perception of hostile responses to a bug reports seems entirely plausible as a contributing factor to a decline in bug reports. It certainly wouldn't account for an increase in bug reports (i suspect the set of socially-masochistic users is a vanishingly small one :P ) For that matter, I haven't seen any concrete, scientific evidence to support zack's suggestion that derivative distributions are siphoning off our bug reports. While it seems potentially a plausible contributing factor to me, i could also see an argument that the more derivative distros we support, the *more* bug reports we should get. (e.g. because all the downstream devs are upstreaming their reports and fixes back to debian, like we want them to, right?) These are not mutually-exclusive explanations, either, and there is no single, simple cause for outcomes like a decline in the number of bug reports. I don't think that demanding concrete, scientific evidence is a reasonable bar for just considering what might be one explanation for the steady drop in new bug reports (chris's original words). --dkg signature.asc Description: OpenPGP digital signature
Re: [all candidates] Removing or limiting DD rights?
On Friday, March 29, 2013 13:46:56, Stefano Zacchiroli wrote: On Fri, Mar 29, 2013 at 01:35:59PM -0400, Chris Knadle wrote: As such, there's an issue of public perception that may need consideration. […] I simultaneously acknowledge the problem of making a DD expulsion list public; that's not exactly the kind of trophy anyone would want to obtain. I wholeheartedly agree with both your points here. Which, to me, is a good indication that this is, in general, a complex problem :) I think the actual expulsion should, generally, not be publicly advertised; what I do want to be public is, in general, community backlash when deplorable social behavior is exhibited in public fora. Seeing that no one reacts to bad social behavior will give the distinct impression that the *community* accepts that behavior which is, imho, even worse than giving the impression that some authoritative police turns a blind eye on it. I wholeheartedly agree. […] On Friday, March 29, 2013 13:59:11, Daniel Kahn Gillmor wrote: On 03/29/2013 01:46 PM, Stefano Zacchiroli wrote: On Fri, Mar 29, 2013 at 01:35:59PM -0400, Chris Knadle wrote: I'm open to other theories as to the cause. I am, however, a bit surprised that you'd completely dismiss the theory I've proposed so quickly. let you know that I regularly bump into users in Debian IRC channels saying things such as I need to be involved in another bug report like I need a hole in the head. I take that as a clear signal that there's a problem. Well, I certainly didn't mean to imply that bug report handling is not something we should look into improving. It's the causation relationship between that and the decreasing number of bug reports which seems unlikely to me. I'll be totally happy to reconsider that and I'm generally very open to reconsider my positions. But I do think that we need some concrete, scientific evidence, to prove causation in this case, and I've yet to see some of it. Do we need to scientifically prove causation here? Chris is raising a good point, and a perception of hostile responses to a bug reports seems entirely plausible as a contributing factor to a decline in bug reports. It's the best theory I've got so far. I do /want/ a scientific causation if I could /get/ one, so I share Zack's desire for that. Your question of do we need to prove that is likewise a good point; lack of respect or other abuses in bug reports is a problem /regardless./ For that matter, I haven't seen any concrete, scientific evidence to support zack's suggestion that derivative distributions are siphoning off our bug reports. While it seems potentially a plausible contributing factor to me, i could also see an argument that the more derivative distros we support, the *more* bug reports we should get. (e.g. because all the downstream devs are upstreaming their reports and fixes back to debian, like we want them to, right? Ah. Here's an interesting related thought; some of the derivatives (such as Ubuntu) have Codes of Conduct covering developer communications, where Debian doesn't, and thus there's an expectation of civility there that we may lack. Thus, assuming that bugs are reported for to a derivative distribution and not to Debian, the chilling effect could theoretically still be a possibility as to part of the cause. These are not mutually-exclusive explanations, either, and there is no single, simple cause for outcomes like a decline in the number of bug reports. I don't think that demanding concrete, scientific evidence is a reasonable bar for just considering what might be one explanation for the steady drop in new bug reports (chris's original words). I likewisie don't expect any of us to be able to come up with a way of figuring out the cause definitively. If we could, we'd do so. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Re: [all candidates] Removing or limiting DD rights?
On Fri, Mar 29, 2013 at 01:59:11PM -0400, Daniel Kahn Gillmor wrote: Do we need to scientifically prove causation here? Oh, you're totally right, we certainly do not need that to *work* on improving bug report handling by maintainers. It just takes that evidence to convince *me* that such aspect is a relevant factor in the decrease of bug reporting rate :-). I digressed on that point simply because Chris was wondering why *I* dismissed that argument quickly. Again, I certainly didn't mean to imply that bug report handling is not something we should look into improving. Sorry if that turn is now sidestepping the more important parts of this conversation, it was not my intention to do so. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: [all candidates] Removing or limiting DD rights?
This message appears to be more appropriate for -project, non-candidate responses, please follow up there. On Thu, 28 Mar 2013, Chris Knadle wrote: As a bug reporter dealing with a misbehaving maintainer, this is what I would want: 1. A clear place to report the misbehavior ow...@bugs.debian.org is an appropriate place to report abusive behavior by anyone (maintainers, users, etc) on the BTS. Likewise, listmas...@lists.debian.org is an appropriate place to report abusive behavior by anyone in messages to lists. This probably should be better documented somewhere on the website, but as I've never had to look for it, I don't know where that would be. Someone who has searched for it and failed may have some better suggestions. 2. A set of guidelines maintainers should follow I certainly wouldn't have a problem with adopting a set of guidelines for interactions on the BTS, but I'd prefer to have these guidelines discussed on -project first. [We already do have guidelines for the mailing list, too.] 3. A public dialog about the misbehavior with some Debian authority along with the misbehaving maintainer. Note on (3): In the cases I've dealt with, the misbehavior was in public bug reports, so the discussion of the misbehavior should likewise be public. Discussion of misbehavior is usually not public. If someone reports bad behavior, owner@ or listmaster@ typically talks to the individual concerned, and warns them about it specifically, and informs the reporter that their concern has been addressed. In the case where owner@ or listmaster@ have made a decision which can be overridden by GR (IE, banning someone from using control@ or similar), -private is notified so DDs are aware. Don Armstrong -- S: Make me a sandwich B: What? Make it yourself. S: sudo make me a sandwich B: Okay. -- xkcd http://xkcd.com/c149.html 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/20130328223540.gq5...@teltox.donarmstrong.com
Re: to DPL candidates: getting new people to Debian
Gunnar Wolf gw...@gwolf.org writes: Gergely Nagy dijo [Sat, Mar 16, 2013 at 01:32:32PM +0100]: Debian is also not impressively different, so to say. We have a distinct culture, we have great technical solutions, but those are hardly enough to impress someone who just casually looks. We need to reach out and show them that there is much more under the hood than they may imagine, that we can, and we do provide something unique. And we need to impress them. That's a very, very hard thing to do, and something that we'll need lots of help to accomplish, and not necessarily from technical folk. (Which is why one of my primary aims is to reach and and recruit non-technical contributors to Debian.) How would you suggest impressing them? A new, shiny user interface is not what it takes, or at least, not all it takes. We have packaged *great* user interfaces for a very long time. Even other Linux distributions, aimed at the desktop, have given a lot of extra shine and polish to their UIs, someof them (i.e. our derivative Ubuntu) developing completely new frameworks, targetted IMO to touch-devices, which are all the rage now. And I still cannot say it impresses or dazzles newcomers. It's not the UIs I would focus on - everyone is doing that, and it's never going to be really impressing, in my opinion. Impressing anyone with technical gizmos is hard, and most often, only possible when they were interested anyway. We're not going to reach too many people that way. How we can reach a lot more - see the end of my previous mail. The stories we can tell, the achievements we can show, our entire culture is something that noone else can show. These are *very* impressive things, we should be proud of them, and we should use them as part of our recruitment too. -- |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/87hajt7tgy@galadriel.madhouse-project.org
Re: [to all candidates] Free Software challenges and Debian role
Lucas Nussbaum lu...@debian.org writes: (I still hadn't replied to that question -- I'll do that by following-up on Moray's reply since I agree with most of it) ...and I'll take the easiest route, and follow up on Lucas' mail, since I mostly agree with both of them. Sorry! On 12/03/13 at 17:11 +0300, Moray Allan wrote: [...] - End-users are moving to web applications/the cloud. Few of the most heavily used ones are free software. Even if they are, centralised web applications remove users' ability to modify software to their own needs unless they duplicate a large amount of infrastructure. And in many cases cloud services reduce users' control even over their data itself, not just over the platform. We used to have trouble with the network effect of e.g. Microsoft Office file formats, but free-of-charge web applications can be even worse for free software, since objectors need to argue an ideological point to say why they want information in another way, rather than only explain that they haven't bought that piece of software or that it won't work on their OS. - Server users are also migrating to the cloud. In many cases this means that their services move to sit on a non-free platform, and it often reduces ease of modification even in free parts of the platform. Note that in that case, the cloud is also a great opportunity for us, since most IaaS clouds users use them with free software. So the Cloud tends to reinforce the position of libre operating systems for server OS. While the cloud is a great opportunity for us, as Moray said, quite often, we'd sit on top of a non-free platform. I usually put this under the same label as non-free hardware, because hardware is being replaced by virtualization - but the setup remains fairly similar. I'd add two more things I see as an increasing risk for free software in general: One is code dumps, where the software itself may be free, but development behind it is not, when vendors abide the letter of the license, but not the spirit. That is something that is becoming more and more common, and I find that very worrying. Not only because it does not follow the spirit of free software, but because it makes it much harder to contribute and work with the software in question. I can easily see it alienating people, who'd otherwise become part of the larger free software community. Not only does it not follow the spirit, I believe it actively works against it. The other issue I see is bundling (often patched) third-party libraries. That is hard to untangle, makes security support a nightmare, and has all kinds of negative side-effects. All that to make it slightly more convenient for vendors, who never really learned how to work with free software. (This also applies to careless find sed forks, though those are thankfully much rarer). There's quite a lot we could teach them there, and the world would become a much better place. -- |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/87a9pl7pz8@galadriel.madhouse-project.org
Poor BTS interactions (Re: [all candidates] Removing or limiting DD rights?)
On 2013-03-28 16:35, Don Armstrong wrote: ow...@bugs.debian.org is an appropriate place to report abusive behavior by anyone (maintainers, users, etc) on the BTS. But how broad a definition of abusive behaviour are you taking here? I would have thought of contacting ow...@bugs.debian.org in respect of, say, two people battling about a bug's status in control messages, but I wouldn't have assumed that you would want to deal with, e.g., unnecessarily dismissive responses to user feature requests, or maintainers who sound ruder than they intend to users who report a bug due to not having read the documentation. This probably should be better documented somewhere on the website, but as I've never had to look for it, I don't know where that would be. Someone who has searched for it and failed may have some better suggestions. If new bug reporters have followed our instructions and used a tool to report the bug, they won't necessarily look at the website at all. If we want to be sure of reaching them with this kind of advice, it probably has to come by email as well (at least as a clearly labelled URL). -- Moray -- 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/59841be56f0e5b237e68d6b960d49...@www.morayallan.com
Re: [all candidates] Removing or limiting DD rights?
Don -- my apologies for not responding to this earlier; somehow I missed this message, and figured out I had missed it via reading Moray's resonse to it. On Thursday, March 28, 2013 18:35:40, Don Armstrong wrote: This message appears to be more appropriate for -project, non-candidate responses, please follow up there. Okay, I've just signed up for [debian-project]. I'm in a bit of a rush at the moment, but will respond tomorrow. -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201303292132.59426.chris.kna...@coredump.us
[all candidates] What to do with debian-private ?
Le Thu, Mar 28, 2013 at 03:35:40PM -0700, Don Armstrong a écrit : -private is notified so DDs are aware. How is the state of -private those days ? When I unsubscribed, it was still mixing informations that are really private, like Alice takes holidays in Honolulu, some that may be private by accident, like Bob wants to package libfoo-perl, and some that are irrelevant, like Claudius likes pasta well cooked, Donna does not like discussions about pasta, and Eros thinks that one should not be criticised for discussing about pasta on -private. I found it very tiring to have to permanently remember to never talk about a lot of things that should never have been private in the first place. If this has not changed, is that something that the DPL candidates would like to tackle ? (Bonus question to the DPL candidates: are you subscribed to debian-private ?) Cheers, -- 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/20130330013408.ge23...@falafel.plessy.net
Re: [all candidates] What to do with debian-private ?
On Sat, Mar 30, 2013 at 10:34:08AM +0900, Charles Plessy wrote: Le Thu, Mar 28, 2013 at 03:35:40PM -0700, Don Armstrong a écrit : -private is notified so DDs are aware. How is the state of -private those days ? When I unsubscribed, it was still mixing informations that are really private, like Alice takes holidays in Honolulu, some that may be private by accident, like Bob wants to package libfoo-perl, and some that are irrelevant, like Claudius likes pasta well cooked, Donna does not like discussions about pasta, and Eros thinks that one should not be criticised for discussing about pasta on -private. I found it very tiring to have to permanently remember to never talk about a lot of things that should never have been private in the first place. If this has not changed, is that something that the DPL candidates would like to tackle ? (Bonus question to the DPL candidates: are you subscribed to debian-private ?) This will result in a discussion without being grounded in factual data, since talking about such data in public would be leaking said information. signature.asc Description: Digital signature
Re: [all candidates] What to do with debian-private ?
Paul Tagliamonte paul...@debian.org writes: On Sat, Mar 30, 2013 at 10:34:08AM +0900, Charles Plessy wrote: How is the state of -private those days ? When I unsubscribed, it was still mixing informations that are really private, like Alice takes holidays in Honolulu, some that may be private by accident, like Bob wants to package libfoo-perl, and some that are irrelevant, like Claudius likes pasta well cooked, Donna does not like discussions about pasta, and Eros thinks that one should not be criticised for discussing about pasta on -private. I found it very tiring to have to permanently remember to never talk about a lot of things that should never have been private in the first place. If this has not changed, is that something that the DPL candidates would like to tackle ? (Bonus question to the DPL candidates: are you subscribed to debian-private ?) This will result in a discussion without being grounded in factual data, since talking about such data in public would be leaking said information. I think one thing we *could* talk about in public, although I'm not sure if it's really a DPL question, is whether we could just separate out the vacation messages from the rest of -private traffic. There are occasional quite important threads on -private that should legitimately be on -private and belong there, and quite a lot of vacation messages that people are supposed to send there. My impression is that the S/N complaints of most people about -private are about the vacation messages. I have no objections to the vacation messages (personally, I find them interesting), but we could certainly make a separate list with the same nondisclosure requirements as -private devoted specifically to those messages and any followups around keysignings, etc. (and, probably more broadly, for any other life events that Debian Developers want to share internal to the project, such as marriages, new children, etc.), sort of a DD-internal version of -curiosa, and keep -private as more a DD-internal version of -project. -- 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/8738vd7j23@windlord.stanford.edu
