Notice of affiliation change of Technical Committee member
A lot of folks know about this already, but it occurred to me that it would be a good idea to send a more explicit notice. I think public knowledge of affiliation information is important for members of decision-making bodies so that the broader community can be aware of possible conflicts of interest. So, towards that end, I wanted to let everyone know that I left Stanford University and joined Dropbox (https://www.dropbox.com/), starting last Tuesday (August 19th). I'm a member of the Dropbox site reliability engineering team (meaning that I work on the servers that keep the service up, but not on the product code). I don't expect this change to have any long-term impact on my Debian activities, except possibly freeing up more time to work on Debian depending on various pending conversations with Dropbox. I have, however, used this change as an opportunity to rethink various committments, and will be stepping down from some package maintenance teams (and, in the long run, possibly rejoining or at least resurrecting activity levels in others). For more details, see: http://www.eyrie.org/~eagle/journal/2014-08/001.html http://www.eyrie.org/~eagle/journal/2014-08/002.html -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87siklefqy@hope.eyrie.org
Re: Can I donate in bitcoin?
Daniel Pocock writes: > - Many people feel a strategy of holding assets in the currency that > aligns with future expenses is helpful. If, for example, 60% of > Debian's annual expenses were in USD and 40% were in EUR, then it would > seem sensible to convert any other donations to those currencies. > Whether the donations are from a volatile cryptocurrency (BTC) or just > some other currency like Australian dollars or Canadian dollars, if > Debian doesn't actually need those currencies for any known expense, > then holding them is a form of speculation. +1. I believe Debian should only hold bitcoin if Debian anticipates future expenses in bitcoin. Otherwise, it should convert bitcoin to whatever currency in which expenses are expected. I think the decision to hold bitcoin outside of expected expenses are basically ways for the project to indicate support for bitcoin, and I'm very dubious that is appropriate. I know there are people who feel like the goals of bitcoin are in close alignment with the goals of free software, but I personally am completely unconvinced of that. The underlying economic theory behind bitcoin appears to me to be based on theories about "hard" currency that I believe have been completely discredited in the macroeconomic literature. I realize that other Debian Developers disagree, and I'm not particularly interested in trying to convince them that I'm right and they're wrong; rather, I think that whole debate is rather far afield from our project goals and would be a distraction. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvgi8yab@hope.eyrie.org
Re: Can I donate in bitcoin?
martin f krafft writes: > also sprach Russ Allbery [2014-08-26 19:24 -0700]: >> +1. I believe Debian should only hold bitcoin if Debian >> anticipates future expenses in bitcoin. Otherwise, it should >> convert bitcoin to whatever currency in which expenses are >> expected. > So how do we decide whether we anticipate further expenses in > Bitcoin? This *is* what I am talking about. I am not saying we > should endorse Bitcoin or speculate. But support would come with > a decision for us to hold Bitcoin for future expenses. Well, what does Debian spend money on, and are those things available in Bitcoin? That feels like a question for the treasurer. I believe Debian's major expenses are Debconf, team meetings (mostly travel and possibly some lodging and food), and computing hardware. I would be surprised if Bitcoin were useful for the first two. The latter seems likely to have the most potential to take Bitcoin. However, I think there's another factor: I don't believe it makes sense for Debian to hold Bitcoin to buy things from vendors whose pricing is in regular currency (USD or EUR or the like), but who are willing to accept Bitcoin and immediately convert. Daniel's point about accounting best practices isn't that you hold money in currency you *can* spend, but rather you hold money in currency in which the prices of the things you will be buying are denominated. My understanding is that basically everything is denominated in USD or EUR or the like, even if Bitcoin is accepted. This matters because of the volatility: if Bitcoin suddenly drops in value by half (or doubles in value), do the prices stay the same, or do they immediately drop by half or double? If they stay the same, then we should hold Bitcoin, because that's the currency the prices track. If they double or halve, we should hold money in the currency in which the prices are stable, since that's the minimum risk position. There is an exception to that, and I should expand some more on my dubiousness about Bitcoin. My concerns are primarily around the movement to treat Bitcoin as a primary currency -- as equivalent to USD or EUR and usable for the same thing. But Bitcoin as a *secondary* currency could be useful to hold in small quantities for the same reason that one might hold small amounts directly in one's Paypal account instead of transferring it out to a bank, since it saves on hassle in shifting things in and out of the account. Bitcoin has some nice transactional properties separate from the whole "economic system hacking" aspect of the Bitcoin community that may make it more useful than regular currencies for, say, micropayments. If we have places where it's useful to use Bitcoin because, for instance, we're making micropayments and the transaction fees are much lower, then we should hold an appropriate amount of Bitcoin for those purposes to take advantage of the low transaction costs. I'm not sure if that's the case for anything yet; the treasurer would know more. I should also note, in response to Santiago's comments on debian-devel, that the reason to talk about Bitcoin in particular and not other cryptocurrencies is that support for Bitcoin is *far* more widespread than any other cryptocurrency so far as I can tell. (For example, many Twitch streamers accept donations in Bitcoin, although generally immediately convert to local currency.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ppfmvehy@hope.eyrie.org
Re: Can I donate in bitcoin?
martin f krafft writes: > The benefit of using Bitcoin for DebConf and sprints is to be able to > reimburse people without the costs of cash or international money > transfer. This is, in fact, one of the main ways I could see Debian use > Bitcoin. Ah, yes, that's a good point. In other words, if someone is willing to take Bitcoin or some national currency that Debian does *not* generally hold, it may be cheaper or at least more efficient for the project to hold Bitcoin to reimburse those people instead of converting to either Bitcoin or the national currency in question. This would probably not come up for people who are happy to be reimbursed in USD or EUR, but could well come up for reimbursements in other currencies. I think that would be a great question to ask the treasurer. One step forward would be to start asking people, whenever we reimburse them, whether they would have preferred to be (or even just wouldn't have minded being) reimbursed in Bitcoin instead of whatever currency Debian gave them, particularly people who are getting payments in currencies other than USD or EUR. > So yes, even if we thought that Bitcoin was useful as a reimbursement > means, we could buy them on the spot to send. > Then we simply pay commission twice, once to sell, once to buy. Yeah, and this still might be worth it if that's less than the currency conversion loss, but it would be even better if we had BTC on hand. > And with this ins mind, the effort involved, and the fact that we are > not even facing this sort of problem right now, as Debian holds a > whopping 0.1 BTC (in my hands), I think we could certainly say that > Debian will hold up to 10 BTC (or make it 5, or 2, the actual number > doesn't matter and can be amended) as a buffer and only sell/buy above > that limit. > I see this less as endorsement and more as liquidity. Good point. I do think it would be worthwhile at least gathering information where we can on whether we would be able to use Bitcoin for reimbursements at any scale. We could start that any time -- it's common to survey people about such things in advance of actually offering it. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhqahauu@hope.eyrie.org
Re: Can I donate in bitcoin?
"Thijs Kinkhorst" writes: > The question about where to spend them on is a question on whether to keep > Bitcoin or convert it immediately. However, to the original question of > whether to accept Bitcoin, I say a full yes. +1. Absolutely. > Debian should make it as easy as possible for people to donate to us. > People want to support us, we should be grateful and make this at least > a hassle for them as possible and align maximally with their wishes (of > course informing them about drawbacks, e.g. transaction costs, of > certain options over others). So if there is significant demand to be > able to make such donations, we should accept them. Indeed. My concern is only with holding Bitcoin as Bitcoin. We absolutely should accept donations via any mechanism that we can handle without undue costs. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871ts2neg8@hope.eyrie.org
Re: open source or free software?
Mason Loring Bliss writes: > On Sun, Aug 31, 2014 at 12:28:51AM +0100, Ian Jackson wrote: >> This is an absurd misrepresentation. No-one is threatening to prevent >> you using the words the FSF disapprove of. > And yet, an argument about the merits of saying "free software" versus > saying "open source" is nothing more than an attempt to push a > particular political stance. Everything that we do on a day-to-day basis pushes a political stance. Politics is nothing more or less than the process whereby we negotiate with each other about long-term goals, and try to balance our wants and desires against those of others. *Everything* is politics. You cannot avoid politics. Calling something political is not an insult any more than accusing someone else of using a computer is an insult. Of *course* it's political. Everything is political. If you want to avoid politics entirely, good luck finding a small cabin in the woods where you can withdraw from all other humans. Which, I should note, is also a political act. > It's a waste of time and divisive all at once, when there are more > important things to talk about. Claiming that there are more important things to talk about is nothing more than an attempt to push a particular political stance. :) You can, as I have and as others have, argue that the discussion is not going to reach any new conclusions, and that one should choose what to do about it with that information in mind. But while that may make it a waste of time, that doesn't make it less important. That just makes it unresolvable, which is a different problem. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761h9wb6x@hope.eyrie.org
Re: Code of Conduct violations handling process
Scott Kitterman writes: > Manoj Srivastava wrote: >> How do you suppose we keep the atmosphere from devolving back to >> the poisonous flame-fest days, and enforce various codes of conduct >> policies? I have seen far too many tech conferences without codes of >> conduct devolve into misogynistic and occasionally racist >> experiences. The argument that codes of conduct are forms of censorship >> is frequently made, but, I am afraid, not very convincingly. > None of those things are at issue in this case. It's not relevant. What case? Ian raised a bunch of general questions about how we plan on enforcing our CoC, with no reference to any specific incident. You seem to be convinced that this is about some specific incident and, further, about forcing some specific action about that specific incident, but so far as I can tell, this belief on your part is not based on anything that's been said in this mailing list. Even if you're right and this is all inspired by some specific incident, the general questions are still worth discussing seriously in their own right. There's no need to dismiss the entire conversion (or, worse, be flippant about it in a way that implies that Debian doesn't care about the experience of people on its mailing lists or at its conferences) just because you *think* you disagree with the motives of the person who raised the issues. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mwagwrgi@hope.eyrie.org
Re: Code of Conduct violations handling process
Piotr Ożarowski writes:
> [Ian Jackson, 2014-09-03]
>> Piotr Ożarowski writes ("Re: Code of Conduct violations handling process"):
>>> Some people want(ed) to codify in CoC other political correctness
>>> "things" that I don't agree with. I like our current CoC and I don't
>>> want to change it.
>> Neil Gaiman writes:
> [...]
> that's not what I think about political correctness, quite the opposite
> actually, but if it makes you happy, so be it. Please stop CCing me,
> though - I'm subscribing -project.
This may be a case where people for whom English is not their first
language, or who are otherwise not embedded in the political debates about
the English term "political correctness," may not realize the land mines
they're stepping on.
At least in the United States, people who use the term "political
correctness" in all seriousness as something they dislike and think is bad
are generally people with whom you would not want to share a project and
people who you would be best off avoiding. This viewpoint is correlated
with racism, sexism, and other really anti-social behavior. Its most
vocal public proponents, in the US political arena, are people who feel
the major problem facing society is not that bigotry is tolerated in the
public sphere but that other people dare to call them on their bigotry and
imply it's unacceptable. Expect to see, for example, the KKK ranting
about "political correctness."
However, the term got exported to the broader world, and I suspect that,
outside our particular political hotbed, others are using it as a gentler
sort of term for "getting too caught up on exact phrasings" or "taking
offense too readily." Just be aware that is NOT what many people in the
United States will take the term to mean. By using it, you are risking
allying yourself with people you probably do not want to be associated
with.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871trswojf@hope.eyrie.org
Re: Code of Conduct violations handling process
Luk Claes writes: > On 09/03/2014 07:21 PM, Russ Allbery wrote: >> What case? Ian raised a bunch of general questions about how we plan >> on enforcing our CoC, with no reference to any specific incident. You >> seem to be convinced that this is about some specific incident and, >> further, about forcing some specific action about that specific >> incident, but so far as I can tell, this belief on your part is not >> based on anything that's been said in this mailing list. > Hmm, how can you argue this with the statement that we should not invite > Linus on future conferences? That was not a statement that anyone has made on this mailing list. > True, but it's also unfair to dismiss the specific case because you want > to take it broader. No specific case was raised on this mailing list. I realize that we're not particularly good about this, but in this case I think it is particularly important to be clear about what discussion we're having, and where, to avoid making rash statements in places where they are not constructive and to be certain about exactly what topic we, as a project, want to discuss. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8738c8qiyl@hope.eyrie.org
Re: [Debconf-discuss] Code of Conduct violations handling process
Zenaan Harkness writes: > More facts trickle out. Thank you for stepping up to the plate. > Any chance someone could crush an egg shell already and just post a link > to the brouhaha? Or summarise the events? > Are we that timid, that dominated by the almighty COC, that facts are no > longer politically correct? > I happen to think facts are a useful foundation to a conversation. I don't think the conversation about the specific event that happened is a useful conversation to have here, and I think it has a very high chance of creating huge amounts of heat and smoke to no constructive effect. I realize that the curiousity of bystanders has been piqued (and it would have been nice if we'd been able to have a conversation without doing that, although that's a lot to ask), but honestly I think it would be more rubbernecking than any foundation for constructive debate. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq9kp434@hope.eyrie.org
Re: CoC / procedural abuse
Mason Loring Bliss writes: > Alright. Thank you. I would like to see some public process for review > machinery, and I'd like to see a requirement that rather than "no > objections" there be a quorum for a banning decision, but that these > actions are recorded in debian-private seems sufficient. For the record, we as a project previously discussed and rejected those approaches to bans. I think there's general consensus that we'd much rather the listmasters just take care of it and only get other people involved if there are objections. Being banned from mailing lists is not exactly a major penalty or massive interference with someone's life, nor does it cause immediate harm, so having an after-the-fact appeal process seems sufficient. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4txeo46@hope.eyrie.org
Re: CoC / procedural abuse
Mason Loring Bliss writes: > It just strikes me that we can do better, and I'd like to see us do so. Personally, I think everything you've proposed so far would be doing worse than what we're doing now in terms of the desired outcome here, which is to keep our mailing lists useful, productive project resources and places where we can accomplish our goals. The Debian project mailing lists are not free speech or public debate forums, nor are they the place to try to make one's point by trolling with juvenile sexual references. Given the messages that Zenaan subsequently bcc'd to my personal inbox, I'm quite confident that the listmasters made the right decision in this case. > I value Debian as the most relevant vehicle for distributing and > promoting free software in existence by a very wide margin. The > community already values many important things and acts to do the right > thing in most cases. One place where we fall down is in our application > of force. Preventing someone from sending mail to a project mailing list is not "force" by any sensible definition of the word. It's a rather mild action with little impact on someone's life, particularly if that person is not actively involved in Debian development. Given that, I think we should be optimizing for lightweight process and useful mailing lists instead of some sort of full-blown judicial inquiry. As I've mentioned in previous discussions of this topic, I'm quite comfortable with the thought that lightweight process means that I could get banned for an ill-conceived message even though I *am* actively involved in Debian development. I would happily wait out the ban period while using it as an opportunity to reflect on what I said and why people found it sufficiently irritating to complain about it and for the listmasters to agree. I certainly don't think some sort of complex public process should be involved. The current approach seems far superior. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r3zpl4tn@hope.eyrie.org
Re: DEP-5 (copyright file format) ... gap with practice
Osamu Aoki writes: > It may be good to have a set of specifically defined file types for > exclusion in DEP-5 policy. Then we can skip listing them in the > copyright file. The helper script can generate a template for the > copyright file in line with the actual practice and not to contradict > with the DEP-5 policy. The general rule of thumb appears to be that, provided that the files are DFSG-free and don't pose any surprises or conflicts, there's no need to exhaustively document any source files that are only used as part of the build system and don't contribute code to the binary package. I've wanted to document this explicitly in Policy for a while, but the blocker is that I've never been able to get anyone to commit to a clear enough rule that it felt like something we could put in Policy. For example, I'm not sure if it applies to the build system in general, or if it's specifically for Autoconf, Automake, Libtool, and friends, which have very well-known and standard license behavior and are common across vast swaths of the archive. If we had a concrete rule, we could document it in Policy. Personally, I just document the licenses of all of those files in my debian/copyright files, but I also automated that (with a truly awful and horrible Perl script). And I'm not sure that documentation is really of much use. > ( I think the following must not be skipped.) > ( LGPL-2.0+) > ( * m4/vapigen.m4 ) I think it's fine to skip that as well if one skips any of this, since it doesn't pose any more license issues than any of the rest of the files you list. (Actually, it probably just converts to GPL-2 or GPL-3 for the purposes of generating the build system, given the license of the source of the rest of the output files to which it contributes.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq9c6qf6@hope.eyrie.org
Re: CoC / procedural abuse
Ean Schuessler writes: > - "Charles Plessy" wrote: >> I guess that the story is simpler than this: time-limited bans do not >> seem to be supported natively in Debian's mailing list engine >> (SmartList), so if one wants to see our listmasters use time-limited >> bans more often, then somebody has to spend time to implement this >> function. > http://unixhelp.ed.ac.uk/CGI/man-cgi?at Pointing people at scheduling software that does not, itself, understand the configuration syntax, know how to remove bans, or is integrated into the ban workflow is not helpful. You can assume everyone reading this already knows how at works; that's not the problem. In order to help a team in Debian one has to approach them, talk to them a bit and understand the problem and the current methods used (while being mindful of the fact that they're busy), and then implement something that works for them. Not just lob suggestions from the sidelines that they've generally already thought of but haven't had time to act on. And yes, this is hard, and it means a lot of little stuff doesn't get done, but that's a problem in every environment I've ever seen: work, volunteer, open source, whatever. Small tasks are only easy when you've already invested the effort into being part of the team and understanding their workflow, or when that team has already found the time to put a lot of pre-work into making the small tasks easy for non-members; until then, they require more work to do properly or you just make more work for the team in the long run. The actual code may be extremely simple, only two or three lines. It's getting the right lines in the right place in a way that works for the people who are doing the day-to-day work that's the hard part. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4tfcptf@hope.eyrie.org
Re: Update to reimbursement procedure (now: max 3 months after expense)
Lucas Nussbaum writes: > Also, I don't think that 3 months is unreasonable. My employer applies a > two-week soft deadline, and a one month hard deadline for travel > reimbursements. I don't know how much this carries over to other legal systems, but in the US these sorts of limits for reimbursement from one's employer are for tax reasons. Travel reimbursement from one's employer that isn't processed within some legally-defined time period becomes compensation and the employer then has to pay additional taxes on it. (I forget if this is labor or income taxes.) Given the nature of Debian, I suspect that our travel reimbursements generally end up falling into one of the untaxed gift buckets of money, at least in the US, so the same reasons wouldn't apply. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877g0d2cel@hope.eyrie.org
Re: Being part of a community and behaving
Ian Jackson writes:
> Russ Allbery writes ("Re: Being part of a community and behaving"):
>> We waited two years, during which positions hardened, people got
>> angrier and angrier, and there were increasing demands to force the
>> issue. Serious question: how much longer were we realistically going
>> to wait with zero sign of forward progress?
> The correct reaction to people not adopting your software is to make
> your software better, not to conduct an aggressive marketing campaign
> aimed at persuading upstreams to built it in as a dependency, nor to
> overrun distro mailing lists with advocacy messages.
The traffic on Debian mailing lists that I'm talking about was and is from
people inside the Debian project who believe, as a matter of technical
judgement, that systemd is better, and want their favorite distribution to
use it for exactly the same reasons that you wanted your favorite
distribution to use upstart. I find it really quite irritating, and
disturbing, that you are belittling other people's right to hold and
advocate an opinion that differs from yours, and trying to dismiss the
opinions that they have arrived at with just as much thought and care as
you as some sort of artificial, underhanded, or deceptive campaign.
Please consider the possibility, just for a moment, that what you see as a
"marketing campaign" is simple enthusiasm of technical people for a
technical project that they find delightful and enjoyable to use, and that
they would like to see broadly adopted because it solves problems for
them.
But putting that aside for the moment, I'm talking about what *Debian*
should do. Regardless of what theories you have about what systemd
upstream may or may not do, we, as a project, don't have control over
that, nor should we. We only have control over our own behavior. So the
fact remains: there was a heated, antagonistic project argument over two
courses of direction, and every attempt to find some way to maneuver
around that ran into fundamental conflicts of either technical judgement
or foundational principles. So what should we, as a project, do in that
situation?
Please, when trying to answer this question, try to extend to all sides of
this debate the respect of believing they hold their opinions as deeply as
you hold yours. For example, I consider the GR that you are currently
proposing to be such a monumental violation of fundamental principles of
Debian that, should it pass, I will have to seriously consider whether or
not I want to continue to be part of this project. I realize that this
stance is probably baffling to you; please understand that I find your
stance equally baffling. That is *exactly* the problem: we are at
loggerheads, and yet the project still needs to make a decision. Because
not making a decision is *also* a decision that will *also* make some
people feel fundamentally unwelcome, or like Debian is acting contrary to
the principles they thought they joined the project for.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fvdnf0wu@hope.eyrie.org
Resigning from the Technical Committee
work being governed. This was true for me when I was more active in Policy and Lintian work, and isn't true at the moment. In short, I don't want to be that person who never does anything themselves, but who joins all the conversations to complain about how everything is being done. I can feel that happening, and I want to stop it before it starts. We've made two decisions recently related to systemd, both of which I misjudged. By that, I don't mean the decisions themselves (my feelings on that are more complicated, and I'm not going to get into that here), but the way that they would be received and the ways they could be interpreted. If I'd made either decision knowing that, it would be one thing, but the reaction caught me by surprise in both cases, even though in retrospect I should have recognized the problems. There are other people on the technical committee with more technical expertise and more institutional knowledge. The primary skill that I try to bring to TC discussions is to catch exactly this sort of thing, and to try to apply empathy in line with the values that I care the most about in Debian: maintainer empowerment and the ability of people to work on things that bring them joy. I'm not successfully doing that at the moment. It's clear to me that I need to be doing a lot more work than I'm currently doing in talking to people, understanding their perspective, and getting more social context in order to do this effectively. If I'm not going to do that work, and right now I don't have the additional resources to spend, I need to step down and let someone else take their own approach to the TC role. This is particularly true right now, where every decision the TC makes that has anything remotely to do with systemd is incredibly fraught. It's going to be parsed and examined and dissected, and has to be extremely careful in order to avoid making existing hurt deeper. I don't believe I have the resources to do that work right now. Finally, I've been thinking hard about Debian project governance in the light of Joey's resignation, as I'm sure many of us have been. I've also been thinking hard about many of the subsequent discussions and reactions. As I've mentioned in several recent threads, I think governance of this sort of project is a very hard problem, particularly when the project is deeply divided on many aspects of a particular question. I do still feel like governance is necessary; philosophically, I'm one of the people who believes that any group of people larger than a small team are going to need some sort of governance structure so that disagreements aren't paralyzing. But I think Joey captured my feelings very well in his blog post at <https://joeyh.name/blog/entry/on_leaving/> where he talks about the importance of being able to try out decisions and iterate. I think the agile philosophy got a few things right: find ways to reduce the cost of change, empower individuals to make choices and act on them, and reduce the cost of failure and embrace iteration instead of trying to prevent failure in advance. And I'm increasingly dubious that Debian's decision-making processes as currently used, particularly the technical committee, are compatible with that approach. My largest concern in stepping down from the technical committee is that I'm just avoiding working on something difficult, and thereby making the problem worse. I believe that some governance method is necessary, and given that I have strong feelings about this and keep thinking about it, I should stay and make it better. But it's become clear to me over the past week or so both that I don't have any great alternatives that I feel comfortable advocating, and that I'm exhausted with the discussion. I think project governance is a hard problem, and a worthwhile problem, and I hope that someone with good ideas will step forward and work on that problem. Debian is one of the largest free software projects, and one that faces a large number of hard decisions. If we can do that work well, it would be a valuable contribution to the broader community. But, right now, I don't feel like I'm helping that process, and at times am making it worse. Thank you, all of you, for your trust in me over the past six years as a project representative for technical decisions, and for the wonderful support and encouragement that I've received over the difficult past year. I'm probably going to take a break from discussions and project arguments for a while, and then hopefully will be back to work on more of the day-to-day technical work of the project. I've been giving that involvement a lot of thought as well, but this is a project that I want to stay part of regardless of the outcome of the current GR. I have strong opinions, but I also have gre
Re: Can I still depend on Debian?
Rhy Thornton writes: > More concerning than that is that systemd won't be producing human > readable log files. Hi Rhy, There is no truth to the rumor that systemd doesn't produce human-readable log files. In a recent discussion on debian-devel, we identified a bug in the current syslog-ng package in jessie that causes syslog-ng to not be started properly under systemd. That may be behind some of the problems that people misinterpreted as being somehow intentional. That bug will be fixed for jessie, and wouldn't have affected people using the default of rsyslog. The systemd journal is supplemental, and can be ignored completely (apart from some rare edge cases involving extremely high log volumes, where you would already be doing custom tuning to make syslog cope). All the log files that you expect to have still are there in the same format they are now. I've been running systemd for about a year now, and don't use the journal at all except via systemctl status. I still grep /var/log because I always take a long time to adopt a new tool. I noticed precisely zero change when switching to systemd. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mw7pwgyw@hope.eyrie.org
Interpreting the init system GR results
I originally posted this in a thread on debian-private, but on further reflection it seems appropriate for a broader audience. There is quite a lot of discussion in various places about what the recent GR result means. Some are concluding that systemd won in some way that implies Debian is not going to support other init systems, or at least that support for other init systems is in immediate danger. A lot of that analysis concludes that the pro-systemd "side" in Debian won some sort of conclusive victory. I have a different perspective. I think we just had a GR in which the Debian developer community said that we, as a community, would like to work through all of the issues around init systems together, as a community, rather than having any one side of the argument win unambiguously and impose its views on those who disagree. There were options on the ballot that clearly required loose coupling and that clearly required tight coupling. The top two options did neither of those things. The second-highest option said, effectively, that we should feel free to exercise our technical judgement for our own packages, but should do so with an eye to enabling people to make different choices, and should merge their changes and contributions where possible. The highest option said that we don't even want to say that, and would instead prefer to work this whole thing out through discussion, respect, consensus, and mutual support, without giving *anyone* a clear mandate or project-wide blessing for their approach. In other words, the way I choose to look at this GR is that the project as a whole just voted to take away the sticks that we were using to beat each other with. In a way, we just chose thet *hardest* option. We didn't make a simplifying technical decision that provides clear guidance to everyone. Instead, we made a complicating social decision that says that, sorry, there's no short cut to avoid having to talk to each other, respect each other's views, and try to reach workable collaborative compromises. Even though it's really hard, even though everyone is raw and upset, that's what the project as a whole is asking us to do. Are we up to the challenge? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871toyj2bh@hope.eyrie.org
Re: Systemd
Christian Mueller writes: > I just tried to update to Jessie and couldn't remove systemd because > there were already dependencies to it which I could not ignore (I'm > using XFCE, thus this is not strictly a Gnome thing): systemd (the collection of software) is required for a lot of desktop environments because logind (which is part of the systemd binary package) has replaced various previous ways of addressing console login and permission handling (by virtue of being a rather better implementation of those needs). That doesn't mean that you need to run systemd the init system. In other words, if your concern is what init system you're running, you're removing the wrong package. The package you want to remove is systemd-sysv, which is the package that configures systemd to run as the system init system. If you're instead trying to remove every piece of software that's part of the systemd source package, that's not really supported and is unlikely to be supported for jessie, so you're on your own there. You might be able to make it work, and other people are also interested in making that work, so you may find some help, but it's not a release goal and it probably won't work for everything. It's a ton of work to completely avoid logind for desktop environments, and there isn't a lot of enthusiasm to do that work since logind works independent of running systemd as the init system, using systemd-shim, and solves a lot of problems for a desktop environment. > Quite a few pieces I may or may not be willing to part with but the > printer driver is something I definitely need. If I had to guess, I'd > say the previous udev-based script which loaded the printer firmware has > been replaced by systemd events of some sort but I didn't really > investigate. Doubtful. It's probably just assuming logind instead of ConsoleKit, which is something different than the systemd unit file support. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d26aoxye@hope.eyrie.org
Re: Systemd
The Wanderer writes: > On 01/19/2015 at 11:52 PM, Russ Allbery wrote: >> Christian Mueller writes: >>> Quite a few pieces I may or may not be willing to part with but >>> the printer driver is something I definitely need. If I had to >>> guess, I'd say the previous udev-based script which loaded the >>> printer firmware has been replaced by systemd events of some sort >>> but I didn't really investigate. >> Doubtful. It's probably just assuming logind instead of ConsoleKit, >> which is something different than the systemd unit file support. > The chain is printer-driver-postscript-hp -> hplip -> policykit-1 -> > libpam-systemd -> systemd. > So apparently it's PolicyKit, not ConsoleKit, but still almost certainly > logind. I think that's PolicyKit wanting to use logind for something it previously used ConsoleKit for, and the changelog for the package seems to back that up. Really, the vast majority of dependencies on systemd in the archive are for things that want to use logind, generally indirected through libpam-systemd, and generally stuff that used to use ConsoleKit. The single most productive thing that people who don't want to use logind at all (and have the cycles to put into development work towards that end) could do is either revitalize ConsoleKit or reimplement logind in a way that would be acceptable to all of these various upstreams, including the DEs and PolicyKit. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4owgall@hope.eyrie.org
Re: Systemd
ain in the ass, so it was miserable to have to do it, but we needed to do it to get where we wanted to go, so we did. systemd is no different -- it's just software. It's *free* software, in fact, so unlike with /bin/login where we had to reverse-engineer code for which we had no source, all you have to do is grab whatever bits of systemd you still need, tack them on to whatever you're doing, and as long as you're okay with using the GPL, you're all set. You can even do that on an ongoing basis. You're about as locked in to systemd as you are into readline. If people write a widely-useful piece of software, surprise surprise lots of other software starts using it. That software will be written to that API. That means that, if you want to replace it, you will have to reimplement that API or convince a lot of software to change what it relies on. But that's just *normal*. That's how free software has always worked. That's not lock-in -- or, put another way, if that's lock-in, 90% of the software in our archive is locked into one thing or another. The alternative would be vast amounts of basically wasted effort writing two implementations of absolutely everything, not because you actually have problems you're trying to solve, or any unique approach to the problem, but just so that you can say that you have two implementations. If that sort of thing turns your crank, by all means, knock yourself out -- I'm happy to see people pursue anything they like to work on in the free software world. But that certainly doesn't sound fun, interesting, or particularly useful to the broader world to me. I'm quite happy to have just one implementation of something as long as I can fork it when I need to change it. systemd is under the GPL, so I have all the free software freedoms, so I'm happy -- if anything seriously bugs me about it, I'll fork it with other like-minded people. If there aren't enough other like-minded people, that's *my* oproblem, not systemd's, in exactly the same way that the FSF Emacs maintainers have no obligation to keep XEmacs development alive just so that we have two good implementations of Emacs. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tmou2r1@hope.eyrie.org
Re: Systemd
Russell Stuart writes: > On Tue, 2015-01-20 at 21:22 -0800, Russ Allbery wrote: >> Pretty sure there's no dependency on journald. I think you have to use >> systemd's syslog passthrough if you're launching systems under systemd >> as an init system (although I'm not 100% sure about that even), but >> that's not the same thing as journald or the journal itself, and that's >> systemd as an init system, not logind, which can run separately. > No, the dependency is unavoidable. Try running "sudo journalctl" some > time - you will the stuff that it has written under to /run/log. I thought you could turn that off too if you wanted to, but I must admit that I never cared enough to investigate. > I am not comparing us to Microsoft. We hold us to higher standards than > that. Well, I don't mean to be argumentative here, but I think this is a bit disingenous. When you use the term "lock-in," comparing systemd to Microsoft, or at least IBM or other old-school monoliths that used vendor lock-in as a strategy, is *exactly* what you're doing, whether you intend to do so or not. This is the emotional baggage and historical weight that term carries. If you mean to make some other criticism, consider using other words. > Journald it an excellent starting point for a discussion on lock in. > After all why are we forced to use a binary logging just because Looks like you sent this prematurely, but I'll pre-emptively say that I just don't buy this argument at all. You're "forced" to use binary logging in much the same way that Linux is "forcing" you to use serial ports because it's hard to not get a /dev/ttyS1. If you don't want it, ignore it, or modify the code to not create it if you care enough. Let me be a little more explicit and blunt here. The WHOLE POINT of the DFSG and the free software movement was to prevent lock-in systematically via our licensing terms. systemd is using those licensing terms, and is not software-as-a-service or fallling into any of the other gaps that have been much-discussed. It's old-school, old-style free software in which you get the source and the code and there is no third party or remote service involved. So either those licensing terms and the foundation of the free software movement are inadequate to their purpose even for software that's straight in the middle of the original target area for free software, or systemd is not lock-in. I know which of those I think is the case. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k30goye9@hope.eyrie.org
Re: About the recent DD retirements
Gunnar Wolf writes: > And... Sure, Debian's attractiveness has also morphed. Those of us who > joined a long time ago (I'm "younger" than you on the project, only > since 2003, but it's still a very long time) have changed our life > circumstances, possibly our interests, maybe even our ideological > viewpoints. And yes, maybe (but that'd fuel a different discussion) > Debian is less attractive in general to the young developer population > to what it was in the past — I don't remember where I read that the > median birth year of DDs has remained almost constant, which means that > (yes) we might be attracting more senior developers (after all, Linux is > no longer just a toy), but also... That we are failing to attract young > talent. Partly this is because we've been so successful. Back when I started working on this stuff in the mid 1990s, packaging and distributing software was a hard problem. The existing solutions were rather dubious, portability to the various UNIXes was quite challenging, and we all didn't really know what we were doing. This situation has improved *radically*, largely (although not exclusively) due to Debian. The world is now full of high-quality packaged software, and even the relatively crappy packaged software or half-assed packages (fpm with no attempt at metadata, for instance) are better than the state of the art was in the 1990s. One side effect of this is that packaging feels like a solved problem. That doesn't mean people aren't willing to work on it, but it isn't the cutting edge of what we used to call sysadmining and what's now called SRE. In talking to professional colleagues about this, most of them are not particularly interested in packaging, not because they think it's unimportant, but for the same reason why they aren't interested in coreutils. cp and ls just work, which is great, but it also means they've never felt any particular desire to work on them. Addresssing this problem is tricky, since it's a *good* thing that we've solved a problem reasonably well and packaging is no longer what's actively painful for people (and thus motivating them to do something about it). But there are still a lot of hard and interesting problems, which are worth working on. So, one, we need to figure out how to make those problems apparent and provide people leverage to work on them. But we should also consider that the project has a lot of appeal for people who *aren't* interested in being on the cutting edge of something, and who find maintaining their corner of a well-established infrastructure rather attractive. Which requires a different kind of recruiting. But some of it is also inevitable. A lot of smart, talented people want to work on really hard problems that are currently major pain points, since that's where they can have the most leverage. Packaging just *isn't* that any more, so it's to be expected that a lot of those people are off working on something else that is: crypto, or social networks that aren't driven by advertising and surveillance, or container deployment, or trying to build a programming language that can finally replace C as a safer language for writing our core infrastructure, to list a few obvious examples. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oaprpm6f@hope.eyrie.org
Re: About the recent DD retirements
Tollef Fog Heen writes: > This also points at something not explicitly mentioned: Our support for > multiple versions of the same package is pretty much non-existent. (You > can hard-code the version into the package name. This causes NEW pain, > this kinda breaks dependencies and doesn't map well to how at least some > languages like Ruby handles dependencies.) > This means that if you use system packages and want to have two > applications that both want foo.jar installed, but different versions > (since they need different APIs or different bug compatibility), we > don't support that well. For C libraries, there are sonames and all, > but those largely doesn't exist for other languages and fixing that > would be a huge undertaking with, IMO, pretty poor prospects for > success. Yeah, this is a cause of serious pain. It's probably the number one objection to using Debian packages to distribute software internally. People don't like using a system that breaks down when different pieces of software need different versions of some dependency, and this is very, very common. Hence the popularity of things that fix this, such as Python virtual_env, Java's tendency to use per-application JAR trees, Ruby's support for doing something similar, Nix, or languages like Go that do static compiles. You can work around this problem by using containers for everything (or, similar but less modern, chroots), but that introduces a bunch of new pain. A clean way to let, e.g., Python modules at different versions co-exist would be really nice, but it's a very hard problem. You'd probably have to completely redesign the way that packages are built and deployed, similar to what Nix does. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/873870oskw@hope.eyrie.org
Re: About the recent DD retirements
Tollef Fog Heen writes: > That requires tracking ABI versions. People often don't do that. They > (effectively) statically link and then just test the resulting binary > and distribute that, including all dependencies. > There are certainly downsides to this approach, but it's what lots of > the world seems to have fallen down on. The primary drawback is that if there's a problem with some dependency, you have to rebuild the world, and you have to backport the fix to the problem to every version of the dependency you're using. The former is a problem for smaller sites but something large web-scale sites have probably solved in some way. Rebuilding the world is something that, culturally, gets prioritized pretty highly. But the backporting problem is still pretty nasty. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ppa3oi2y@hope.eyrie.org
Re: Why are in-person meetings required for the debian keyring?
Christian Kastner writes: > And I maintain that those people cannot be trusted with unrestricted > upload rights to the archive. That person-noone-has-ever-met but > occasionally-prepares-and-uploads-packages could just be a well > motivated person (or a group of people -- who knows?) hoping to > eventually compromise a popluar OS such as Debian, with zero risk of > personal consequences, or criminal prosecution. I think the point is that so could the person who showed up at DebConf. Once you start postulating a sufficiently motivated attacker that they would be willing to take the time to establish a contribution track record and go through the NM process, showing up at DebConf with a forged ID is not increasing the difficulty of the attack by very much, nor is it increasing the risk by all that much. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mw4iao0v@hope.eyrie.org
Re: Any plans to add Pale Moon browser to the repository?
fidelis writes: > Btw in in regards to a conversation I had with one of you about Pale > Moon browser being added to the repository and them saying you weren't > allowed to. > "Repository/package maintainers are free to add unaltered versions of > the Linux browser to their repositories. Noncommercial, Open Source > operating systems are exempt from binary destribution limitations if the > browser is otherwise not materially changed or reconfigured. > Please see the redistribution license: > http://www.palemoon.org/redist.shtml specifically > point 8. I'm afraid that we can't include Pale Moon in Debian with that sort of license. The "not materially changed or reconfigured" part is an obvious violation of DFSG #3 since it prohibits large classes of derivative works. More subtlely, it's also a violation of DFSG #6 and (sort of) #8: Debian derivatives that are commercial distributions would not be allowed to include it, and we don't accept software in Debian main that has these sorts of license terms that limit the ability of derivative distributions to include it. Even if Debian itself will satisfy the licensing terms. (Please note: this response is based mostly on the information included in your message. I only looked cursorily at the actual license of Pale Moon to confirm that it looks very non-free by our definitions.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mw3h4k5d@hope.eyrie.org
Re: Survey on Bug Tracking Tools
Dominik George writes: > If any Debian contributor BELIEVES that the use of Google, and the > like, is a good thing, then the illness lies in the divergence between > their contribution and their values, and in that case, I honestly do > NOT respect that and consider it harmful. Please note that there are a lot of shades of feeling about Google between "use of Google is a good thing" and "I will never use Google because they are evil." The world is full of compromises. Sometimes unethical companies or poor products are nonetheless the best immediate tool to get some other job done, either for some greater good or, practical necessity being what it is, making money to put food on the table and put a roof over one's head. Being this absolute can often be just a way of beating up on people who already have it worse than you do. You have the luxury of making idealistic but sometimes impractical choices. More power to you! That's a great way of driving some things forward. But not everyone has that luxury, and they can still can provide very positive contributions to the project. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zj3z8t79@hope.eyrie.org
Re: cdimage?? What should we call it?
Steve McIntyre writes: > We called our main installer images distribution site > cdimage.debian.org a long time ago, when that was all it published and > most people downloaded images of CDs. Ummm. Things have moved on in > the intervening years, and this name is looking more silly over time: > * lots of people are using USB sticks > * we're providing live images that don't fit on CD > * we're providing cloud images (Openstack so far, with others coming >soon!) > So, I'm looking for suggestions. What should we call it? I had > initially thought that images.debian.org is more generic, but it's > also likely to confuse people into looking there for pictures... :-) install.debian.org? (get.debian.org is good too.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: cdimage?? What should we call it?
Riley Baird writes: >> What about get.debian.org ? (There is get.debian.net) > Off-topic, but I just had a look at get.debian.net, and it uses Google > Analytics, which seems strange for a Debian site. debian.net aren't Debian sites, generally. debian.net == some Debian developer set up a DNS record for some reason. It's completely self-service, IIRC. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian 8.1 Question
Tasha M Wenner writes: > I work for Raytheon, reviewing Freeware and Open Source Software > licenses to ensure our programs can and will comply with the > restrictions and requirements set forth in the license terms. I have a > request for Debian 8.1, and I am unable to truly determine the license > that governs Debian. I saw where it is free and numerous licenses are > provided, but nothing that says what actually covers the software. > Could you please provide the full license for Debian? Hi Tasha, Debian as a distribution is a compilation of a wide variety of different software packages, each of which has its own license. Debian does not put a separate license on the compilation as such. Accordingly, there is no single license; every work in Debian has its own, as documented in /usr/share/doc//copyright. What Debian does guarantee is that every package in the "main" archive area (everything that is part of Debian proper, not the supplemental distributions that use our infrastructure but are not part of Debian, such as the non-free archive) has a license that satisfies the Debian Free Software Guidelines. Those guidelines are documented here: https://www.debian.org/social_contract#guidelines -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Repository Link are NOT https://
tom writes: > I have discovered that non of the repository links is https:// . Is it > not safer to use only https:// connections. > And as well the download of a debian distro is only http:// . > Sorry to say that but nearly all other distros used for the downlaod > link https:// . But as repository links they all used only http:// > connections like debian. It doesn't matter for the integrity of the packages. APT does a much stronger validation via a public key signature and doesn't rely on transport security at all. It does potentially matter as a source of information leakage, since it allows others to know what packages you're downloading to your host. Unfortunately, it's hard for us to deploy a consistent certificate through our entire mirror network, so it's a bit of a challenge to enable TLS for package downloads. It's also not clear that encrypting the package download channel actually buys you much in terms of privacy, since an attacker can still do quite a lot by correlating the amount of traffic with the sizes of packages. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Software Freedom Conservancy needs our cash
Stefano Zacchiroli writes: > We already pay for those services. There is a forfait amount of money > that Debian pays to Conservancy per year (1000 USD, IIRC), which > corresponds to a forfait amount of lawyer hours that Conservancy give to > Debian per year. If any enforcement (or other legal) action will require > more than those hours, Conservancy will bill Debian for the extra time. I thought we paid a retainer to the Software Freedom Law Center, not the Software Freedom Conservancy. Am I confused? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Renaming the Debian Project
Daniel Pocock writes: > c) do you have verifiable references for the other allegations you are > making about the project founder? It is very inappropriate to post > things like that without citing some solid evidence, doing so only > undermines your own credibility. Given the timing of this message, it's a pretty obvious troll. If there were a legitimate point, it could have been made any other day other than this day. The only reason to choose today to post the original message is to stir up shit. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Renaming the Debian Project
laro...@larocca.io writes: > On Wed, Dec 30, 2015 at 02:03:40PM -0800, benjamin barber wrote: >> It's unfortunate that Debian is named after Debra and Ian, because >> having the project named after a white supremacist, who used his >> ex-wifes name as an trophy. Being that the current year is almost 2016 >> and is 20 years after Debian started, we should look to the future and >> not the past. We shouldn't tolerate the project being named after a >> person who uses the N word, or marginalizes women who've been sexually >> assaulted. Instead I think we ought to rename the project "Euphemia", >> which means "good speech" and represents our code of conduct, as well >> as being the name of Euphemia Lofton Haynes the first African American >> woman who earned a math PHD. > The neo-tribalist, pseudo-leftist, anti-materialist form of ideology > that took shape during the famed '80s Culture Wars--"identity > politics"--seems to have had a slight resurgence in the past few > years. So much for those who take it up. > "First as tragedy, then as farce." Speaking as someone who proudly supports something that you probably call identity politics, the above was nothing of the sort. It was pure shit-stirring from someone who (generously) hadn't heard about subsequent events after Ian's last public words or (much more likely) decided to use them to try to spark exactly the sort of reaction that you're posting and a subsquent big fight over it. There will be plenty of time to argue about social justice, identity politics, and so forth as it pertains to Debian. It doesn't need to be done based on this particular fodder, today. Please have some respect for the recently deceased, who gave a great deal to the broader community and built some amazing things. Thank you, Ian, for everything that you built for all of us. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Frustrated
palmal palmal writes: > Here is the answer:why you allowed microsoft to get inwolwe and build > their product on your operating system? Anyone have any idea what this is referring to? I think the original poster has a whole bunch of misinformation (and I'm sorry that they had a bad experience with jessie), but I have no idea what this specific point could even mean. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Frustrated
koanhead writes: > The cake reference makes me think of Microsoft's presence at LinuxFest > Northwest last year in Bellingham, WA. MS had a booth there touting > their Azure service and giving out blue cake. Possibly they have given > away cake at other venues as well- I understand they can afford a lot of > cake. > When I saw them again at LinuxCon they seemed to have run out, but > luckily the Sheraton had the cake situation covered. Well, they did buy Minecraft a while back, so at this point I would hope that they have the supplies for infinite cake. That doesn't mean that they actually *have* infinite cake, since the auto-crafting requires a mod, but maybe they wrote an in-house mod (since I can't imagine they'd use the Internet ones). Hm, although, without auto-crafting, they probably don't have enough chests to store the infinite cake supplies. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: third-party packages adding apt sources
Daniel Pocock writes: > b) many upstreams appear frustrated about getting their package > officially supported in Debian. Sometimes there is good reason their > package doesn't belong in Debian but sometimes it is more about inertia > in Debian or the upstream isn't aware about backports and thinks their > package will be stuck at a particular version forever One of the big reasons why organizations do this is because they provide packages for stable users and want control over exactly when they ship new packages to those users without meeting the standards for stable update review (which are very strict). Consider Google Chrome's packages, for example, which are one set that use this method. I don't think we can provide that inside Debian, at least without some pretty significant changes to how we handle stable releases that are contrary to some of our goals for stable. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: third-party packages adding apt sources
Daniel Pocock writes: > Another thing comes to mind: making sure that even if the user > explicitly allows some other repository, they are protected from package > updates that come along and replace other things like apt itself, libc, > bash, gnupg, ... While this would be nice to prevent accidents, it's not clear that you can really establish any security guarantees. You can protect against some very obvious things, such as wholesale replacing core packages, but postinst scripts still run as root and can do anything they want. So you don't get any real security benefit here that I can see. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian slogan / tag line / emphasizing freedom
Daniel Pocock writes: > Debian has been using the slogan / tag line "The Universal Operating > System" for as long as I can remember. > It is a good choice and it represents the aims of many contributors, but > is it the optimal choice today? > For example, has there ever been discussion about replacing it with a > slogan that puts an emphasis on freedom, another value that is important > to many contributors? That's always spoken to freedom to me, since something that isn't free can't be universal. By definition, access to it is restricted in some way to some blessed set of people, either by money or by some other legal arrangement, which is the opposite of universal. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Publicly-readable list for only DDs and DMs to post to
Ian Jackson writes: > I think that such a list would provide an opportunity for discussions > to move out of -private, which is of course an even bigger barrier to > participation. I believe threads stay in -private long past the point of requiring privacy, not because people are particularly enamored of the audience or posting restrictions there, but because discussion threads almost never move. People always tried to move threads in Usenet as well, and I'd say it works about 5% of the time. People almost always just keep replying in whatever forum they saw the original in. This isn't a problem specific to Debian. I see this all the time at work too. The only thing that can sort of help is if *everyone* in the discussion is using something like Gmail that doesn't do proper threading and instead shows every discussion as a linear discussion, and everyone does reply-to-all to the last message of the discussion, at which point you can mess with the recipients and sometimes it will stick. But with any diversity of mail clients or proper threading, this goes away. And the threads start in -private due, usually, to legitimate privacy issues. I've rarely seen threads *start* in -private for no apparent reason. Rather, thread drift happens (which is pretty much a constant), and the thread never moves (which is pretty much a constant). I'm extremely sympathetic to the problem you're trying to solve, but I think it's a fairly fundamental UI issue in how email works, and I'm dubious that creating another list will help much. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Publicly-readable list for only DDs and DMs to post to
Clint Adams writes: > On Mon, Jul 18, 2016 at 02:31:12PM -0700, Russ Allbery wrote: >> I'm extremely sympathetic to the problem you're trying to solve, but I >> think it's a fairly fundamental UI issue in how email works, and I'm >> dubious that creating another list will help much. > Right, what we need is a way of punishing people for replying to > mailing list threads. It's important in order to make the project feel more welcoming and open. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Publicly-readable list for only DDs and DMs to post to
Clint Adams writes: > On Mon, Jul 18, 2016 at 03:17:20PM -0700, Russ Allbery wrote: >> It's important in order to make the project feel more welcoming and open. > I bet that's truer than you think it is. It's possible for it to be both true and ironic at the same time. :) Also, part of what makes being more welcoming and open hard is that different people find different things welcoming and open. There are some obvious basic ground rules (treat everyone decently, don't be exclusionary), but when it comes to preferences on chatty versus on-topic, people vary. A lot. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: public stats about posts in -private
Daniel Pocock writes: > On 20/07/16 03:46, Gunnar Wolf wrote: >> As one of the people who track retirement messages (as keyring-maint >> often does the first steps of the retirement process, and pass the >> ticket on to other groups later on), I agree with Jonathan. By far, the >> most often cited reason is "I have no time nor motivation to do this >> properly anymore" or some variation on it. Real (that is, analyzable) >> reasons are almost never even mentioned. > I would agree that is one of the things that could be summarized. > Sometimes people also mention family reasons or changes in employment. > Maybe such insights aren't very dramatic but even that much hasn't been > stated publicly before because those emails are sent on debian-private. Except it has. Every time this topic comes up, and it has several times before, someone says publicly just what Gunnar said above. I'm quite dubious anything more formal is going to add additional value. > It could also be interesting to ask people who retire to complete a > small survey with the stats becoming public. This is one of the practices that I *detest* when companies do it to me, and which leaves me with a bad final impression of that organization, so let's not. We already have enough (necessary) bureaucracy in our exit process to properly deal with authentication. "I no longer have the time or energy for Debian." "Great, could you fill out this survey about Debian?" -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Replace the TC power to depose maintainers [and 1 more messages]
Ian Jackson writes:
> Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
>> We should go for "weak code ownership" instead, which *in theory* is
>> what we already have
> Well, no. What we have is a kind of sticky door when the current code
> owner is cooperative. And many other people have various amounts of
> influence. The release team have a certain amount of power. But if the
> current code owner is uncooperative, they have almost absolute hard
> power.
> The TC has never desposed an existing maintainer, and very rarely even
> overturned an individual decision.
There is a widespread perception that doing this would frequently cause
that maintainer to leave Debian. This is quite the mental hurdle to
overcome, and the exhortations to not care about this (the subtext of
"Debian is better without people who would leave because of that") don't
really help. People get their motivations from different sources. It's
hard to figure out how to balance this against the demotivating effects of
an ongoing bad situation.
I know you know all this, but I want to restate it for the record because
it affects heavily how I view this proposal.
I think we all agree that this is a bad situation to be in, and we should
not block other active maintainers because we're afraid that we'll
demotivate someone who isn't doing a great job anyway. In other words, I
don't think anyone views the above situation as a *feature*. However,
it's still psychologically difficult, and I don't think it becomes less
difficult by ramping up the confrontationalness of the hardest cases (the
ones that come before the TC). The semi-paralysis is largely already
because the situation is so fraught, and you're proposing making it even
more fraught.
I think this is partly what Zack is getting at. If we want to make the
situation less fraught, and make changing maintainers or allowing other
people to upload packages a less difficult step to make, formalizing this
as a remedy in hard cases is less effective as just undermining the
concept of maintainership *in general*. This makes all disputes over
maintainership somewhat less fraught by making maintainership less of a
thing that people feel possessive about, which in turn will make the hard
cases easier to handle as well.
In other words, I completely agree with you on the problem, but I feel
like you're tackling it from the wrong end, since hard cases make bad law.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Greetings from dash - Follow up
Dash Press writes: > Hey guys > i send you an email recently about our > “Security Paper” Ver 0.1.7 > https://dashpay.atlassian.net/wiki/x/CYCHBQ > as a follow up i wanted to ask for future removal of the MD5 and SHA1 > checksums as emphasized in chapter I.5.5.2.1.3 due to security risks. In > addition please mention Apt-Transport-Tor integration for future Debian > releases (chapter II.3.1#HINT 2). And finally please ask to remove HTTP > mirrors and only provide HTTPS connections for downloads instead (chapter > I.5.5.2#ATTENTION). Hi! You seem to have mistaken the Debian Project for a commercial company. This isn't how Debian works. If you find those things interesting to work on, you are welcome and encouraged to join the relevant team and work on those tasks yourself, after getting consensus from the other members of the team. (This will require active participation in the project, not just writing documents on some closed-source wiki site that apparently have *six-deep nested sections*.) There are a variety of reasons why use of HTTPS is not as compelling as you might think. It's been much-discussed in the project. Some people are interested in it and may work on making it happen, but it's not really a project priority and isn't likely to become one, since the benefits are fairly marginal and debatable. In any case, if you would like to discuss these topics, please discuss them with us, like a human being talking to other human beings, using your name and not a role account, and not using some external specification document. I think many of us get *way* more than we need of that sort of thing in our day jobs, and in Debian we have the luxury of ignoring such things completely. :) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Formal declaration of weak package ownership in source packages
Philip Hands writes: > Until now I've tended to be irritated by the way courts do that, but > suddenly I have more of an understanding of why they do ;-) > Having someone that is familiar with court processes on the TC might > help. I don't know if any of the current batch have a legal background. > I wonder how long it would be before people start acting as advocates to > guide others though our increasingly arcane rules -- that might actually > work quite well though. Perhaps we'd have a better process if someone > not involved in the dispute acted as champion for each party, so that > even timid folk could be confident that the person they were dealing > with was on their side. This is not a fully-thought-out idea, but reading this, it occured to me to wonder if we're erring here in going farther down the path of legal process, which inherently emphasizes the grievanace and personal responsibility aspects of the problem. A lot of the problems that come before the TC strike me more as project management problems than legal problems, in that the question isn't about liability and harm so much as it's about technical and procedural approach and about tradeoffs between several possible good approaches. The TC is quite competent to make judgement calls on the relative importance of several different possible technical outcomes, but that doesn't necessarily help if the maintainer still disagrees with their call and isn't happy with letting their judgement be overridden. (I have a talk I gave at work on the emotional and personal motivations of free software work that I should reproduce in some more public forum.) But treating this as legal action puts hard emphasis on rights and responsibilities and other such things that I think tends to make this all more fraught. In a workplace, this sort of thing is usually sorted out by a project manager instead, who talks to the various stakeholders, tries to build consensus for some general approach forward, puts timelines on it, and then holds people accountable to those timelines. This is always trickier to do with volunteer work, where you can't really enforce any timeline, but the overall strategy feels better to me. Project managers come with the base assumption that this is not an adversarial process, everyone is trying to produce the best outcome, but there are both resource and direction conflicts that have to be resolved somehow. Project management in general is a huge gap in the free software world, and I think we're no exception. It's easy to underestimate the power of a good project manager unless you've worked with one. Quite a lot of this process feels to me like it would benefit hugely from a project manager, including the perpetual complaint that the TC is too slow, which is one of the core things that project management can help with just by keeping the eye on the specific actions that have to be taken to move things along. And we should strive to emulate processes that have the properties we feel we're missing, so if more timely action is a goal, emulating legal process (which is notorious for interminable delays) may not be a good idea. One of the roles of project managers everywhere is to guide people and projects through whatever process is used by the larger organization. If there's anyone out there reading this with project management experience who has been wondering what they could volunteer to do to help Debian immensely -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: contacting Debian is too easy to get wrong
Ian Jackson writes:
> Ritesh Raj Sarraf writes ("Re: contacting Debian is too easy to get wrong"):
>> When a user asks for a question, most usually end up on a web
>> forum. Developers mostly prefer monitoring hand-picked mailing lists
>> only. That's where the disconnect is, in my opinion.
>> What we need is to relate these interfaces to one another.
> I think the problem with user questions is even worse than that.
> Many developers don't actually want to spend much (or any) time
> answering user questions. Partly for bad reasons; but also for the
> very good reason that it doesn't scale.
I was about to follow up to make this point, but Ian beat me to it.
When I had lots of time to spend on Debian, I would occasionally get some
satisfaction out of helping a user debug some sort of general issue with
Debian on their system, or thinking through an odd use case for a package
to find some solution, but that sort of thing usually takes quite a lot of
time and back and forth, and it's often not high-leverage in the sense
that an equal amount of time put into packaging a new upstream release or
fixing a known bug will improve more things for more people. As I've had
to cut back on the number of hours I spend on Debian, I gravitate towards
higher-leverage activities.
At this point, I just don't have time to read and understand most user
questions, let alone help with them, so it's not so much that I prefer
forums that use a different format than users prefer as it is that I
prefer forums that don't have user questions. :|
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Unaddressed use cases for machine-readable debian/copyright files
Guillem Jover writes: > Something that is also a common source of confusion, is that because > it specifies a Files field, it seems it compels people to do very > fine-grained splitting. Personally I have no issue with coalescing > copyright notices, as long as they are all for the same license, etc. > I even coalesce copyright years for the same owner. +1. I would strongly encourage people to do this wherever possible. There doesn't seem to be much purpose served by being more granular, unless it's a side effect of automatically generating the file or something. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Inappropriate content on planet.debian.org and need of evolution of documentation and CoC
shirish शिरीष writes: > Please CC me as I'm not subscribed to the mailing list. Please excuse > the non-brievity of the mail. > Couple of weeks back, I put up a blog post > https://flossexperiences.wordpress.com/2017/03/30/the-tale-of-the-dancing-girl-nsfw/ > Because the subject matter is mature and uncomfortable to many people > my feed was turned off. > In response I was given/shared three documents/links - > https://wiki.debian.org/PlanetDebian > To be more precise it was > https://wiki.debian.org/PlanetDebian?action=diff&rev2=49&rev1=48 Per the follow-up message, I don't have the full context on your post or why your feed was turned off, and therefore don't really want to address that directly. However, the statement: The content should be such that it is suitable for people over 12 years of age. now in the PlanetDebian wiki page added with the above revision is, if true, quite significant. If that is Planet Debian policy, I'll switch my aggregation feed for planet.debian.org over to only posts I explicitly tag with Debian, which will mean removing nearly all of my posts. A lot of people have very different ideas about what is and isn't appropriate for people above 12 years old. I currently aggregate my entire journal there at the specific request of other Planet Debian readers in a previous discussion here after a question about whether people wanted to see my book reviews. But I have no intention to get into the murky territory of whether my book reviews are always appropriate for anyone over the age of 12. I read a wide variety of different things, I review books with significant sexual themes, and I do not promise to never review erotica. I review essentially everything I read, since that's the whole point of my book review site for me, and I'm an adult who reads books aimed at adults that may or may not be appropriate for a 12-year-old. These reviews have always been something I just put on the Internet for anyone to take or leave, no expectations or requirements on my side. I will always make an effort to avoid posting content that is racist, sexist, bigoted, or otherwise easily understandable as attacks on the existence or legitimacy of certain people. But I'm not going to second-guess what I post to it in the area of sexuality; I have strong personal objections to that form of content filtering, and I do not believe discussing sexuality in the sort of objective way that I would in a book review is something that should, or does, fail Debian's code of conduct. If I'm out of step on that and it's not welcome content on Planet Debian, I'm happy to remove it. (I'm also pretty mystified about the application of Debconf's code of conduct to Planet Debian, if that is indeed something being considered. I would treat those very differently; content that's acceptable as words on the Internet may be entirely out of line in an environment where children are physically present, and I would always check the audience and environment before discussing sexuality in person at a conference. On-line communication is far different because there's no way to check the audience; once it's on-line, anyone on the Internet may be reading it.) Anyway, I know that so far this is just one post and I'm missing a ton of context here, and I'm not going to do anything rash or rush to judgement. I just wanted to make sure anyone considering this is aware of the above and the implications of the implied policy change of this edit to the Planet Debian wiki. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Inappropriate content on planet.debian.org and need of evolution of documentation and CoC
shirish शिरीष writes: > Please CC me as I'm not subscribed to the mailing list. Please excuse > the non-brievity of the mail. > Couple of weeks back, I put up a blog post > https://flossexperiences.wordpress.com/2017/03/30/the-tale-of-the-dancing-girl-nsfw/ Okay, I've now thought about this some more and looked over that post in some detail, so a few more comments, separate from my serious concerns about the (I suspect unintended) implications of the Planet Debian content policy change. (Cultural note: Those of us in the US get pretty paranoid about content rules that involve what parents think is or isn't appropriate for twelve-year-old kids, since there are large and well-organized parent groups in the US that think upwards of 90% of world literature should be absolutely off-limits to twelve-year-old kids.) Shirish, if you felt like you should put a NSFW tag on a post, please don't post it to Planet Debian. I think "safe for work" is an entirely reasonable (and reasonably expected) content policy, if for no other reason than we, as a project, want people to be able to read Planet Debian at work. If it helps, think of it this way: it's not about offense to other project members directly. It's about getting fellow project members *in trouble*. A lot of employers have absolutely zero sense of humor about this sort of thing. I think "safe for work" is a much easier-to-apply and less-fraught policy than "safe for anyone over the age of 12." In particular, "safe for work" emphasizes the problems with open offices, easily-seen screens, and people reading over your shoulder, and therefore correctly emphasizes the problems with *visual* content. The *textual* content of your post is not necessarily a problem (more on that in a minute); the photo of a lap dance, while not particularly explicit if one doesn't have the context, still is. That's going to be a problem in a lot of office environments. I think it's still kind of borderline since everyone in the image is basically clothed, but it's the sort of border that doesn't really need to be approached. Images from Wikipedia are *not* necessarily safe for work. There are absolutely Wikipedia articles that I would not browse through at work, and I work in California tech, which is *extremely* relaxed about this sort of thing compared to a lot of other industries. If you want to post such things anyway, you can also make things safe for work by clearly disclaiming them *and then making sure the content isn't shown without explicit action*. For instance, I think it would have been entirely fine by that standard for you to syndicate a *link* to your blog post on Planet Debian. But that aggregator expands posts fully in-line on the site, including all images, so any images you put in a post are "above the fold," and need to pass that safe for work bar. Separately, on the textual content... I'm not sure exactly the right way to phrase this advice, but I do think you use your blog to explore intensely personal philosophical questions. I understand that you really want to explore those with other people in the project as well, but I can also see how it can be a little out of step with what others post there. I'm not really certain how much of a problem it is, but the piece of the Planet Debian policy that I would have pointed you at isn't the family-friendly bit, but the "excessively personal information" bit. Everyone posts some of that from time to time, and some of it isn't a big deal. I've certainly posted some of it, and no one really minds. But I think the key bit is *occasionally*. As part of a mix of a variety of other content, I don't think anyone is going to object, but if your blog is *mostly* extended philosophical musings, particularly long ones (because again Planet Debian expands everything in-line), I'm not horribly surprised that a few people might start complaining. Whether those complaints should warrant a change is kind of a hard question, and I'm not quite sure what to feel (I really value the diversity of human experience in the project), but you might want to consider whether there are some merits to dialing it back a bit, at least in the content you syndicate to Planet Debian. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: having public irc logs?
Gianfranco Costamagna writes: > the main sadness comes to a lot of friends, sharing on "private/semi > public places" a lots of private pictures, without understanding the > damage that they might receive in case of leaks. > saying "I told you" doesn't help fixing the problem, after a leak has > been done there is nothing left to do to repair it. > being aware of that is the most important thing, and there is nothing to > leak when something is public :) This is indeed a real problem, but the solution to this problem is not to further erode what remaining privacy we have. It's to find ways to rebuild privacy using technical and social means, because privacy is a necessary human right, while continuing to give people pragmatic and cautionary information about the frequent violations of that right. I'm frustrated by how we occasionally seem willing to give up on privacy just because it's hard and is currently under attack. We don't do that with other human rights, and we shouldn't do that with this one. For example, it's equally true that criminal justice is hard, and often people only get the justice that they can pay for, but we don't then conclude that we should teach people to assume the police are useless and should never be contacted, that crimes should not be reported because it's pointless, and we should instead take private revenge against criminals. Instead, we try to mix pragmatic cautions with an attempt to fix the system and blunt its worst abuses, with an understanding that we *need* a functional criminal justice system to be a civilized society. This means we live in a world of complicated tradeoffs and cautious, fraught decisions rather than in a world of clear black-and-white options. But, well, that's reality. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian contributor Register of Interests
"Dr. Bas Wijnen" writes: > On Tue, May 09, 2017 at 11:51:23PM +, Scott Kitterman wrote: >> I think it's a horrible idea. One of the major draws of Debian is that >> we are all here for our own reasons. I don't judge your motivations >> and you don't judge nine. > It's voluntary, so you decide what you want to share. If you don't want to > share anything, that's fine. How is this meaningful if it's strictly voluntary and no conclusions should ever be drawn from it? I'm personally reasonably comfortable with declaring conflicts, but then mine are pretty simple and pose no complex ethical concerns. I understand Scott's concern: I see no way in which this would stay strictly voluntary and meaningless if it were widely used. One can say anything one likes on the page about not drawing conclusions from the data, but if no one is supposed to draw any conclusions, why are we collecting the data? In practice, if lots of people fill this out, people *will* draw conclusions about people who are missing, will exert social pressure for people to fill this out in various situations, and will draw conclusions from the data that's disclosed. This is just human nature, and is only logical. If we don't want that to happen, we shouldn't collect the data in the first place. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian contributor Register of Interests
Nikolaus Rath writes: > On May 10 2017, Russ Allbery wrote: >> and no conclusions should ever be drawn from it? > I don't think anyone has said that. Quoting from the originally proposed wiki page: | The following people have added themselves to this list. No-one should | assume that the presence or absence of a person from this list implies | any conflict of interest or misconduct within Debian. I'm agnostic on the merits of collecting this data -- I can see both sides. But I think the above paragraph is unrealistic, and if we want that paragraph to be true, we should not gather the data in the first place. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: should debian comment about the recent 'ransomware' malware.
shirish शिरीष writes: > while it was primarily targeted towards Windows machines, maybe we > could tailor a response which shows how Debian is more secure and > possibilities of such infections are low/non-existent . I don't believe such a statement would be factually correct, so no, we shouldn't make it. This ransomware used a government-developed exploit that was patched by Microsoft a month before the malware was released (only because someone did the right thing and gave them a private heads-up), and gets a toehold via phishing. There is absolutely nothing about Debian that would prevent exactly the same thing from happening to us; the reason why it doesn't is quite simply because Debian is much less widely used than Windows, and in particular has less penetration into markets that run obsolete operating systems on "cannot patch" systems using older and very insecure protocols. Which is extremely common in the health care industry. This is not a case where Microsoft did something clearly wrong, or even differently than we would have done, or where free software would have helped significantly. (Maybe if the whole SMB stack were free software this bug would have been discovered sooner, but quite possibly not; the free software world certainly has many security bugs that have gone undiscovered for ten years or more.) I'm extremely proud of Debian's security team, and we're often quickest to patch among major Linux distributions. Our security team does amazing work. But nothing a distribution or OS vendor can do can help with unpatched systems, or against government-funded adversaries that hoard unreleased zero-day vulnerabilities and exploit tools. Those are very hard problems, and we should not mistake our lack of *incidents* from having a smaller and differently-focused user base for a lack of *vulnerability*. The entire computer industry is vulnerable to attacks like this, and Debian is absolutely not an exception. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: should debian comment about the recent 'ransomware' malware.
Ian Jackson writes: > If these systems were running Debian, big organisations like the British > government could hire people to provide security support for their > users, even for versions which we no longer support. When the obsolete > operating system is Windows, they can only hire Microsoft, who can set > the price at whatever they think the market will bear. > As it happens this particular vulnerability was indeed fixed by > Microsoft, and that the UK NHS suffered so much is because of government > and management failures[1]. But in general, users who for any reason > are stuck on very old systems are in a much better position if those > systems are free software. That's a very good point that I neglected. Thank you for adding that! > Also, Debian's engineering approaches mean it's easier to support > obsolete environments, eg via chroots and/or mixed systems and/or > selective backporting. Also a good point. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bug#856139: certspotter: long description advertises commercial service
Vincent Bernat writes: > As a sidenote, I strongly think I should just shut up. This kind of > discussions always lead nowhere and people just forget them. But... Yeah, I've been feeling the same way. But one message in support of this point, just to try to balance the expressed opinions a bit. > Let's take rclone. > Description: rsync for commercial cloud storage > Rclone is a program to sync files and directories between the local > file system and a variety of commercial cloud storage providers: > . > - Google Drive > - Amazon S3 > - Openstack Swift / Rackspace cloud files / Memset Memstore > - Dropbox > - Google Cloud Storage > - Amazon Drive > - Microsoft One Drive > - Hubic > - Backblaze B2 > - Yandex Disk > It says "commercial". Lot of commercial services. But, it would work > with free S3 implementations and it works with Openstack Swift which is > free. So, not in contrib, right? > Now, it is written in Go and it depends on a lot of libraries, notably those: > - golang-github-aws-aws-sdk-go > - golang-github-stacktic-dropbox > - golang-google-api > - golang-google-cloud > They should be in contrib. But then, rclone would be in contrib > (packages in main cannot depend on packages in contrib). So, our users > would just lose a software which can be used to migrate data from a > commercial service to a free service. Indeed. I think it's a bad idea to push this sort of tool off into contrib. I don't think making it harder to use free software with non-free services is going to achieve our goals as a project; to the contrary, I think making it easier to get data out of non-free services using free software can only benefit free software, given the current balance of power in the ecosystem. If free software cloud services were overwhelmingly common and non-free cloud services were an intruder in this space, the calculus might be different, and it might be tactically better to freeze out the non-free services and make it more difficult to work with them. But that's not the shape of ecosystem that we're dealing with right now. (Conflict of interest disclosure: I currently work for Dropbox, although not on the product side. I think the above opinion is the same I'd hold if I didn't work for Dropbox, and held before I took that job, but anyone reading this thread should judge that for themselves.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Are online services also software for Debian's rules?
Vincent Bernat writes: > Then, please file bugs against offending packages, severity > serious. Otherwise, all this discussion is useless. A starting point > could be golang-github-datadog-datadog-go and golang-google-api > packages. And please think about the significant hardship you will create for people trying to maintain software in Debian that works with multiple free and non-free services before you go down this path. The number of things that would have to move to contrib because one of their underlying libraries would now be in contrib would be substantial. Is the amount of effort people would have to go to in order to untangle that mess, and the number of our users who would immediately enable contrib who don't have it enabled now, really worth it? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Are online services also software for Debian's rules?
"Dr. Bas Wijnen" writes: > Also, I don't want to move lots of software to contrib. I would much > rather have it fixed by removing the support for the non-free services, > or by having plugin systems that allow only the non-free-interfacing > part to be in contrib. I believe this would be hugely counter-productive for free software. It would hurt us way more than it would hurt proprietary services. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Are online services also software for Debian's rules?
Miles Fidelman writes: > Getting past all the obfuscatory count and counterpoint, there seem to > be two clear questions on the table: > 1. Given a piece of FOSS client software, that has no purpose other > than to interface with a proprietary back-end service (say a FOSS > twitter GUI), should that be considered "free software" for the purposes > of placement in main vs. contrib vs. non-free? (Or alternatively, where > should it reside?) > 2. Given a piece of FOSS client software that interfaces to, among > other things, a proprietary back-end service (e.g., a multi-protocol > chat interface that includes AIM and MS Messenger among the back-ends it > supports), be placed in contrib or non-free, simply because its > description mentions those services? The point that I think may not yet be clear enough is that if the answer to 2 is that such software should not be moved to contrib (as has historically always been the case), the answer to 1 *also* has to be that the software is not moved to contrib. Because the way you get software of type 2 is that it uses a variety of libraries of type 1, so if those libraries are moved to contrib, the main software of type 2 would also have to be moved to contrib. Writing a library specifically to interact with a non-free service is *good software engineering* (do one thing and do it well), and the correct way to implement software of type 2. So unless you want to see all software of type 2 kicked out of Debian, at least libraries of type 1 also need to be allowed in Debian. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Judging consensus at in-person meetings
t should be written, that's a lot more valuable to the project than just objecting. Sometimes this is called "bias for action": most decisions are reversible, and most changes can be more easily refined once there's a foundation in place for further refinement. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
Martin Steigerwald writes: > I always found that just focusing on the technical aspects of the Init > system discussion left out… everything else. Even the issue in itself > was not purely technical, although back then I had the a feeling that > almost no one agreed with me that it was not. Just focusing on purely > technical means in that discussion was in my eyes harmful in itself. Well, I agreed, and agree, with you that the issue was not purely technical, and spent a substantial amount of time, effort, and writeup energy on discussing the non-technical issues. Your description bears very little resemblence to the process I was part of. I think it's really important to not oversimplify past discussions. We're in danger of learning the wrong lessons from them. One of the reasons why the systemd discussion was so painful was precisely that it could *not* be discussed at a level of purely technical details, and we all knew it. Technical details are much easier to reach decisions of fact on; the systemd discussion was painful precisely because it *wasn't* and *couldn't* be conducted in the way that you describe. It touched on everything from competing visions of the nature of free software in the project, the meaning of our social contract and "universal" in the motto of our distribution, the attitudes and behavior of multiple different upstreams, accusations of corporate conflict of interest, and deep personal friendships. There wasn't *anything* "left out" of that discussion. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
Gunnar Wolf writes: > It's easy to reach a technically sound decision, but it's hard to uphold > it without someone somehow getting sore about it. I don't know how > inevitable this is, but I recognize it happens in many different > areas. And a few sore people "hurt" more than a silently sympathetic big > crowd. I think there are several principles that I suspect most people bring to TC decisions. Certainly, I did. I think it may be helpful to look at them and realize that they're *inherently* in conflict. In other words, it's clearly possible to find cases (and we have found cases) where it is literally impossible to satisfy all those principles at the same time. Off the top of my head: 1. Make timely decisions so that tense situations that are causing social and technical friction are resolved as quickly as possible. 2. Ensure that every party in the conflict is completely heard and understood before making a decision. 3. Avoid forcing people who are already burned out on a problem to do *significant* emotional and mental work to write up their positions, arguments, rebuttals, and defenses. I cannot overstress just how much energy and time this requires to do properly, particularly for volunteers. Being a party to a TC bug can easily start to feel like you need to take time off work to respond properly. 4. Make a decision in a way that doesn't drive any party away from Debian (on either side of the conflict). 5. Make the decision that leads to the most technically correct distribution and the best and most usable result for our users. 6. Avoid letting someone's heartfelt unhappiness not force an incorrect decision when they are (however sincerely) in the wrong (either socially or technically or both). 7. Be transparent to the rest of the project and available and responsive for questions from other project members who have concerns about the process or outcome. 8. Make a decision that upholds the aspirational, ideological, and ethical standards of the project. If one thinks through all the ways in which these principles can come into direct and painful conflict, I think it becomes clearer just why this can be so hard. I think it's also worth remembering that *every* community finds this hard. I think it's safe to say that every legal system, appellate process, or conflict resolution mechanism known to humans fails at one or more of those principles much of the time. We should always try to do better. We should avoid expecting ourselves to be superhuman. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
Martin Steigerwald writes: > Russ Allbery - 28.10.17, 16:13: >> There wasn't *anything* "left out" of that discussion. > In my opinion this is a pretty bold statement. > If everyone has been heard, noticed, felt and valued, if everything has > been covered, then why are we discussing it… yet again now? Those are not equivalent statements. In that sort of discussion, it is literally impossible to make everyone feel valued, since at least some people on each side will only feel valued if their preferred option is chosen. That's therefore not a reasonable thing to attempt to achieve; we can try to maximize the number of people who feel valued, but there are usually at least some people involved in this large and sprawling of a decision for whom "valued" is synonymous with "agreed with." There are two primary reasons why we're continuing to discuss this. One is that the decision went a direction that a lot of people didn't, and don't, like, and they're still unhappy about it. There's really nothing that can be done about this; any other decision would have had exactly the same consequence, just with a different set of people. The second is that there is a very strong tendency for humans to confuse "you have heard and fully understand everything I said and simply don't agree with me" with "you haven't heard me." I think everyone does this to some extent. We're all firmly convinced that our arguments are the best (since if they weren't, we'd hold a different opinion), and therefore if someone doesn't agree with us, it must be because they just haven't *really* heard and understood our arguments. It's very, *very* hard to not believe this. And a *ton* of that happened, and continues to happen, with systemd. But... it's just not true. I'm quite confident that everyone on the TC who made the systemd discussion fully understood the arguments for the opposing side. We simply didn't agree. And we have to find some way, as project members and as human beings, to accept that and live with it. Part of living with it is not trying to come up with *yet another* phrasing of the argument that, this time, the other side will *finally* understand. This phenomenon is not at all unique to Debian. It happens in all political discussions. > I certainly think that the CTTE process can be improved upon. Is it bad? > I do not know and does it really matter to decide? I am sure everyone > involved is doing their best. We always do. > Can it be improved upon? Yes, is my answer. I'm certainly happy to agree with this! There's hardly any human process that can't be improved upon. My key point here is that if you think there was some other way that the systemd discussion could have been held, some additional work that could have been done, such that everyone would have been happy with the outcome... well, sadly, I just don't think that was on the table. There are certainly things we could have done better, mechanically, culturally, interpersonally. But there was no *argument* left out of that discussion that would have convinced people, and there was zero chance that we weren't going to come out of that decision with some very upset and angry project members. > Does the everyone involved with CTTE process drive conflict resolution > processes to their completion? I don't think the type of conclusion that you're talking about here (I sense that you're talking about something other than a mechanical conclusion of a defined process) is something that exists with truly hard decisions. This feels like an argument for always making decisions by consensus, and the sad fact of the matter is that some decisions cannot be made by consensus because there is no consensus and *will never be a consensus*. In those situations, in practice, this line of argument is an argument for not making a decision, by perpetually postponing the decision because the conflict resolution hasn't completed, because some people are still unhappy. And not making a decision is itself a decision, often a rather bad one. The other point I want to make here is that the systemd discussion was one of the most exhausting and time-consuming things that I've ever been involved in. I'm sure some people in that discussion didn't feel listened to for various reasons, and maybe in a few cases that was because they truly weren't listened to. (Perhaps because they were making other versions of the same arguments other people were making.) But at least speaking for myself, there was not the *capacity*, emotional or temporal, to engage in more detailed personal discussions with yet more people to make sure they felt fully heard. This is some of the "being human" part that I was talking about in my oth
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
Marty writes: > I agree technically but I wonder whether strategic, ethical or social > contract issues were given sufficient weight, or if the constitution > even allows for such considerations. I don't know but this obviously > would include some regard for the wider community, including users. [...] Hi Marty, I probably shouldn't reply to more systemd discussion, but I do think this has some relevance to the question of how to handle TC decisions more generally, so I'm going to dive into this anyway. I believe this is an example of the pattern that I identified in a previous message. What I'm seeing in your message makes me believe that you are so firmly convinced that systemd is evil, its developers are evil, and it is a negative effect on free software that you are unable to comprehend how someone could disagree with you. The only possibility is that they must have somehow been prevented from taking those issues into account, either by not giving them sufficient weight or because of some provision of our governance structure, or because they were caught "off guard," or because they're part of the corrupt conspiracy. I was one of the Technical Committee members who was involved in this decision. I have, and had, absolutely no affiliation with Red Hat whatsoever (or Ubuntu, for that matter). I took strategic, ethical, and social contract issues fully into account in making my decision. They pointed me towards systemd. Other colleagues drew different conclusions. We're independent human beings who arrive at different conclusions given the same evidence. This is reality. Your model of governance and ethics has to account for this, or it's useless. I have heard all the arguments against systemd. I understand them fully. I was not caught off-guard. I thought about them for months. I believe those arguments range between valid but insufficient given the weight of evidence in the other direction to outright incorrect. I believe the overall characterization of the systemd project and its effect on Debian is factually inaccurate. You are fully entitled to continue to disagree with me. *But I am also fully entitled to continue to disagree with you without being a plant or a conspirator or a liar or a dupe.* If your world view claims that people like me *do not exist*, your world view is, well, wrong. And when you continue to make arguments on the basis that it is somehow impossible to hold the view that I, in fact, hold, you are in effect accusing me of being unethical. Of lying. *This* is where I see the true source of the *ongoing* division in the community. It's not over the technical decision. It's not even over the decision-making process. It's that some people, most (but not all) of whom seem to be opponents of systemd, are so completely confident that they're right and that theirs is the only ethical position possible that they repeatedly accuse anyone who disagrees with them of bad faith. This is horrifically destructive, and extremely demoralizing, and if anything is going to seriously hurt the Debian project as an ongoing collective project, it's this attitude. Reasonable people disgree. We want to continue to work together anyway. We can find ways through a lot of different problems and challenges and disagreements as long as we can unite around that principle. If we can't unite around that principle, almost any disagreement has then potential to tear us apart. The term for this in the broader world is "assume positive intent," and it's one of the most important characteristics for any successful large-scale collaboration. The broader implication of this for the TC is that the TC deals with the most divisive issues, where people have started lining up on sides and the tendency to assume bad faith from the other side has become very strong. Thankfully, very few are as bad as systemd, but some will be quite heated. The TC is in the difficult position of trying to unwind some of that type of conflict as well as making a decision that often won't make everyone happy. It's extremely hard. But one thing that the *rest* of us can do outside of the TC is to hang on very tightly to that principle of assuming positive intent. We're all on the same side. We're all trying to make Debian better. We just disagree how to get there. We've all made a lot of judgement calls in the past, and we've all been right sometimes, and we've all been *wrong* sometimes. We can argue our sides, but at some point we just have to trust our fellow project members and try to make the decision work. That's what makes Debian a collective, collaborative project rather than just a technical assembly of packages. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Do we need embargoes for GPL compliance issues?
Florian Weimer writes: > Do you think Debian should welcome embargoes for GPL compliance issues? > Security embargoes are a huge pain, but one would hope that GPL > violations by Linux distributions are much rarer events. I'm sorry, I think I'm missing some basic context required to make sense of this question (and therefore I suspect other people on this list are as well). What exactly would we be embargoing, and why? For security embargoes, what we're embargoing is the description of the vulnerability, and we're doing that to keep attackers from having an opportunity to write exploits before a patch is released (putting aside the question of whether this works). I'm having a lot of difficulty mapping those concepts onto license violations, so I don't understand what you're proposing. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Do we need embargoes for GPL compliance issues?
Paul Wise writes: > It seems to me that Florian is talking about the rare GPL violations > that Debian (and other distros) commit and keeping those secret until > they can be rectified. These happen (and are sometimes caused by > upstreams like the GNU project). ISTR in the past we have just rectified > the issues and ignored the fact that we lost our rights under GPLv2. How does keeping them secret affect whether or not we lose our rights? Oh, I think I see: it's about this section of the GPLv3? Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice. So the idea is that if we self-discover, or are told by someone who is not the copyright holder, and publish that fact immediately, the copyright holder could then give us and our derivatives and any other distributor with the same problem immediate formal notice and we'd only have 30 days to remedy, but if we keep it secret, we can take more than 30 days to remedy as long as the copyright holder doesn't separately notice? That seems a little tortured to me, but I can sort of see it if I squint hard enough. How much of a problem is this? Has Debian ever received a formal notice from a copyright holder under that clause? Does anyone really do this? I may just be hopelessly naive or out of touch, but I feel like the termination of rights clauses under the GPLv2 and GPLv3 are widely ignored for good-faith violations (such as those Debian would make) and basically never enforced that way. Hell, they're barely ever enforced against blatant violations by large commercial companies like VMware. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Do we need embargoes for GPL compliance issues?
Paul Wise writes: > On Thu, Sep 13, 2018 at 12:36 PM, Russ Allbery wrote: >> I may just be hopelessly naive or out of touch, but I feel like the >> termination of rights clauses under the GPLv2 and GPLv3 are widely >> ignored for good-faith violations (such as those Debian would make) and >> basically never enforced that way. Hell, they're barely ever enforced >> against blatant violations by large commercial companies like VMware. > Agreed re good-faith violations by FLOSS community projects. That said > there are also a lot of potential long-term violations in projects > surrounding the FLOSS community, for eg check the Debian derivatives > census for the phrase "no source packages". Would an embargo help for that kind of thing, though? If a Linux distribution isn't publishing source at all, they're seem to be into far more dangerous waters than an embargo could possibly help with. I guess what I'm looking for is a concrete example of something that happened to a Linux distribution for which an embargo would have been helpful and productive. Without such an example, I think we should default to being opposed to participating in embargoes per point three of the social contract. I don't think the social contract means we should *never* participate in embargoes. For security, for example, the priorities of our users conflict to some extent with not hiding problems, and we have the current compromise. But there has to be some reason to compromise that furthers some other point of the social contract; otherwise, we should default to openness. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Do we need embargoes for GPL compliance issues?
Florian Weimer writes: > * Russ Allbery: >> Florian Weimer writes: >>> Do you think Debian should welcome embargoes for GPL compliance >>> issues? Security embargoes are a huge pain, but one would hope that >>> GPL violations by Linux distributions are much rarer events. >> I'm sorry, I think I'm missing some basic context required to make >> sense of this question (and therefore I suspect other people on this >> list are as well). >> What exactly would we be embargoing, and why? > See bug #907585 for an example. It occurred to me only afterwards > that reporting it publicly (upstream) might be a bit inconvenient for > some people (although no one has complained to me directly). Hm. I guess I'm not seeing any harm there. The problem only happens if a copyright holder sees such a notification and then files a formal notice of copyright violation, right? One unfortunate part about the way the GPLv3 license is phrased is that if the same copyright holder reports multiple instances like this, the thirty-day thing only applies to the first one, and then one technically immediately loses the license to distribute (at least if I'm understanding the license correctly). So, for packages like the Linux kernel where these license violations are fixed when we notice them but which have an ongoing likelihood of seeing new violations, we can get into some bad and I think unintended consequences. That means embargo isn't really useful anyway in cases where we expect to see ongoing unintentional license violations that have to be cleaned up. That said, the Linux kernel is of course under GPLv2, which doesn't have that 30-day provision at all, so it doesn't seem like an embargo would have helped at all in this specific case (which I think you mentioned in your original message). If we get into informal conventions among copyright holders about what they'll pursue and what they won't pursue, (a) I have a hard time imagining any such convention that would pursue a copyright complaint against what Debian does, and (b) those conventions are strictly voluntary and there's no reason to believe that all Linux copyright holders will follow them anyway. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Daniel Pocock writes: > I was recently at the UN forum on business and human rights, listening > to an Iranian dissident talk[1] about the extremes that his country goes > to in censoring and silencing people who don't agree with their rulers. > I would encourage people to watch the video. > At that very same moment, the anti-harassment team were censoring[2] a > Debian Developer's blog from Planet Debian. Chilling. > I actually looked at Planet shortly after attending that panel > discussion and immediately noticed that Norbert Preining[3] had been > censored. Disappearances of Khashoggi[4] and Kamphuis[5] came to mind. Entirely apart from the merits of the rest of your discussion of whether the project should republish this blog using project resources, this framing is appalling and blatantly dishonest. It intentionally conflates issues of government censorship and journalistic freedom that have cost people their lives with a dispute over whether Debian should *republish* content that has not been censored, restricted, or removed in any way, let alone been subject to threats of physical violence. I object in the strongest possible terms to this framing of your argument. You should be profoundly ashamed for choosing this path of malicious exaggeration phrased as an attack on the work of fellow developers. It was completely unbecoming of a Debian project member. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Daniel Pocock writes: > and I reply with the strongest possible evidence, personal experience > and scientific research. You decided to distort a political issue that many of us feel strongly about to attack a policy around what to republish in project-owned forums, which is only on a continuum with that issue if you look for it with a telescope. You did this in a way designed to provoke strong feelings and create moral absolutes rather than start a conversation, and you did this knowing full well that you were attacking a specific team inside Debian composed, like all Debian teams, of overworked volunteer members. You did this without the slightest attempt to extend an assumption of good will or allow for the possibility there are further things going on that you don't know about, and you did so with such pathetically sloppy and incomplete research that even *I* know you are leaving out substantial background, and I haven't been trying to follow this saga. In other words, you immediately turned the temperature up as high as you could go and called on other people to attack your fellow Debian developers on the grounds that their work is a violation of UN-recognized human rights (!!). That you cannot understand how completely absurd this is means that it is futile to try to argue this point with you on the merits. There *is* an underlying project debate here that is a real debate, namely the rules for participation and republication in project forums. I think it's a debate we've had to the point of absurdity, but I'm not horribly surprised that people want to still have it, and if that had been all your message had been, I would have sit on my hands and not added to the noise. But you saw an opportunity to artificially strengthen your debate stance by comparing the Debian anti-harassment team to assassins (!!) and you seem completely oblivious to why this is utterly unacceptable in collective discussion within a project of colleagues, peers, and friends. I have no idea personally what set off Norbert's removal from Planet Debian. When I said irrespective of the merits of your argument, I really meant that. But *this* bothers me far more: this kind of brutal approach to Debian politics is hostile, nasty, and deeply hurtful to the project. If you want to have a debate about the decision of a team in Debian, you have an obligation to the project to conduct that debate with a certain basic level of mutual respect. Asking you to not compare your fellow project members to assassins does not seem like a high bar! If you aren't going to do that, I for one am quite happy to make this argument about *your* behavior, which was appalling and utterly toxic to supporting the community of a volunteer collective project. > Having been rear ended by a utility van, thrown off a motorbike half way > across a roundabout and having also received abusive and threatening > messages from people within the Debian community, I feel that the > physical pain caused by the latter was more than the former. Those > people should be ashamed of themselves. Yeah, no shit. Your lack of awareness that *you* are that person who should be ashamed of yourself because that's what *you* just did is honestly mind-blowing. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Scott Kitterman writes: > If censorship isn't the right word (and at best, it's not ideal), what's > the right word for the chilling effect on willingness to speak in public > due to the risk of being ejected from an organization like Debian? Being an adult. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Roberto C. Sánchez writes: > On Fri, Jan 04, 2019 at 10:17:56AM -0800, Russ Allbery wrote: >> Scott Kitterman writes: >>> If censorship isn't the right word (and at best, it's not ideal), what's >>> the right word for the chilling effect on willingness to speak in public >>> due to the risk of being ejected from an organization like Debian? >> Being an adult. > That was uncalled for and inconsistent with the high bar you have set > for yourself in so many other discussions. How was it uncalled for? It says exactly what I meant. I'm not saying anything at all about Scott's behavior; it's the very simple answer to his question. I apologize for apparently giving you the impression that it was an attack on Scott. I probably should have unpacked it a lot more. But having to mediate your behavior to follow standards that you may not agree with or face consequences around what organizations will have you as a member is *exactly* being an adult. This is how the world works. You have to watch what you say at work, or you might be fired. You have to be careful of what you say among groups, or that group may eject you. You have to follow the standards of an organization of which you're a member, or that organization will expel you. This is just ordinary, perfectly normal adult behavior. Everyone watches their behavior and their wording all the time. The idea that there is any forum in which people interact as adults where there is no chilling effect on one's unfettered speech and where no one has to watch their language, tone, or presentation is pure fantasy nonsense. Even 4chan has social norms and consequences for going against them. People seem to feel they're unreasonably put-upon by having to think about what they're saying *at all*, but this is absurd. Everyone else in the world is doing this all the time. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Scott Kitterman writes: > Nonsense unless you define being an adult as completely and fully > understanding exactly what the hundreds of people around the world think > is reasonable. Anyone who has held down a job in a typical workplace has already shown that they can understand what's reasonable and adjust to a social environment well enough to do just fine in Debian. (And yes, I realize that's *also* a challenging environment for some folks, and in a lot of cases we can be *more* welcoming than that, but I think it's being aware of that baseline.) > I suspect we agree on more than we disagree in this area, but I don't > think "My way or the highway" is the right answer beyond a certain point > in a worldwide project like this. It's certainly not "my" way -- it's some sort of consensus emergent standards among all of us, which changes in the complicated and intricate ways of all human communities. But every community has standards of behavior and social consequences, whether formal or informal, for violating them. There exists no place on earth in which you can say literally whatever you want with zero consequences, because humans are a social species and we interact with each other and those communities involve making judgments about who we include and don't. > Please accept that I am concerned that reasonable people who, none the > less, do not fully accept a certain political orthodoxy are uncertain > about where the lines are and find that chilling their willingness to > participate in Debian beyond narrow strictly technical discussions. Yup, sometimes it's uncertain and uncomfortable. That's because navigating social situations can be work. It can require effort. And yes, we all make mistakes (for instance, I just made one in going for pithy over fully explained, and made it seem like I was attacking you, for which I sincerely apologize). And it's a process; you step on someone's foot or put your foot in your mouth, and then you adjust, and pick yourself up and dust yourself off and try again. The part that I'm a little frustrated by is that I feel like you think people of a particular political belief are doing *more* work than others, and wow, that is not my experience at all. The people who complain the most about "chilling effects" are, in my experience, the people who are doing the *least* amount of work in most conversations. And that may still be a lot of work! That may still be really hard for them! I'm not saying this to say that they're doing very little work in some objective sense. What I am saying is that they seem oblivious to the fact that the people on the other side of the discussion are *also* doing a *considerable* amount of work on how they communicate, and when, and what wording they use, and have been all along. They're just not complaining about it, because they realize this is just the normal price of human social community. > I find this notion that if anyone has any concern or confusion about if > their opinions are OK to express it's only because they are wrong very > troubling. That's not what I'm saying at all, and I'm sorry that it came across that way. Having concern and confusion about whether your opinions are okay to express is *also* part of being an adult. This is a universal experience. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Scott Kitterman writes: > For clarification from me, I don't expect a consequence free > free-for-all where anything at all can be said with no repercussions. > There are absolutely things that are not acceptable, but on the other > hand, I also don't think "someone was offended" is a reasonable standard > (and I am not claiming that's what Debian is currently using - but there > are places where things seem to me to be headed in that direction). I think it's useful to think of offending someone as being like stepping on someone's foot. Most of the time, it probably means you should apologize. Apologizing doesn't mean that there was necessarily anything you could have done differently. Perhaps you stumbled into someone's foot through no fault of your own, but it's still normal to apologize. Apologizing doesn't mean rending your garments and doing five years of penance; it just means saying "whoops, I'm sorry!" There are occasional instances where someone intentionally sticks their foot in your way. But this is relatively rare, and the first time you step on someone's foot, it usually doesn't make sense to assume this happened. If the same person's foot constantly ends up under your feet, but you don't seem to be stepping on anyone else's foot, it may be time to start reconsidering whether you should keep apologizing or if something else is going on. If you keep stumbling over a variety of people's feet with some regularity, it's probably time to figure out why this is happening and what you need to do to stop stepping on people's feet, which might involve some real work, unfortunately. But most of the time, if you step on someone's foot, you can just apologize and move on and everything is fine. It happens to all of us. It doesn't have to be a big deal. (But refusing to apologize does very quickly make it a big deal.) And sometimes people stick their feet in the most irritating places, and it can be a bit of a chore to step over their feet, and it can be seriously tempting to tromp down on that foot that someone is sticking out *right in the middle of the aisle*. And, just like we do in everyday life, it's almost never a good idea to do that, as opposed to just grumbling to yourself about it and maybe complaining to some friends about that rude person who had their foot stuck out in the aisle. Usually when I do give into temptation and stomp down on that rudely-placed foot, it turns out that person had just broken their foot and was on the way to the doctor's to get a cast put on it, and then I feel awful. > I am concerned about Debian becoming over-politicized (beyond the core > issue of Free Software, which has an inherent political aspect). I like > that the diversity statement isn't anti-anything. Well, I'm in the camp that says that Debian is a political project at its very core, and there's very little about Debian that has ever been *not* political. But I realize this is an ongoing argument over what "political" means. (I think a lot of people have an unreasonably narrow definition.) > My personal challenges with engaging constructively don't derive from > any particular political perspective. They come more from having a > strong temper over which my grasp is unfortunately not always adequate > and being old enough that I worry about language shifting under me in > ways I can't anticipate. A sincere apology goes a very long way. No one wants to make life unreasonably harder for other people. What gets people upset is not that people make mistakes, or even that some people make mistakes more than other people. This is normal, ordinary human community stuff. What gets people upset is when people don't make any apparent attempt to not make mistakes, or (particularly) when they vigorously defend their right to tromp on someone else's foot because the foot shouldn't have been there in the first place. Then everything gets heated. As long as you're trying, even when it's hard, I think nearly everyone is going to assume good faith. The hard feelings come when someone declares that they should not have to try, and that being told to try to not step on people's feet is an offense against their human rights. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
x27;t have the energy, I don't have to do the work, but maybe I should also consider staying a bit more quiet. I don't have to; I can just speak my mind anyway, but when I do, there's a higher than normal chance I might need to apologize afterwards. And that's okay! It's okay to decide you're not going to try to be diplomatic and are going to risk it, and sometimes that's okay, and sometimes you're going to have to say later "whoops, that wasn't wise, I'm sorry." As long as the apology is there, and is sincere, I think it will all work out in the end. There's a lot of good will in this project; people are not particularly eager to believe the worst of other people. But if one starts taking the position of never apologizing for anything because demanding apologies is unfair and it's not their responsibility to assuage easily-offended people whooboy. That's not going to go anywhere good. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Jonathan Carter writes: > On 2019/01/04 15:44, Scott Kitterman wrote: >> Note that I'm not talking about refusing to republish (I know what that >> is). I'm talking about declining to speak based on concern about >> disproportionate reaction from our leadership/delegates for doing so >> (I'm also not arguing that did or didn't happen in any recent situation >> - I am trying to see if there is some consensus to be found on at least >> how to talk about it). > Since there were so many replies to your email without actually > answering your question, I decided to indulge. > I think what you're referring to above is self-censorship, I think this > wikipedia page resonates with what you're trying to get across: > https://en.wikipedia.org/wiki/Self-censorship Thank you, Jonathan. That was a much better response than my too-flippant one. Also, I never said this in my replies, but thank you, Scott, for looking for a less charged word than censorship to talk about this. I think that makes the conversation better. And indeed it's possible for communities to go too far and create self-censorship that is harmful and gets in the way of talking about important issues, so it's useful to have a term for this so that we can talk about whether Debian is close to that line or not. It was a good question and deserved a real answer. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Eldon Koyle writes: > In regards to the use of the word 'censorship', looking at the > definition[1][2][3] of the word seems to support its use in regards to > a-h removing feeds from planet for being objectionable (and does not > imply any infringement on rights). Whether that form of censorship is > good or bad or rights-infringing is a separate argument. Language is messy and inconsistent and infinitely variable, and meanings shift and people use words because they're stronger or softer or for various other reasons. It can make it hard to communicate. But I don't think the definitions of words are the heart of this discussion, so trying to hammer out what definitions to use may not get us any closer to really having the root conversation. (The words below are random meadow plants and aren't intended to have any connotations.) One action: people preventing you from speaking or publishing an opinion via force, either by killing you or by taking away your possessions or by confining you, or by credibly threatening those things. We'll call that action Clover. Another action: people treating you poorly in ways over which they have personal discretion, such as refusing to work with you, calling you rude names, attacking you in public, and so forth, because of what you say or publish. We'll call that action Dandelion. Yet another action: people who were previously echoing your words or republishing your writing, potentially to a much larger audience, stop doing that because they disagree with your words in some way, but your original (possibly much more limited) publication venue is unaffected. We'll call that action Daisy. Debian is clearly not doing, nor is capable of doing, Clover. A whole lot of Dandelion happens all the time, and is probably unavoidable. One could argue that Debian is sort of officially doing Dandelion at the moment; personally, I don't think it is, but it's not 100% obvious. Debian clearly did Daisy. We can all agree on that. There's no point in arguing about Clover, because that's not happening. The primary argument we're having is over when Daisy is and isn't appropriate. I don't think changing the labels changes the core disagreement, which is that some people want to have a far higher bar for Daisy than other people. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Anthony Towns writes: > There are times when you don't have to think about what you're saying > before you say it; that situation is often called being "among friends", > or "in a safe space", or "able to let your guard down". > I think it's probably news to a lot of people that Debian isn't that > sort of a situation today. But of *course* we're not! The project is more than 1,000 people! There's no way that is a situation where we're all among friends and can completely let our guard down and say whatever we think without any filters. What you're talking about is trust, and we can certainly try to build trust within the project, and part of that is giving other people the benefit of the doubt, assuming good will, and so forth. To the extent that we can achieve that uniformly across everyone in the project, that's great. But a project with a couple dozen people can reach a much higher level of trust than a project of over a thousand people. As the scale gets larger, the level of baseline trust we can establish is necessarily going to be lower. Trust is complicated and involves a lot of factors. It's not just the assumption of good will, it's also the chances that someone else agrees with you politically, has the same motives that you do, cares about the same goals that you do, and so forth. Even things like sharing a native language or an economic background or a national origin help build trust. When the project gets larger, some of those parts of trust will lessen necessarily because we have a wider variety of members. It's sad in a way, but it's inherent in size. 1,000 people is a *lot* of people. (Obviously, there's a smaller core of people who participate in discussions like this, but it's still a *lot* of people.) I'm afraid Debian as a project is not in "small gathering with your close friends" territory. It's in "small town" territory. The good news is that this means we have way more people doing way more interesting work, and way more cultures and thus more interesting things to learn. The bad news is that, yes, the level of baseline trust is a bit lower, which means that we have to be more polite and more thoughtful and more, well, "civilized" in the old definition of "the way people behave in cities." > (IMO, one of the problems with planet aggregators is it changes your > personal blog from being a place where you can say whatever you want and > have it only affect yourself, to a place where you have to watch what > you say because it's automatically pushed to strangers who are only > interested in very particular parts of who you are) Yup. And if you don't want that effect, well, don't aggregate your blog. It's okay to not aggregate your blog! -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Martin Steigerwald writes: > Ian Jackson - 05.01.19, 18:17: >> Very competently toxic people will calculate precisely what they can >> get away with: they will ride roughshod over weak victims or in >> situations with less visibility; when challenged by an authority who >> can impose consequences, they will lie and obfuscate and distract as >> much as they can get away with. They will turn the dispute about their >> personal bad behaviour into a big poltical fight so as to increase the >> cost of enforcing the rules against them. And if that fails they will >> do precisely as much as is needed to avoid further punishment. > Have you actually really seen such kind of behavior? Yes. Worse, I was young and stupid and didn't recognize what was going on, so I let myself get taken in by it and made excuses for them and thus became part of the problem. I've hopefully gotten better at recognizing the signs earlier now. I don't think this is a problem that Debian is commonly plagued by, but there are absolutely people in this world who I don't want to have anything to do with, and if they join a community I'm a member of and that community won't eject them, I will leave. Because life is too short to be on edge all the time, to be in a community that I cannot trust at all, or to pour my emotional resources into that kind of scary black hole. Hopefully eventually they'll realize how much they hurt other people, but they can work on realizing that somewhere far away from me and anyone and anything I care about. I just want to have some fun working on free software and maybe changing the world a little bit, hopefully in the company of some people I can call friends. At no point in that process did I sign up to be part of a community psychological counseling effort for dangerous people. I am, to be clear, saying this in the abstract, and please don't read particular people from the current discussion into this comment. But you asked a general question about whether such people truly exist in the world, and the answer is yes, they do. Also, to be clear, if you're reading this and thinking "shit, am I one of those people?", you're not. Almost by definition. I have never seen anyone who acted that way ask themselves that question. One of their most defining characteristics is that nothing, *nothing* is *ever* their fault (although some of them can fake convincing apologies). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
lace of almost total lack of understanding of what it was like to be on the TC during that decision. I think I put more thought into all of the aspects of that decision, including weight on the impacts of the decisions, than just about any other decision I've made in my life. I have put less thought into where I live than into systemd. I think this is part of that all-too-human belief that one's own position is so obviously correct that if anyone disagrees with you, it's just because they've not thought about the problem hard enough. And it's just not true. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Miles Fidelman writes: > On the other hand, the IETF seems to do just fine - with a much larger > base of participants, and a lot more room for discussion and debate on > contentious issues. Global infrastructure, with distributed ownership, > lots of stakeholders, all held together by agreements, with the decision > processes open to pretty much anybody who shows up. The process puts > pretty much everyone else to shame - with lots to be learned from it. Speaking as someone who is a listed author on three published RFCs and chaired one IETF working group, I will take Debian process over IETF process any day, and find your description of the IETF pretty entertaining. :) Also, please note that many IETF participants are paid as part of their job to participate in the IETF. (We keep coming back to that.) That's true of some Debian contributors as well, of course, but I strongly suspect the percentage is lower. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Miles Fidelman writes: > I think you're minimizing the level of investment & commitment it takes > to either use Debian, particularly in production, and even more, > minimizing the efforts of upstream, and kernel, developers upon whom > Debian ultimately depends. I really don't think I am, particularly since I've also done many of those things, but I'm also a bit baffled as to why you think that you should get to decide what I do with my volunteer time when you're not paying me. I mean, that's really what this comes down to. Of *course* the people who are members of the Debian project have the primary say it what it does. > There are also those who contribute by providing support - e.g., > answering user questions on Debian lists. And those people can join the project as voting members so that they can have a say. (I would love to see more of that, in fact; it's important to include people in our community who do other things than package.) > As far as I can tell, the only people who count, in Debian decision > making, are packagers - which strikes me as a rather bizarre case of the > tail wagging the dog. Seriously, if you want control over something that you use, you have to put resources into it, whether that is time or money. You can purchase something and have the influence of a customer and whatever contract you can get, or you can put in sweat equity and get a voice that way. Those are pretty much your choices, apart from government-controlled projects. This isn't a very radical concept. > I remain amazed how much the impacts on users, systems administrators, > and upstream developers were dismissed as irrelevant. You list those things as if they're somehow distinct, when many (most, probably) Debian Developers are all of those things. > On a larger note, I point to the IETF as an example of a much larger > community, running huge infrastructure, where pretty much anyone who > shows up has a voice. Do you know how the IETF funding model works, and how the Debian funding model works? You do know that the parent organization of the IETF has paid employees, right? The IETF is a lot more like the Linux Foundation than it is like Debian. And that model has its place in the world, but I wouldn't be a Debian Developer if Debian were funded and run that way. > I'm sorry to say this, but the only value that Debian provides to the > world, is packaging. And, personally, over time, I've found it more and > more necessary to download, build, and compile from source - reducing > the value of Debian. > Pretty soon, I expect I'll be migrating. Okay? I mean, you say that like you expect me to be upset, but I'm totally okay with that, and I wish you the best of luck with whatever operating system you migrate to. I've said this before, but I think it's an important reality check: it doesn't matter nearly as much who uses Debian, or how many people use Debian, because we are not a company or a product, we don't sell something, we're not trying to make a profit or maintain some growth curve, and we're not part of this capitalist system. We are building a Linux distribution, to a very large extent, for each other, and delightfully other people also find it useful. Sometimes those people even join us! Which is great! But we are delightfully not beholden to anyone outside the project, apart from the much-appreciated donations of funding and equipment of course, for our goals or even our survival. Which means that we can have a much more collaborative, communal decision-making process that doesn't obsess over market share or retaining or monetizing every individual user. > And, next time I do any serious developing, I expect the only init > scripts I'll provide are sysvinit based. That suggests that my platform > will be something other than Debian. I hope you have fun and enjoy that platform! I'm very glad that you will be able to find a platform that is a better fit for you. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Miles Fidelman writes: > On 1/7/19 10:06 PM, Russ Allbery wrote: >> Speaking as someone who is a listed author on three published RFCs and >> chaired one IETF working group, I will take Debian process over IETF >> process any day, and find your description of the IETF pretty >> entertaining. :) > Well yeah, but which "works" better in terms of results? Particularly, > as viewed by those who are impacted by the process? Oh, Debian, by far. Debian is massively more productive than the IETF per unit of effort put in the front end. Now, some of that is the nature of standards development, which is inherently hard and much more contentious than nearly all packaging problems. But Debian puts far more work out in the world, faster, than the IETF does relative to the resources invested. That's part of why I'd rather work on Debian Policy than on IETF standards. IETF standards are very valuable, but the process redefines the concept of slow and tedious. And frequently, if there's no consensus, nothing happens at all in the IETF for literally years. (Not that this nevery happens in Debian *cough*, but it's less common and it's usually only relatively less important things.) That's fine, to be clear. I don't think that's a flaw in the IETF. The IETF is trying to do one thing (create general standards for the Internet) and Debian is trying to do something far, far different and more immediate (create and maintain a usable operating system that runs on real-world computers). Obviously they will be organized differently along the lines required to achieve those goals. But the IETF, particularly in recent years, has increasingly become an industry consortium in which representatives of companies negotiate with each other over how to implement interoperable standards for their products. Not a community of hobbyists who are building something in large part for the joy of it. The IETF is an excellent example of an organization where you largely have to pay people to get them to participate in it. There are certainly some people who participate in IETF working groups for fun, but compared to Debian I'm fairly sure it's limited. People largely participate in the IETF because they're trying to accomplish something specific *outside* the IETF for which an IETF standard would be useful, or because they're being paid to do so. Not, at least to the degree that is the case in Debian, because participating is *itself* fun and exciting and meaningful. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Miles Fidelman writes: > I was watching the discussion on systemd fairly closely. I could be > wrong, but very little of the discussions over systemd seemed to reflect > folks who managed production servers, or kernel developers, or developers > of key backend software (Apache, MySQL, Postfix, Sympa, ...). Well, for whatever it's worth, I was managing Debian production servers during the entire period of that debate (and for about ten years previous to that). I was the primary advocate for Stanford running its central infrastructure on Debian, so I'm familiar with the problems and arguments for and against using Debian in that sort of environment. Some of the other major voices in that debate manage far large production deployments than I did. My current employer uses Ubuntu in production, not Debian, for many of the typical reasons why people use Ubuntu over Debian, but from the perspective of systemd that's basically the same thing. Ubuntu went through essentially the same transition that we did. I do think distributions have some interesting challenges in the future, and what our users are asking from us is shifting. Containers and deep dependency programming ecosystems are both becoming more common, Go and Rust take a far different attitude towards how to assemble system components than C and C++ projects have historically, and cloud deployments are becoming far more common than hardware deployments for many of our users. One of the simultaneously fun and frustrating thing about this field is that problems are constantly shifting, and new ideas and new ways of doing things are constantly arising. Debian certainly will need to change and explore new and different corners of that, and feedback from day-to-day users of Debian both inside and outside the project will be very important to understand how to change. But, if anything, I think being *more* agile, not less, is where we can improve the most. And, of course, always trying to find ways in which we can have it all at once, where we can: provide a broad and inclusive platform for making a lot of different choices, so that we don't have to pick the best choices in advance and over-commit to one way of doing things. Which, among other things, calls for init system diversity, and I'm very glad to see that work continuing (although I personally still hope that someone will come up with a great init system that has the highly decoupled properties that people want but that isn't sysvinit with all of its well-known problems). I'll stop talking about this here since several folks are saying that we should keep init systems out of this conversation, and I'm not really helping. You just raised some points about the social impact of hard disagreements, and about how decision-making works in general in Debian, about which I have strong opinions and really wanted to reply. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Josh Triplett writes: > If you have to have your "guard up" to avoid hurting people, you have a > more fundamental problem. > It really *isn't* that hard to just think about the effect of your words > on others *all the time*. As Russ said, that's a fundamental skill. Eh... I do think that goes a little far. It *is* a fundamental life skill, but there are a lot of fundamental life skills that come harder for some people than others. For example, the absolute fastest way to make me miserable is to put me in a situation where I need to make verbal small-talk with strangers. In writing, absolutely, I can do that all day. In person, I run out of social energy *really fast*. I also consider this a fundamental life skill, and I've gotten better at it, but I am in no way good at it, and am usually still feeling awkward about mistakes I made in some conversation five years ago. My point in those messages was poorly expressed, particularly at first. It's not to argue that this is *easy* for everyone, just that this is something we do all have to do. For some people it's harder than it is for others, and if someone is trying and working on it and apologizing when they don't do it well, I'll extend them the benefit of the doubt all day long. Where I start drawing boundaries is when that transitions into not even making an attempt, or arguing that one should get to say whatever pops into one's head because free speech and the responsibility for filtering is entirely on the listener. That just doesn't fly in any human community I want to be part of. In other words, intention matters a lot to me. If someone is trying but it doesn't come naturally, that's one thing; if someone is being intentionally provocative and sniping at people because they think it's enjoyable or funny (and I grew up on-line on Usenet; I've met a *lot* of those people), well, surprise, people don't put up with that shit nearly as long as they used to, and that's a *good* thing. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Censorship in Debian
Miles Fidelman writes: > No. I may mind, but I sure don't want others minding on my behalf. I > find THAT offensive. Then I won't do that for you. But I'm sure you realize that your experience is not universal among all of humanity, and some people *do* want other people minding on their behalf in some situations, mostly because they're exhausted, sick to death of having to fight this battle, and/or much more likely to get abuse and harassment if they do speak up than I am. I will continue to emphasize the voices of those people and push for things that they care about in places where I'm fairly sure that's what they want because that's what members of a community do for each other. Hell, that's what *friends* do for each other. They have each other's backs. If a friend of mine cares about something that impacts them personally, that means that I probably should at least consider whether I should care about it too. For me, this is a core part of the *definition* of friendship. If I don't give a shit about things that hurt my friends, I'm not much of a friend, am I? Obviously, it's then on me to be *really* good at listening, and to not jump into places where I'm *not* wanted. And obviously it's not completely blind; sometimes a friend is going to be hurt by something, and on reflection I'm going to decide that whatever they were hurt by wasn't out of line. It's tricky. I'm going to mess up occasionally and have to readjust. But that's okay; it's still a lot less tricky than having to deal with constant harassment every time you express an opinion. I'm happy to do some of my part in supporting my friends. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: metaphors and feminism
Mike Hommey writes: > On Sat, Mar 30, 2019 at 10:22:35PM +0200, Jonathan Carter wrote: >> So, how about: >> DM: Debian Members. Full members of the project that can represent >> themselves as such, vote in elections, and have a @debian.org email >> address. (Pretty much what a DD and non-uploading DD is). > VDM: Vetted Debian Members. If we're going to add the V, how about voting members? That's the primary structural distinction, after all. I like the "member" terminology in part because it's common terminology for non-profits, meaning (roughly) what we mean by it: http://www.nonprofitlawblog.com/starting-nonprofit-voting-membership-structure/ That does mean it also runs the risk of some confusion since Debian itself is not a non-profit and does not have a legal existence, hence cannot have members in the legal sense. But still, the definition of "member" or "voting member" of a non-profit is spot-on for how we currently use DD. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Realizing Good Ideas with Debian Money
Adrian Bunk writes: > My biggest high level concern is the income side, since this is the most > difficult part and will likely also be the most controversial one. I could well be entirely wrong, but the part that I would expect to be the most controversial is that, once Debian starts spending project money to pay people to do work that other people in the project are doing for free, the project is doing a form of picking winners and losers. We're deciding as a project that some people's work is valuable enough to pay for and (by omission if nothing else) other people's work is not, and for all the good intentions that we have going in, there are so many ways for this to go poorly. If we're only hiring people from *outside* the project, not each other, maybe that avoids the worst of the problems, but it's still an odd dynamic. For example, it creates a perverse incentive for someone to resign from the project so that they can be paid for the work they're currently doing as a volunteer. I'm particularly concerned what will happen if something goes wrong: we pay someone to do additional work and that work isn't up to the quality standards that we need. Now what? If that person is also a Debian Developer, we have now introduced an aspect of job performance feedback into a volunteer community. While doubtless there are Debian Developers who are also managers in their day jobs, that's not something anyone is currently doing *in Debian*. Managing feedback and consequences for poor performance is a skill that we are not currently exercising and that is not trivial to learn. These problems generally go away with externally-funded initiatives such as LTS. In that case, even when Debian Developers are involved, it's clear that the person with the money is making contract and hiring decisions, is the person who can decide to fire someone from that contract if they don't like the work being done, and any decisions made there are entirely separate from one's ongoing Debian work as a volunteer. People still have to decide what they're willing to do for free and what they want to be paid for, but it helps a lot that LTS is scoped to one specific problem and has resources such that, if everyone else decides they're not willing to do LTS support for free, the initiative still survives. It also helps considerably that LTS was something we as a project had decided not to do with pure volunteer resources, so it's a pure incremental on top of project work. Maybe we can find more things like LTS that are pure incrementals over what the project is currently doing, but I'm pretty worried about the social dynamic of paying people to do core project work that others are currently doing for free. I assume the above is the sort of thing that Sam is referring to when he says that we need to have a higher-level discussion if we're going to pursue this idea. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Realizing Good Ideas with Debian Money
Ximin Luo writes: > A lot of people are already paid full-time to work on Debian. Wouldn't > it be better to additionally have some other people be paid full-time to > work on Debian under a democratic mandate (our voting system) rather > than under corporate orders? At the very least, it would be a good > social experiment to gain insight from - something like that hasn't not > been done much in the world before. In an ideal world, with some sort of cooperative allocation of resources in the context of a mutually supportive society where fundamental human needs are met automatically, yes, I would love to work out the details of such a system. In the messy, mostly-capitalist world in which nearly all Debian project collaborators are embedded, in which some of us have considerably more money and resources than others, where costs of living vary *wildly* by where you happen to live, and where one person's extra and mostly unimportant spending money is another person's food and rent, I am afraid that social experiment has a much higher chance to result in very real losses to the project. The failure mode here is that we lose contributors because of hard feelings over who gets paid and who doesn't get paid and how much they get paid and how they get paid, and the project ends up weaker and more fragile. People have strong feelings about money, sometimes even if they don't think they will. Not all people, not all the time, but it's a maxim because on average it's true. Money ranks right up there with politics and religion as likely to cause the most drama, the most hard feelings, and the most misunderstandings. That's because money is really complicated: it's not just a way to meet one's physical needs. It's also affirmation, it's a measure (sometimes competitive) of worth, and there's a whole lot of social programming and momentum behind the feeling that who gets paid is a measure of who is the most valuable. I respect the desire to try social experiments and be bold, but my counter question is whether Debian as a project has the right training and the right people to conduct a proper social experiment *here*, on *this* particular topic. Do we have economists? Psychologists? Do we know what the nature of the experiment would be? For example, you say "democratic mandate," but what *specifically* does that mean? Are we going to vote in a GR on who gets paid and who doesn't? Wouldn't that risk compensation turning into a popularity contest, or at least being perceived that way? If we're paying someone under such a system, is there any accountability if they don't do what we're paying them for? Is there someone supervising them, and if so, who? Or are we just giving people $X and saying "do whatever you want with it"? This stuff is very not easy to figure out. You rightfully point out that people are getting paid now, and that payment determines, partly, their priorities in the project. That's true, but that payment comes from a huge variety of different sources and there are very strong social norms in the free software community about what sorts of things people writing those checks get to determine for the community and what things they don't. And we have a lot of ways of handling when some contributor no longer is getting paid to do something they were doing, and a firm understanding that this isn't *because* of our community, although it may be a problem our community has to find a way to deal with. These dynamics change a *lot* when the money is coming from the project itself. That money is special; it's not just one more company or foundation or whatnot that is providing resources to aid in a general volunteer project. It becomes a loaded statement about what work the project considers the most important and, worse, *who* the project considers important to do that work. It's a real problem for the project that we don't have a better way of allocating resources, and it hampers us in some ways compared to, say, Ubuntu or Red Hat, where there is a single, stable funding stream to maintain the distribution and set firm priorities. There are some things we don't do as well as those distributions because of it. But, for instance, while I know a lot of people volunteer work for Ubuntu, I personally have very little desire to do anything with Ubuntu because people get paid to do that. Particularly now that my free time is rarer and more precious to me, doing unpaid work for an organization that also has paid staff is hugely demotivating. It's entirely plausible that paying for resources would mean that Debian would end up with *less* resources than we have now, if other volunteers feel the same way. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Realizing Good Ideas with Debian Money
Ximin Luo writes: > Nobody is suggesting that it won't be a hard problem to get right, but > progress isn't made by worrying about all the things that could possibly > go wrong. Figuring out a blueprint for organising large-scale work > using more directly-democratic principles would have lots of benefits > far beyond this project. Yup, this is fair, and I admit that I tend to see the problems more readily than the opportunities. My core point is that I personally don't believe this is the right experiment for us. I don't think Debian is the right organization to try this. I don't think we have the expertise and the muscle in the right places to be the project to lead in this specific area. However, this is just my opinion, and I don't want to try to persaude you too strongly, because if you're right and I'm wrong and we can make this work, it would be a very neat positive development. Funding free software development is an enormous problem right now that desperately needs options other than controlling sponsorship by for-profit companies with all the baggage that carries. > Then some of the other things you mentioned are not necessarily > downsides. Making a loaded statement about what work the project > considers the most important isn't necessarily a bad thing, especially > if it stands against the loaded statements that Big Tech already puts > out worldwide, that give engineers (including open source engineers) a > bad name in front of people that don't know there are less monopolistic > ways of creating and using technology. I think I'm coming from a place where I feel like our community is still rather fragile, and I'm worried about putting more stress on it by making those sorts of loaded statements. But yes, it's entirely possible that I'm being too cautious. I will say this: we only have the energy to make a small number of big bets like this. If we work on funding development, we're *not* going to work on most, if not all, of the other big bet ideas that the project could work on. Now, that's possibly better than not working on *any* big bets, and we do have a tendency to default into not changing anything, and that isn't going to serve us well in the long run. I'm in favor of picking something big and going for it. But I think we should pick one or two big things, no more, and try those things until they reach some agreed-upon conclusion before adding more on. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Realizing Good Ideas with Debian Money
Adrian Bunk writes: > On Fri, May 31, 2019 at 04:07:54PM -0700, Russ Allbery wrote: >> I could well be entirely wrong, but the part that I would expect to be >> the most controversial is that, once Debian starts spending project >> money to pay people to do work that other people in the project are >> doing for free, the project is doing a form of picking winners and >> losers. > Perhaps I am wrong on that, but I am associating the term "picking > winners and losers" as an ideological statement used by US Republicans > and Libertarians. For most people outside the US the underlying > "government is bad" philosophy doesn't make any sense. *heh*. Er, no, not even remotely. I'm about the farthest thing you can get from a US libertarian or someone who thinks government is bad. I'm sorry to have used a confusing term and muddled my point! What I'm trying to get across here is that one of the rather fundamental things about Debian is that everyone works on the things they care about, and the project is mostly neutral about which of those things are the most important. What's the most important is decided in a very practical, democratic way: it's what people are willing to work on. This is isn't an unmitigated good by any stretch of the imagination. Sometimes we really do want to decide that something specific is important even if no one wants to do it. And those are probably good places to look at spending money, so I'm probably being too negative about the idea. If we can find other things like LTS where everyone thinks it would be great if it somehow happened but people are generally not willing to do it for free, I think those would be compelling places to spend money if we can sort out the supervision issues. I'm just quite nervous about breaking down that deep structure of Debian where we vote with our own time and energy. It's not perfect and it has flaws, but we understand it well and it "feels" fair (at least to those of us who have been in that world for a long time). I know no one is proposing this, but a shift towards a model where people pick priorities for the project and then direct effort to work on those things and not other things would, for me, start feeling a lot more like a job, and would hurt my motivation a lot. I'm not all that productive at the moment, so that doesn't matter a ton for me personally, but I'd be worried others would feel the same way. But what I'm hearing in the thread is that this is probably an avoidable problem if we're careful to pick and choose the right types of projects. Janitorial work, as you mention. (Also, the point is well-taken that "voting with time and energy" is not particularly "pure" in Debian already, since various corporations vote with their money to fund people to do various things they care about. So this is already complicated and is not a pure volunteer endeavor, to be sure. That said, my impression -- on the basis of no actual research, so maybe it's wrong -- is that Debian is driven much less by corporate priorities than a lot of large free software projects. Certainly less than the Linux kernel, to take an obvious example.) > My personal experience with real-life self-organizing projects is that > the hardest part is usually finding volunteers who clean the toilets > daily. > There are areas like DSA or security support that are essential, but not > the "package the cool latest software" kind of work where volunteers are > easy to find. Yeah, this is a very good point. > But this direction of higher-level discussion only makes sense if there > is a realistic prospect of a reliable long-term money source generating > at least US$ 1m per year - there are completely different discussions > depending on whether the additional money available to be spent each > year would be US$ 0.1m, US$ 1m or US$ 10m. I very much doubt that our current donation-driven model would generate US $1M per year on a sustained basis, particularly if you subtract DebConf out of the mix (which I think we should, because that money is essentially earmarked for a specific purpose and has a whole sponsorship and advertising component that works great for the conference but that I doubt we would be comfortable with in Debian proper). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Realizing Good Ideas with Debian Money
Jonathan Carter writes: > On 2019/06/01 19:55, Russ Allbery wrote: >> I very much doubt that our current donation-driven model would generate >> US $1M per year on a sustained basis, particularly if you subtract >> DebConf out of the mix (which I think we should, because that money is >> essentially > DebConf tends to bring in money for Debian, so not sure why you would > want to subtract it. You cut the part where I explained why. :) That said, I'm not deeply familiar with how much of the money that is donated during DebConf fundraising goes to general project funds instead of to putting on DebConf itself; perhaps the money is not as earmarked as I thought. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Realizing Good Ideas with Debian Money
"G. Branden Robinson" writes: > My two cents[4] is that DSA should make its purchasing and hardware > solicitation decisions with the architectural security issue fairly far > down the priority list. It saddens me to say that, but this new class > of exploits, what van Schaik et al. call "microarchitectural data > sampling" (MDS), is a playground for security researchers right now; a > big rock has been turned over and bugs are erupting from the soil in a > squamous frenzy. It will take months or years for the situation to > settle down. > To acquire hardware based on what is known today is to risk buyer's > remorse. Plan on inescapable remorse later; every chip vendor will let > us down until corporate managers learn to treat confidentiality and > integrity as feature rather than cost centers. (And count on them to > forget what they've learned after a few quarters pass without > embarassing headlines.) +1 to this. So far as I can tell, about the only thing that seems to correlate with being less likely to have side-channel attacks is less sophisticated scheduling pipelines and processor architecture (read: simpler, slower processors). And this area of security research is changing very rapidly. I would expect several more novel attacks to surface. Processors that don't have a bunch of non-free, unauditable bullshit as a proprietary control plane would obviously be better, but you'd be paying a prohibitive performance price (not to mention other issues). There just aren't any good options right now. Buy (or accept donations of) whatever makes sense for other reasons, and expect there to be mandatory microcode updates, kernel and virtualization workarounds, and security bugs. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Alternatives to the Socratic Method
"Chris Lamb" writes: > To elucidate, it was my understanding that the Socratic Method — at > least as the term is used today — refers to one interlocutor asking a > series of unfolding questions with the aim of leading another to reach a > particular point of view. I think the thing that most often bothers me about the Socratic Method is not the method itself, but instead is problems of consent around how it's deployed. Asking a series of unfolding questions can be a powerful teaching technique, but the underlying assumption is that someone is teaching and someone else is learning. That, in turn, is a relationship that I think should be consentual: the person who wants to learn should understand that's what's going on and be actively agreeing to go through this exercise in order to learn more. If, instead, someone has a different opinion from someone else and wants to persuade (which is not the same thing as teaching), but there's no previously-agreed teaching relationship, diving into Socratic questioning feels weirdly indirect and a bit presumptuous. I'd rather just state my objection or different opinion up-front with an open offer to explain how I arrived at it. Then the other person can choose to opt into a (temporary) teaching relationship while I explain my thought process (if it's complicated enough to warrant that much structure), and at that point the Socratic Method may be great. Usually when I find myself getting into that sort of Socratic dialogue, it turns out that the other person already understood the first four or five steps and going through the preliminaries was just sort of weird, and it would have been better to just start at the end and back up only until we find the point of disagreement. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian supports pridemonth?
Roberto C. Sánchez writes: > Hispanic Heritage Month is coming in a few months (at least in the US, > not sure about international observances). Perhaps Debian could make a > public show of support for those of Hispanic origin (who tend to be > drastically underrepresented in the community). We already missed Black > Heritage Month this year in the US, but it is coming in October for > Europe and will come round again in February in the US. Blacks, or > African-Americans, are similarly underrepresented in the community. > Perhaps we could also show support for Jews and those of Jewish origin > during one of the principal festivals (Passover, Weeks, or Tabernacles). I think this would be great. Explicitly saying to our various communities on days of significance to that community that they are welcome and supported in Debian seems like a warm-hearted and open gesture, and I fully support it. My employer does this for four or five of the events that are the most significant to company employees, and it's always very welcome. The criteria I'd use (because we do have to draw some sort of line somewhere, since there are more days or months like this than there are days and months in the year if you look hard enough) is to let the relevant community in Debian take the lead. That also avoids the occasional issues where there is some supposed recognition of a group that is controversial or unwanted within that group, which happens from time to time because humans are complicated. So, we should look to our LGBTQ project members to decide what Debian should do for Pride, to our Hispanic members to decide what Debian should do for Hispanic Heritage Month, and so forth, since they're the experts on what they would find the most meaningful within the Debian context. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian supports pridemonth?
Gerardo Ballabio writes: > Clearly, there must be a prior assessment that any particular group's > values are aligned with Debian's values. Sure, of course. > And I don't think that this is, or should be, within the bounds of the > Publicity Team delegation. I think this is probably the place where we disagree. That said, how *do* you want to handle this, assuming that other people in the project do want to acknowledge important events for our community members? For example, Debian has made note of Diwali in the past in various ways (arguably less obviously than changing the logo, to be fair), and it's been entirely uncontroversial. Having a GR every time the project wants to acknowledge a day that is important to part of the project seems rather excessive to me. Perhaps it's just because I come from a work culture where this sort of acknowledgement is entirely routine and unexceptional, but this all feels like a tempest in a teapot to me. My position is that if some subgroup of Debian wants some sort of acknowledgement that's meaningful to them, we should default to doing so unless we have some obvious reason not to, and I trust the Publicity Team to judge whether such a reason exists and escalate or figure out some other approach if it does. I think this is much less complicated than people are making it. Now, if the *actual* issue here isn't about process, but is instead an argument that Debian shouldn't be recognizing Pride, specifically, then we simply disagree, and I'm not sure fiddling with the process is going to help. And no, I don't think this is something the project should avoid because it makes some people uncomfortable. If we have to hold a GR on having Debian acknowledge Pride, I'll second it, and I suspect it will pass easily; I just hope we can avoid that. > An example that is probably more to the point: Debian certainly > welcomes Israeli people, but if publicity were to issue a statement > that Debian supports a Zionist initiative, I'm sure that many would > object. We could instead acknowledging Jewish holidays as a way of making our Jewish community in general feel welcome (if that is something that would be meaningful to them). For instance, Jewish co-workers at my job organize an after-work Passover meal each year and invite anyone who wants to join. Corporations navigate this routinely, despite much stronger constraints (even legal constraints) on what types of acknowledgements they can do. > (There is of course a difference between being Israeli and being a > Zionist. I'd argue that it is the exact same difference that there is > between being LGBTQ+ and being an LGBTQ+ activist.) Pride is not the activist event that it used to be, at least in the United States and I believe in a lot of Europe. It's become very mainstream. (This is something that some people in the LGBTQ+ community are also rather frustrated with, as it turns out, but nonetheless, I think that's where we are today.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian supports pridemonth?
Adrian Bunk writes: > Why should Debian honor people in the US of one specific race? Because they are part of our community and the gesture would be meaningful to them. To me, this is like asking why Debian should be acknowledge the death of a contributor, or why Debian should congratulate a project member on a major life milestone, or celebrate a project member winning an award. We do things like this because we are not a computer program. We are a community of living, breathing people who care about each other and who want to celebrate and support and welcome each other. > It might make sense for you to honor them inside your country, but for > the other 95% of the population of this planet they are just people with > the privilege of living in the US. They are Debian project members. That's the part that matters. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian supports pridemonth?
Zlatan Todoric writes: > In my opinion, and as Russ explained about becoming political is > basically unavoidable, I would be actually up for celebrating things > that can (should?) be worldwide celebrated - community celebrating Pride > Month is in my opinion a worldwide community. Celebrating specific > racial/national/religious things, I think that should be left out for > multiple reasons: nations change through history and if you celebrate > holiday of one nation, you can easily miss how it offends the other > nation, same goes for race and religion. > So LGQBT, Software Freedom, Universal Healthcare, Basic Income etc - yes > (it affects all human kind) > Hispanic/Black/Jewish/Green/Orange/Blue things - no, because they are > specific to certain group and diversity statement is all-inclusive for > that purpose, no need to pinpoint specific groups. I wonder if this may be a cultural difference (and by saying that, I want to stress that means that I think different members of the project will arrive at different conclusions entirely in good faith, and there's no real objective right or wrong). For example, my employer (Dropbox, for what it's worth, but I think this is common among a lot of our peer companies) celebrates Black, Hispanic, and Asian and Pacific Islander months (and I'm pretty sure others that aren't occuring to me), along with things like Diwali, Ramadan, and Passover (and of course Christmas and Easter), all in different ways. These are generally self-organized by employees for whom these events are meaningful, they're entirely optional, and they focus on talking about food, heritage, art, personal history, and other similar things that vary in their specifics but unite us as humans. The point of this is to recognize that people are different and bring those differences to the workplace as part of their whole selves, people don't have to fit into a single model or mold, and learning about other people and the things they find meaningful is inherently interesting and broadens perspective and helps us all work together more smoothly. This is a fair amount of work (I don't know that Debian should try to tackle that many events unless members of our community are asking), and it does require a bit of effort to be thoughtful about how to organize such events, but I think it's valuable. But that's my cultural background; that's the sort of thing that I'm used to, so when it comes up in the Debian context, that's the spirit in which I take it. Other folks may have much different personal experiences and therefore may take it in different ways. This may be something that's literally never done in your workplaces or in your society, and thus something that seems strange or unnecessary. However, I *don't* think that saying we therefore shouldn't ever touch any of these topics is either workable or wise. Like it or not, humans are inherently political (political comes from the root word polis, or public life, which is unavoidable whenever there is a public). For people coming from a culture where this sort of acknowledgement is common, *not* acknowledging someone's meaningful celebrations is *also* a political statement, particularly if it's done because someone's culture is deemed "controversial." There is no easy default action here; we're a large enough project with a large enough community that we have to wrestle with this in one way or another. Anyway, personally I'd rather err on the side of *more* celebration of the diversity of people in the Debian project, including noting meaningful days and events for them, because I think it says something important about our community. It says that we're a world-wide community of people from a huge variety of backgrounds and interests, and that diversity is also reflected in our huge diversity of packages and the universality of our operating system. > That said, I like celebrations (good way to find out about different > cultures/things), so maybe, just maybe we could have these things still > being issued by Publicity Team but with some specific Headline Tag like > "Debian Diversity Celebration: Today we celebrate US Black Heritage" and > then some text about its history etc - that way it would be informative > and fun IMHO. This is, for what it's worth, roughly what US corporations tend to do. (Personally, I think we should always strive to be better than a typical corporation, not being much of a personal fan of capitalism, but they do spend a fair amount of time thinking about how to navigate these sorts of things among large numbers of humans who are forced together by something largely unrelated to their personal backgrounds.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
