Re: A policy on use of AI-generated content in Debian
Stefano Zacchiroli writes: > (1) You are free to use AI tools to *improve* your content, but not to > create it from scratch for you. > This point is particular important for non-native English speakers, > who can benefit a lot more than natives from tool support for tasks > like proofreading/editing. I suspect the Debian community might be > particularly sensible to this argument. (And note that on this one > the barrier between ChatGPT-based proofreading and other grammar/ > style checkers will become more and more blurry in the future.) This underlines a key point to me, which is that "AI" is a marketing term, not a technical classification. Even LLMs, a more technical classification, can be designed to do different things, and I expect hybrid models to become more widespread as the limitations of trying to do literally everything via an LLM become more apparent. Grammar checkers, automated translation, and autocorrect are all useful tools in their appropriate place. Some people have moral concerns about how they're constructed and other people don't. I'm not sure we'll have a consensus on that. So far, at least, there don't seem to be the sort of legal challenges for those types of applications that there are for the "write completely new text based on a prompt" tyle of LLM. Just on a personal note, I do want to make a plea to non-native English speakers to not feel like you need to replace your prose with something generated by an LLM. I don't want to understate the benefits of grammar checking, translation, and other tools, and I don't want to underestimate the frustration and difficulties in communicating in a non-native language. I think ethical tools to assist with that are great. But I would much rather puzzle out odd or less-than-fluent English, extend assumptions of good will, and work through the occasional misunderstanding, if that means I can interact with a real human voice. I know, I know, supposedly this is all getting better, but so much of the text produced by ChatGPT and similar tools today sounds like a McKinsey consultant trying to sell war crimes to a marketing executive. Yes, it's precisely grammatical and well-structured English. It's also sociopathic, completely soulless, and almost impossible to concentrate on because it's full of the sort of slippery phrases and opaque verbosity of a politician trying to distract from some sort of major scandal. I want to talk to you, another human being, not to an LLM trained to sound like a corporate web site. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: A policy on use of AI-generated content in Debian
Tiago Bortoletto Vaz writes: > I personally agree with the author's rationale on the aspects pointed > out (copyright, quality and ethical ones). But at this point I guess we > might have more questions than answers, that's why I think it'd be > helpful to have some input before suggesting any concrete proposals. > Perhaps the most important step now is to get an idea of how Debian > folks actually feels about this matter. And how we feel about moving in > a similar direction to what the gentoo project did. I'm dubious of the Gentoo approach because it is (as they admit) unenforceable, which to me means that it's not a great policy. A position statement, maybe, but that's a different sort of thing. I also agree in part with Ansgar: we don't make policies against what tools people use locally for developing software. I think the piece that has the most direct impact on Debian is if the output from the AI software is found to be a copyright infringement and therefore something that Debian does not have permission to redistribute or that violates the DFSG. But we're going to be facing that problem with upstreams as well, so the scope of that problem goes far beyond the question of direct contributions to Debian, and I don't think direct contributions to Debian will be the most significant part of that problem. This is going to be a tricky and unsettled problem for some time, since it's both legal (in multiple distributions) and moral, and it's quite possible that the legal judgments will not align with moral judgments. (Around copyright, this is often the case.) I'm dubious of our ability to get ahead of the legal process on this, given that it's unlikely that we'll even be able to *detect* if upstreams are using AI. I think this is a place where it's better to plan on being reactive than to attempt to be proactive. If we get credible reports that software in Debian is not redistributable under the terms of the DFSG, we should deal with that like we would with any other DFSG violation. That may involve making judgment calls about the legality of AI-generated content, but hopefully this will have settled out a bit in broader society before we're forced to make a decision on a specific case. I also doubt that there is much alignment within Debian about the morality of copyright infringement in general. We're a big-tent project from that perspective. Our project includes people who believe all software copyright is an ill-advised legal construction that limits people's freedom, and people who believe strongly in moral rights expressed through copyright and in the right of an author to control how their work is used. We could try to reach some sort of project consensus on the moral issues here, but I'm a bit dubious we would be successful. At the moment, my biggest concern about the practical impact of AI is that most of the output is low-quality garbage and, because it's now automated, the volume of that low-quality garbage can be quite high. (I am repeatedly assured by AI advocates that this will improve rapidly. I suppose we will see. So far, the evidence that I've seen has just led me to question the standards and taste of AI advocates.) But I don't think dealing with this requires any new *policies*. I think it's a fairly obvious point of Debian collaboration that no one should deluge their fellow project members in low-quality garbage, and if that starts happening, I think we have adequate mechanisms to complain and ask that it stop without making new policy. About the only statement that I've wanted to make so far is to say that anyone relying on AI to summarize important project resources like Debian Policy or the Developers Guide or whatnot is taking full responsibility for any resulting failures. If you ask an AI to read Policy for you and it spits out nonsense or lies, this is not something the Policy Editors have any time or bandwidth to deal with. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Don`t upgrade pip
Леонид Сергеевич <7matr...@gmail.com> writes: > DEPRECATION: reportbug 7.5.3-deb10u1 has a non-standard version number. pip > 24.0 will enforce this behaviour change. A possible replacement is to > upgrade to a newer version of reportbug or contact the author to suggest > that they release a version with a conforming version number. Discussion > can be found at https://github.com/pypa/pip/issues/12063 > WARNING: There was an error checking the latest version of pip. Interestingly, if I'm reding the specification correctly, 7.5.3-deb10u1 is a valid semver version (although it indicates a pre-release, incorrectly in this case). PEP 440 is more restrictive than semver in that respect, though. Unfortunately, I don't see a good PEP 440 version number for what reportbug versioning is trying to do. It's sort of a post-release, but .postN only allows a single number. I'm not sure that there's anything much better than 7.5.3.10.1, which unfortunately requires more human interpretation of the last two segments (and also isn't a valid semver, which probably doesn't matter a lot but which is unfortunate). With my day job hat on, I think this is a good change for the Python ecosystem as a whole. I maintain software that has to parse Python package version numbers to check for security updates, and dealing with non-standard version numbers is a real pain. I just wish PEP 440 were aligned with semver and that both standards were a bit richer. Debian has dealt with a lot of versioning challenges that neither standard seems to have addressed, such as multiple named versioning streams that nonetheless need to maintain a total order, although our standard is also looser than would be ideal for PyPI since we try to allow for nearly arbitrary upstream version numbers. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: [RFC] Extending project standards to services linked through Vcs-*
ead towards requiring all projects be in Salsa or some successor, and I'm all in favor. But until such time as we're willing to make that decision, I'm dubious about singling out GitHub as verboten when we allow Vcs-* fields to point to read-only Git repositories with a subset of the functionality that GitHub provides to people without an account. In other words, if we're going to require Vcs-* point to an actual forge and not just a VCS repository, great, but we're not there yet. I recognize your point about how GitHub excludes certain users and I in no way mean to defend this. This is a real feature of Salsa, even more than I was previously aware. But I also don't think this is a strong enough argument on which to rest this proposal. The BTS interaction is also exclusive in the sense that not everyone's email is going to get through; some of it is going to be filtered or rejected for all sorts of reasons. Communication is lossy. I completely agree that we should have fallbacks that are as universal as possible, and that we should not be telling people they are required to use GitHub. But this doesn't feel like the right hammer to me. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Questionable Package Present in Debian: fortune-mod
Conduct to something that does not have at all the same context as what the Code of Conduct was designed to address. If we were going to write a project content policy (which I'm dubious we really need to do, or that it would be worth the emotional effort required), I think it would look much different than the Code of Conduct because it would have different goals. It wouldn't be about building a community or encouraging productive collaboration, because the contents of our archive don't need to do either of those things. Lots of people use Debian who are not members of any shared community, and this is a feature. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: [RFC] Extending project standards to services linked through Vcs-*
Dominik George writes: > For the GitHub case, the problematic terms would be that in order to > register for a GitHub account, users must be at least 13 or 16 years old > (depending on the jurisdiction) ant must not live in a country under US > embargoes. This implies that Salsa is happy to create accounts for people under the age of 13, since the implicit statement here is that Debian's own Git hosting infrastructure is less excluding than GitHub. That's a somewhat surprising statement to me, given the complicated legal issues involved in taking personal data from someone that young, so I want to double-check: is that in fact the case? (US embargoes are indeed going to be a problem for any service hosted in the United States, and possibly an issue, depending on the details, for any maintainer with US citizenship even if they're using a site hosted elsewhere. I would not dare to venture an analysis without legal advice.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Bug#1043539: project: Forwarding of @debian.org mails to gmail broken
Cord Beermann writes: > As listmaster i can confirm that it is a big problem to deliver Mails to > gmail/outlook/yahoo. Yahoo Subscribers are mostly gone by now because > they bounced a lot, for gmail it is so much that we just ignore bounces > because of those rules. Yes, I gave up for the mailing lists I run and just rewrite the From address to be the address of the list and move the actual sender to Reply-To, and I see other technical mailing lists like the glibc lists have started doing this as well (using the built-in Mailman feature, which can optionally do this only if the sender domain has SPF/DMARC records). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1043539: project: Forwarding of @debian.org mails to gmail broken
Helge Kreutzmann writes: > It's just that I never had this problem with mails to people with > @debian.org addresses, so either my new configuration or some other > change, I don't know. The problem I suspect is with email forwarding, and specifically email forwarding to Gmail, which has recently ramped up the amount of verification it does on messages. Because of email forwarding, Gmail sees a message purportedly from helgefjell.de but actually delivered by debian.org mail servers, and has now decided to be suspicious of that. If that's correct, you'll only have this problem with Debian developers who forward their @debian.org addresses to Gmail. Gmail handles some large percentage of all email on the Internet, so this probably isn't rare, but Debian developers are less likely to use it than random Internet users for obvious reasons, so it doesn't surprise me you've not run into the problem before. (In other words, I doubt this is a problem with your local configuration.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1043539: project: Forwarding of @debian.org mails to gmail broken
Helge Kreutzmann writes: > I don't know how it worked so far, and the error could be on my side, as > I recently switched my e-mail setup; however, I don't see anything I can > do to make DKIM/SPF point to @debian.org instead of @helgefjell.de, when > transferring e-mail to gmail. The mail to which I'm resonding also comes from your @helgefjell.de domain, so I'm suspecting some DKIM/SPF issues there if you're using that same address in your original mail message. But just in case you were trying to send from your @debian.org address, one option is to send all of your outgoing mail that is from your debian.org address through the debian.org mail servers. See: https://dsa.debian.org/user/mail-submit/ I don't think this is the direct answer to your original question, but I suspect it would work around the problem. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Vulnerability Question
Frank Carr writes: > Hi, I am trying to determine if there are any plans to release a stable > patch for Debian 11 that address the following CVEs: > CVE-2022-3534 > CVE-2022-3606 > CVE-2022-3715 > CVE-2021-45941 > CVE-2022-3534 > CVE-2022-3606 > CVE-2022-4899 > CVE-2023-29491 > CVE-2023-2953 > CVE-2022-1304 > CVE-2022-31782 > CVE-2021-33560 > CVE-2019-6129 > CVE-2019-20838 > CVE-2013-4235 > CVE-2020-13529 I spot-checked several of these via the Debian security tracker at: https://security-tracker.debian.org/tracker/ (You can enter a CVE into the search box at the bottom.) The ones I checked were all low-priority security vulnerabilities that were fixed in the bullseye release (Debian 12). I can't speak to the security team or package maintainers about their plans for a stable update for these or other vulnerabilities, but if you're concerned about them, the best way to address them right now would be to expedite your upgrade to bullseye. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Brief update about software freedom and artificial intelligence
Daniel Lange writes: > From Paul Wise: >> I note that fair use isn't a worldwide concept and other parts of the >> world have the more varied and restricted concept of "fair dealing". >> https://en.wikipedia.org/wiki/Fair_use#Influence_internationally >> https://en.wikipedia.org/wiki/Fair_dealing >> So, as much as possible, we should try not to rely on fair use. > The Wikimedia Foundation fellow and legal counsel Valentina Vera-Quiroz > (CC) has documented her current expertise around ChatGPT and Copyright at > https://meta.wikimedia.org/wiki/Wikilegal/Copyright_Analysis_of_ChatGPT Oh, thank you very much for this link, and thank you to Valentina for writing this! The section "Can you use copyright-protected works to train AI models?" says exactly what I was attempting to say in my previous contributions to this thread, except more clearly, accurately, and succinctly. Anyone who was reading my previous messages should just go read that instead. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Brief update about software freedom and artificial intelligence
"Roberto A. Foglietta" writes: > - then I decided to protect my projects repositories as database > (collection) in addition to the standard way to protect the code with > a well-known license > - because of the copyright law about databases, if someone creates a > larger database that contains my database or a part of it, then they > have to comply with the license that I choose to protect my project as > a database. In the United States, this is only true if (a) the collection is copyrightable (let's presume that's true in this case), and (b) their use of your collection is not fair use. If their use of your collection is fair use, then they do not have to comply with your license. In other countries, I have no idea. Presumably there is a similar set of rules under the same or different terms to allow such things as parodies, but the boundaries may be different and I know very little about how those rules have been applied to software outside of the US. My understanding is the Berne Convention doesn't standardize the rules around fair use (under whatever name), so this can differ a lot by jurisdiction. > You see, it is a very simple and straightforward concept. The only two > ways to get off this are 1. make unlawful the database copyright law, > 2. make a law for which the training input collection is not coverable > by the copyright law. In both cases every employer can bring to their > home a copy of a database or a copy of AI training inputs and share it > with all the rest of the world. Moreover, the 1. includes the 2 while > the 2. would seriously undermine the database copyright law because > every database could be a training set for an AI/ML engine. > Russ, do you agree? :-) No. It's entirely possible that using databases as training sets for an AI/ML engine is fair use under existing United States law and precedent as long as that use is sufficiently transformative (the first factor of the test, and I suspect the most important one here). The obvious example is a search engine, which performs a similar transformation of clearly copyrighted works into a new service with a different purpose, without the explicit permission of the copyright holders. This is the reason why people have focused so much on GitHub Copilot's willingness to insert large blocks of code from other projects verbatim. Reproducing code from other projects is less transformative and looks more like simple copying, and therefore opens GitHub to a legal argument that their AI model is not sufficiently transformative to be fair use. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Brief update about software freedom and artificial intelligence
"Roberto A. Foglietta" writes:
> On Mon, 27 Feb 2023 at 07:16, Russ Allbery wrote:
>> This is definitely not true in the United States; there is a Supreme
>> Court decision saying the exact opposite. The ruling in Google
>> v. Oracle said Google's commercial and business use of Oracle's
>> copyrighted APIs met the test for fair use.
> It is true despite a single US case judgment.
It's not a single US court judgment. The standard for fair use in the
United States was created by a series of Supreme Court judgments starting
with Folsom v. Marsh in 1841 and enshrined in US national law in 17
U.S.C. § 107 in 1976:
Notwithstanding the provisions of sections 106 and 106A, the fair use
of a copyrighted work, including such use by reproduction in copies or
phonorecords or by any other means specified by that section, for
purposes such as criticism, comment, news reporting, teaching
(including multiple copies for classroom use), scholarship, or
research, is not an infringement of copyright. In determining whether
the use made of a work in any particular case is a fair use the
factors to be considered shall include—
(1) the purpose and character of the use, including whether such use
is of a commercial nature or is for nonprofit educational purposes;
(2) the nature of the copyrighted work;
(3) the amount and substantiality of the portion used in relation to
the copyrighted work as a whole; and
(4) the effect of the use upon the potential market for or value of
the copyrighted work.
The fact that a work is unpublished shall not itself bar a finding of
fair use if such finding is made upon consideration of all the above
factors.
You can find this history numerous places on-line, for example:
https://law.marquette.edu/facultyblog/2022/10/the-surprisingly-confused-history-of-fair-use-is-it-a-limit-or-a-defense-or-both/
Many fair use cases in US history have been about commercial use.
Probably most, since companies with commercial uses are more likely to go
through the trouble of lawsuits. Commercial fair use is routine within
the classic examples of fair use, such as parody and quoting for
commentary.
This is the law in the United States. The law in other countries of
course may be quite different. But given that many of the actors who are
relevant to a discussion of large AI models at present have a significant
locus in the United States, US law is going to play a large role.
> No court ruling was ever emitted in favour of Google vs Oracle
> leveraging fair use but it was an agreement between the two parties
> supported by Microsoft.
This is not correct summary of the outcome of Google v. Oracle, nor is it
what the Ars Technica article you liked said. There was no agreement
between the parties in the question before the Supreme Court. The case
went to judgment and the Supreme Court ruled in favor of Google on fair
use grounds, mooting (and not ruling on) the question of copyrightability
of the API definitions.
Appeals like this in the US are generally over a specific question of law
and do not settle the *entire case*, so the Supreme Court then remanded
the case to trial court to dispose of the rest of the lawsuit. I didn't
follow it after that because the details following the Supreme Court
decision are generally uninteresting since they're probably forced by the
decision. It's quite possible that the parties mutually agreed to dismiss
the case after that decision because the decision meant Google was certain
to win. But the Supreme Court decision was not an agreement between
parties.
This is important because in US law if the parties had reached an
agreement before the decision, the case would generally be dismissed and
thus not receive a court judgment and therefore not create precedent.
Google v. Oracle did not settle; it was decided by the Supreme Court and
therefore did create binding precedent for further district court
decisions on similar cases.
> I can reconstruct the interpretation of a law from basic principles
> otherwise it would not be a law but something that appeared from
> nothing: no any law roots, no any law authority.
If this is your approach to legal analysis, I think I will stop here,
since any further discussion along these lines is going to be pointless.
> Moreover, it does not matter how fair use is defined in many different
> legislations around the world. By copyright principle, it cannot allow
> doing activities like {business, commercial, marketing} without the
> consent of the author or of the license.
This is simply not true, and it is very good for free softawre that this
is not true. One is still allowed to do reverse engineering and API
replacement under fair use even if one is doing it for business and
commercial purposes, and lots of free software development is done for
business and commercial purposes.
Re: Brief update about software freedom and artificial intelligence
"Roberto A. Foglietta" writes: > A totally automatic procedure like web crawling and web indexing > re-enter in your example, perfectly. However, the input collection that > a ML/AI training system needs is a protectable work because the data > should be structured, selected and properly labeled even if these > activities are done with rules like it happens using SQL for > databases. Yes, I agree, I think that a trained AI model is a protectable work. However, it is not protectable *by you* unless you're the one who wrote the model and chose its training. Therefore, putting a clause in your copyright license saying that if your work is incorporated into an AI model, that AI model as a collection is covered by some particular license is not really a thing you can do. The best you can do is the standard GPL thing of saying that you don't have to license your collection under any particular license, but if you don't, you don't have any right to include this specific work. Maybe that's what you were getting at, and I just didn't understand. That second approach of course only works if the use of the GPL-covered work is not fair use. If it is fair use, then the person creating the collection can ignore any provision of the license, so we're back to the question of whether AI training is fair use. > So, web indexing and statistics are created over a input collections > that are *not* a creative works and these tools access to every > copyrighted works in fair use as long as they respect the robots:no > meta-tag when it is applied to a copyrighted work. Instead, training a > ML/AI is a completely another story and their input collections are a > protectable collection under the copyright law. I don't think it's anywhere near that easy to distinguish a web search index from an AI training model in copyright law. They seem like very similar cases to me. A great deal of creativity and human control go into selecting how pages are chosen for search indices (otherwise, every search engine would be unusable due to search optimization spam), and search engines even retain and redistribute portions of the documents they index. My guess is that *both* of these are protectable collections. And the entire Internet currently assumes that building a search engine is fair use of the Internet-accessible indexed documents, even if that search engine is then used and marketed for commercial and business purposes, as Google, Bing, etc. all are. If you believe that AI training is *not* fair use, I think you're going to have to wrestle with the substantial similarities between AI training and the Google search engine. I think it may prove challenging to write an analysis that says AI training is not fair use, but Google's search indexing is fair use. Or, I guess, argue that Google's search indexing is also not fair use but falls into some other exception to copyright law like an implicit license, but there I'm *way* out of the depth of my legal understanding. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Brief update about software freedom and artificial intelligence
"Roberto A. Foglietta" writes:
> - fair use cannot include {business, commercial, marketing} rights in
> anyway and in any conditions
This is definitely not true in the United States; there is a Supreme Court
decision saying the exact opposite. The ruling in Google v. Oracle said
Google's commercial and business use of Oracle's copyrighted APIs met the
test for fair use.
You can't reconstruct the law from first principles without looking at the
actual test that is applied by courts. (And as mentioned this may be
different in different jurisdictions, for additional complexity.) In the
US there's a four-part balancing test for fair use, and the analysis can
be quite complicated.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Brief update about software freedom and artificial intelligence
o comply with copyright law with respect to the material included that you hold a copyright on (either satisfying your license or following the rules of fair use), but if you're not involved in creating the collection, you don't get any separate rights over the collection itself and cannot assert a license on it. There's a bunch of US case law on this around things like phone books (IIRC, found to not involve enough creativity to have a separate copyright), recipe collections (copyrightable as a compilation even though recipes themselves are not individually copyrightable), short story collections, and so forth. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Brief update about software freedom and artificial intelligence
Sam Hartman writes: > Russ, I'm sure you are aware, but things get very interesting if the > input to AI training is not fair use. > In particular, if Github copilot is a derivative work of everything fed > to it (including all the copylefted works), that gets kind of awkward > for Microsoft. > Perhaps the Github user agreement grants permission for every copyright > holder who has a Github account. > But for everyone else, things could be very interesting. Yes. I didn't express an opinion on what the correct outcome is because it's not at all obvious to me and I'm not sure that I have an opinion. As a general principle, as a free software advocate, I approve of an expansive definition of fair use and believe that far more uses of copyrighted material should be fair use than are normally considered fair use today. Expansive definitions of fair use are a key legal component to enabling reverse engineering and compatible replacement of non-free software with free software, for example. I'm seeing some tendency for free software advocates who are disturbed by the other social effects of large AI models (and there are quite a few things to be disturbed about), and about the degree to which some of them are parasitic on free software and other free information communities, to respond by advocating for a narrow definition of fair use, at least in this specific area. I'm worried that this is counterproductive; I think we rely on fair use much more than incredibly wealthy multinational software corporations do. But the specific ramifications of an expansive fair use position for the societal effect of AI models isn't clear to me, and to be honest I'm dubious that it's clear to anyone at this point. There are obviously some significant risks, including the tendency of scale effects with large models to further consolidate power into the hands of a small number of very wealthy organizations. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Brief update about software freedom and artificial intelligence
Gerardo Ballabio writes: > As I understand, that is an open legal question. The Affero GPL would be > such a license *if* the training dataset would be considered part of the > code. While that does seem to make sense, as AI code is essentially > non-functional without the training, I am not aware that there has ever > been a pronouncement by a court of law that affirms or denies it, nor I > am aware of any free/open source license that contains language that > deals specifically with that issue, and I'm pretty sure that there's lot > of room for lawyers to argue their point. To add to this, I'm fairly sure that the companies that are training AI models on, say, every piece of text they can find on the Internet, or all public GitHub repositories, are going to explicitly argue that doing so is fair use of the training material. If that argument prevails in court, or in legislatures, it will not be possible to write a free software license to prevent this, since the point of fair use is that copyright law does not apply to that usage and therefore no copyright license can prohibit it. I don't think we have any idea yet whether that argument will prevail. It will probably be years before it reaches a high enough level court in the United States for a definitive ruling, let alone every other relevant country that will have its own legal judgments. Consider Google v. Oracle: a suitable case with litigants willing to appeal all the way to the highest court about the copyright status of library APIs was only filed in 2015, years after this became a common issue, and it took six years for it to be decided, and that only in the United States. I would expect a similar delay. Court systems work very slowly. It's also entirely possible that court judgments will go different ways in different countries to add even more confusion. The organizations that have every incentive to argue that it's fair use have very deep pockets, so they have a substantial chance of success on the prosaic grounds that the best-funded litigant or lobbyist always stands a reasonable chance of winning. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Insanely frustrating finding older distributions
Daemon Bernstein writes: > Also, there are NO Nvidia drivers for my old video card on those newer > distributions, and older drivers will not install. Just as a side note, we're not very happy about this situation either, but because the drivers are non-free and NVIDIA doesn't keep supporting them, there's not a lot we can do about it. They constantly drop support for newer cards and don't port older drivers to newer kernels or X servers, and thus force this endless upgrade treadmill. We would have to keep around old Linux kernels and old X servers in order to keep the old drivers working, and that has too many tentacles and other problems (not to mention the lack of security support for the older software). I now avoid buying any products from NVIDIA if I can possibly avoid it, in large part because of this. That of course doesn't help if you already own them, sadly. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Evolving away from source package realms
Thomas Goirand writes: > I really would hate having 2 sets of uploading DDs. One with the > archive-wide privilege, and the one without. Then you'd need to ask for > that right, and potentially have to explain why you need it. This is a > terrible idea, with not enough justification (IMO). This is probably my security brain from my day job, but I would prefer to be able to drop permissions that I'm not currently using, as long as I can get them back easily. It reduces the blast radius of mistakes and compromises. I think we're arriving, from different directions, at the importance of "get them back easily." But I think there's some merit for being able to restrict and expand your own permissions even if it is entirely automated via, say, a signed email to a control address. Those sorts of speedbumps in the way of mistakes or compromise are sometimes unappreciated on the grounds that an attacker can just expand their permissions after a compromise, but from a security standpoint there is *some* value in each additional thing the attacker has to figure out how to do and each additional detectable interaction they have with the system, as long as it doesn't add pain for the legitimate user. That might be a useful reframing of the idea: let those of us who would like to (possibly temporarily) voluntarily restrict the scope of our upload access have a way to do that, without implying that people who want archive-wide upload rights need to change anything. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Evolving away from source package realms
Tobias Frost writes: > On Wed, Oct 12, 2022 at 04:09:54PM -0700, Russ Allbery wrote: >> Is there some way right now for me to say "any Debian contributor with >> upload rights should feel free to merge changes and upload this package >> without needing to consult me at all, and I will subscribe to the >> packages feed for the package and say something if something happens >> that I don't like" with a packaging repository on Salsa? And if not, >> would that be a good way to start? > In my understanding this is exactly the purpose of the Debian group on salsa. > As [1] says: > Direct commits to repositories in the Debian group by any Debian > developer are implicitly welcome. No pre-commit coordination > (e.g. merge-request or mail) is expected. > [1] > https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group What I'm missing, and maybe this is just me not understanding, is the uploads part. Does that also imply that anyone can just upload? (And what about the minor protocol parts of that, such as what to put into Maintainer and Uploaders?) But I was wondering if this was what the Salsa Debian group was supposed to be and we just haven't really used it very much (possibly because there aren't that many volunteers to upload random packages?). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Evolving away from source package realms
Pierre-Elliott Bécue writes: > I really think it's not the matter, to me the matter is package > ownership. While new contributors should feel that it's mandatory to > discuss with maintainers, having people clamped so tightly to their > packages that you don't know if these are actually packages or > src:THE_ring is the issue to me. I think a possible path forward is to provide a way for people to explicitly opt out of package ownership and then see how much that movement grows. We've done various iterations of that in the past (the Debian group on Salsa, the low-threshold NMU registration), but I feel like Git plus Salsa provide useful tools to take this several steps farther that we don't (so far as I know) have a clear way to opt in to. In part because there are a few possible policies and it's not clear which one we should pick. Is there some way right now for me to say "any Debian contributor with upload rights should feel free to merge changes and upload this package without needing to consult me at all, and I will subscribe to the packages feed for the package and say something if something happens that I don't like" with a packaging repository on Salsa? And if not, would that be a good way to start? Most of the language-specific teams essentially already implement this for their packages and their team members, I think. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: long-standing bugs and tar pits
"G. Branden Robinson" writes: > That said, such people define "constructively" in an odd way, as can be > seen above; they assert that the only way they experience respect is to > be _obeyed_. They claim that they are treated as second-class citizens > because they are not deferred to like monarchs--or dictators. I advise > people to be watchful for this pattern because you can be sucked into an > energy-sapping dynamic that reduces your channel capacity as a volunteer > and dilutes your enjoyment of (what should be) a collaborative > environment. Yes, this. After my message clearly hit a nerve, I went back and reviewed the debian-user threads that started this out of curiosity, and I see that it had already reached the point of Chuck expressing his suspicions that we're maliciously sabotaging Debian for our employers by not fixing bugs (!!) [1]. I'm not seeing a glorious collaborative future here. It's okay, and even desirable, to give a chilly reception to people who approach free software projects with this level of persistent entitlement. These folks are usually negative effort: the amount of annoyance and disruption that they cause exceeds the value their technical contributions could add. The ones who are willing to learn and change their behavior will figure out why no one is willing to help them and try a different approach. Free software projects are uniquely vulnerable to people who attempt to manipulate you by making you feel like a failure for not having addressed their specific problem. Avoiding that emotional trap is an important part of healthy boundary setting and sustainability. Debian is something we build together, voluntarily and consensually. When someone needs a break, other people carry the load, or sometimes we put the whole thing down and rest for a bit. We don't berate each other for not working harder. [1] https://lists.debian.org/debian-user/2022/09/msg00267.html https://lists.debian.org/debian-user/2022/09/msg00297.html -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Are users of Debian software members of the Debian community?
Chuck Zmudzinski writes: > To put it in the most brief terms, I come to that conclusion based on > what many people are telling me: Debian maintainers cannot fix bugs in > software because they are just volunteers. That explains why I almost > always am at least annoyed by one or two bugs when running Debian > software, and sometimes after an update the computer is totally unusable > until I can debug it and find the fix, because volunteers don't have the > time to do it for me. That is what most everyone on debian-user is > telling me. Do you disagree with what they say? > Also, in my experience, these bugs and catastrophic failures caused by > updates of a supposedly stable release happened *much* less often when I > used software that is written by paid developers. So let's see if I've got this right. You don't like Debian's governance structure or its constitution. You don't like that it's a volunteer project. You think the software is lower-quality than software maintained by paid developers. It has a bunch of bugs that annoy you that you don't think you can get fixed. And you don't feel welcome in the community. You... do realize that you can just not use Debian, right? It's okay to use another Linux distribution that suits you better! This is an entirely consensual relationship! We won't make you use Debian, I promise! I'm all for sticking around and trying to fix things that you think are broken, but these aren't some minor disagreements. These are some really foundational mismatches. You seem to like Debian except for... literally everything about how the project is organized and run. There are a lot of other Linux distributions out there with different philosophies and different organizations, and it's not some sort of betrayal to go look at a different one. No one wants you to be unhappy and frustrated, including everyone involved in Debian! You could, for example, go give Red Hat money and then get that higher quality software from paid developers that you want. They'll give you a support contract and you can tell them what bugs you want fixed, and they'll give you a quote, and you can give them money, and they'll fix the bugs that you want fixed, and you can stop investing all this time and effort in writing extremely long mail mesages to volunteers to convince them that volunteering is bad, actually. Or maybe the problem is that you want to be able to tell people what to do, but you don't want to have to pay them? If so, uh, good luck with that! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Are users of Debian software members of the Debian community?
Chuck Zmudzinski writes: > The theory behind my proposal is that there is a diversity of viewpoints > that stems from a diversity of roles within the project. If the voting > members are restricted only to the contributors who volunteer for the > role of developer, then the full diversity of the Debian community is > not reflected in a vote that only comes from the pool of formal > developers. I think it depends a lot what the viewpoints are being diverse *over*. If you've formed a group of people to go pick up litter, it's not helpful to have a diversity of opinions about whether or not litter should be picked up. That is just silly. And, somewhat more on point, it's not helpful to have a bunch of members who have no intention of going out on the street and picking up litter, but who have strong opinions about how other people should do so. This is not useful diversity. There are numerous Linux distributions with different viewpoints about how to make a Linux distribution. That's diversity, real diversity, in terms of distribution goals and structure. It's the kind of diversity that involves completely independent organizations making completely independent decisions with different financial structures, different founding principles, and so forth. As a Linux user, you can explore that diversity by picking and choosing which distributions you install and use. Within any given project, including Debian, we're all trying to do something together, which inherently requires some amount of agreement and consensus. At some level, this is the opposite of a diversity of opinion. We have to roughly agree on a course of action, at least at some level and with some rough, in order to make forward progress. One of the things that's helpful to avoid endless decision paralysis, or to avoid a bunch of people who are not in a position to do the work voting for things the people who are doing the work don't want to do, is that we ask everyone who is voting on major decisions to have significant skin in the game. The implicit assumption behind GR voting is that to some extent you're then going to go help implement what we all voted for, because we're the only people who can. The voters are the same group as the implementors. We're using voting to help guide consensus among the same group that has to do the work. If no one does the work, the GR is useless and pointless and there's no reason to have held it. That tends to significantly inform our voting. It's something that I think about with every GR. To make that concrete, you can hold as many GRs as you would like saying that every bug in Debian with a tested patch should be applied and uploaded, and it will accomplish precisely nothing. Changing who votes on such GRs is useless; the whole theoretical model behind such a vote is wrong. Work happens in Debian because someone does it. Voting doesn't change that; what changes that is more people doing work. If you think a package is being neglected by its maintainer, we have processes for that, but they mostlly require that you, the person who wants to make a change, step up and be the maintainer. If no one is willing to step up and be the maintainer, the package will continue to be neglected. Voting is not a magic spell. > Michael Stone followed me to this list and condemned for me asking > questions here on this list. There is no way *he* considers me a member > of the Debian community who has a formal voice as a Debian user. This is Michael thinking you're being annoying and wasting people's time and telling you so, while warning other people who don't follow debian-user that arguing with you may be futile. It has nothing to do with whether or not he considers you a member of a community. I can assure you that he'd say the same thing to a DPL if he thought they were being annoying and futile to argue with. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: How do you manage debian mails on your mailbox?
Antoine Beaupré writes:
> For example, to reply to your email, I didn't use GNUS, because then
> outgoing mail doesn't properly gets filed (haven't figured out *that*
> part just yet in GNUS I guess): instead it goes into a
> `nnfolder+archive:sent.2021-03` ... thing (group? folder?). Heck, I
> don't even know where that is actually stored. ;)
It's a file in your ~/Mail directory in regular mailbox format, IIRC.
You can configure where you want outgoing mail to go, and you can even
make it change depending on what group you're in when you send the mail,
but it's a little fiddly. I personally like having all my sent mail
stored separately in dated folders, so I use this configuration, which
stores Usenet messages in a separate set of folders than email messages
(this also has a bunch of other settings, since other things are all
configured through the same gnus-posting-styles variable):
(setq gnus-posting-styles
'(("."
(address "ea...@eyrie.org")
(name "Russ Allbery")
(organization "The Eyrie")
(signature-file "~/docs/sigs/eyrie")
(eval
(setq gnus-message-archive-group (rra-archive-group "mail"
((message-news-p)
(eval
(setq gnus-message-archive-group (rra-archive-group "news"
((or (string-match "^nnml:lists\\.debian\\." gnus-newsgroup-name)
(string-match "^nnml:project\\.debian" gnus-newsgroup-name)
(string-match "^nnml:lists\\.announce\\.debian"
gnus-newsgroup-name)
(string-match "^nndoc\\+bug-ephemeral:" gnus-newsgroup-name))
(address "r...@debian.org")
(signature-file "~/docs/sigs/debian"
Each matching block is run in sequence, so later blocks override earlier
ones. You can see where I could have put in a rule to put my sent Debian
messages elsewhere, and I could also have set the archive group to the
current group if I wanted.
rra-archive-group is this small function, which just handles setting up
the dated groups:
;; Used to generate the name of archive groups in the nnml hierarchy.
(defun rra-archive-group (base)
"Given a base string, returns a dated archive group name."
(concat "sent." base ".unfiled." (format-time-string "%Y-%m")))
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: How do you manage debian mails on your mailbox?
Nilesh Patra writes:
> So, two questions:-
> - Do you use your primary email address for debian stuff as well,
> or is it a different one?
My work mail goes to a separate inbox and a whole separate email system
(which I have never bothered to set up protocol access to and just read
via webmail, since my job doesn't use email very heavily). Other than
that, all email I receive for anything in my life, including Debian, goes
into a single inbox.
> - Do you have any sensible way to cope up with so many mails from
> different mailing lists and not potentially miss out on something
> important?
I've been using Gnus inside Emacs as my mail reader since, good lord,
1994, and one of the things that it supports is what it calls "split
rules." Gnus started life as a Usenet newsreader (which is part of what I
love about it), and therefore thinks about the world in terms of
newsgroups. This is very similar to but not entirely equivalent to the
typical email folder concept, and one of the ways in which it's different
is that Gnus (when using the nnml backend rather than something like IMAP)
does a preprocessing step on incoming email and sorts it into the
appropriate group first. This is basically equivalent to filter rules in
a typical email client except they're strongly emphasized in Gnus and (at
least in my opinion) the tools for managing them are superior. It's very
similar to the way procmail works, but uses elisp as the configuration
syntax.
So I have a set of split rules that sort mail out into various folders
that, because I'm an old Usenet person, are named sort of like newsgroups,
some before spam filtering (I'm still using bogofilter, which still mostly
works) and some after spam filtering. So, for example, I'm responding to
this message in what appears in my email client to be a "group" named
lists.debian.project. Your message was sorted into that group by the
following line in my split rule configuration:
("list-id" "debian-project\\.lists\\.debian" "lists.debian.project")
If someone were to send me direct email to my regular email address, that
would show up in a group called mail.personal. But if they send direct
mail to my Debian address, that shows up in a group called project.debian
due to the following split rule:
(to "rra@\\([a-z0-9-]*\\.\\)?debian\\.org" "project.debian")
However, before that rule are a few other rules that take precedence and
sort a few specific types of mail into different folders because I handle
them differently:
("x-loop" "owner@bugs\\.debian\\.org" "project.debian.bugs")
("x-mailer" "reportbug" "project.debian.bugs")
("from" "nore...@release.debian.org" "project.debian.packages")
("x-debian" "dak" "project.debian.packages")
("x-pts-package" ".*" "project.debian.packages")
("x-testing-watch-package" ".*" "project.debian.packages")
This allows me to maintain mental context when reading each "group,"
choose not to read things that are lower priority until later, and see
more important mail first because I split it out into higher-urgency
groups.
I have about 500 lines of split rules, but that's accumulated over nearly
30 years of using this way of reading email. I update them regularly and
I'm in the middle of changing my mind about how granular I want the split
rules to be and consolidating more things into a smaller number of groups,
but they don't require much work to maintain. I have a group that's
designed to catch mail from mailing lists that I subscribed to but didn't
add a split rule for, and I go through and add split rules for those
messages, or things that show up in my personal inbox that I don't want
there, from time to time. For example, right now I have about five
messages from order notifications for takeout from local restaurants that
are sitting in my inbox waiting for me to have five minutes to write split
rules so that they sort into mail.food instead.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: We need to define a path for Debian to climate neutrality
Davide Prina writes: > So, I think that if Debian must think about climate change, probably it > must be focused on energy efficiency to gain more results. I agree that energy efficiency is probably the place where we could most directly contribute as a project while focusing on the things that we're all good at. (I'm not discounting also talking about how we manage conferences and travel, but that's more "we exist in the world" territory rather than the core focus of the project.) A somewhat tedious and not-sexy but possibly effective place that we could focus is on ensuring modern power management features are correctly enabled and working properly in Debian installations out of the box. My understanding is that Linux has gained quite a few facilities for reducing power consumption, not all of them are automatic, and there are some complex interactions with other system components such as the desktop environment. There may be some low-hanging fruit here that would help Debian consume less power by default, or places where there is no one right decision but we could provide a low-power option to users who want it. This also has the advantage that, whether or not the specific framing of this thread is inspiring to a given Debian contributor, everyone wants longer laptop battery life and lower power bills for their data centers. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: A quiet reminder: please be considerate.
Brian Thompson writes: > The biggest problem of moderating troll posts is that the definition of > trolling varies broadly across individuals. Agreed, and the moderation of debian-project is very sensitive to that. We're addressing this by erring on the side of approval and only rejecting the messages where there's essentially unanimous agreement. In practice, this has only been spam (95% of what's been rejected), direct and obvious personal attacks along the lines of the reason why we put the moderation in place originally, and a very small handful of messages that were so incoherent and off-topic that we couldn't make heads or tails of them (and were probably actually spam). This is all done somewhat ad hoc since we don't have moderation software that lets us implement this more mechanically, but in practice it seems to have worked. I have also checked all messages to the moderation queue since March 11th and can't find any messages from Norbert, so whatever is going on there seems to be happening upstream of moderation. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: (Lack of) GDPR compliance in Debian
Jonathan Carter writes: > It's not 100% clear to me, but from what I understand having had some > informal conversations with experts in this field (we should ideally > speak get some more information from legal experts on this topic), it > would fall on individual members, unless a TO has en explicit contract > with someone. This is also my understanding from other open source governance work I've done on other projects. Unless the organization is incorporated, I think the liability falls on the individuals. Even if it is incorporated, it's fairly standard to carry directors and officers liability insurance because they can still be potentially held personally liable. (If you do open source work outside of the auspices of an organization that carries insurance and you have assets to protect, it's worth considering a personal umbrella policy.) My understanding of US business law is that most lawyers would tell us that what we're doing is ill-advised from a legal standpoint because we may accidentally form a general partnership. You essentially never want to have a general partnership because the members of the partnership have unlimited liability for the actions of the partnership (basically, each individual can be liable for anything the other individuals do as part of the partnership). I'm not sure how large that risk is to Debian in particular since we don't engage in commerce and therefore may not fall under commercial business rules, but it's not a situation one wants to come close to. > It's one of a few important reasons why we need to look at incorporating > Debian, I wanted to push for that during the last year, but during the > release and the last 1.5 GRs didn't seem like an ideal time for it. I'll > also provide some more details and thoughts on this on -vote over the > next week, but I believe this is something important to pursue for the > project regardless of who serves as DPL for the next term. I agree. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Discussion idea for how DAM/CT/etc. could work
s probably the hardest part of this. Anyway, I am *not* proposing that we adopt this system. I'm sure it's full of other problems I haven't seen. I'm just hoping that this makes all of my ramblings a bit more concrete and lets other people understand the sort of model I have in my head. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Questions around Justice and Our Current CoC procedures
Felix Lechner writes: > Your statement is the opposite of what I felt. In fact, I asked for the > circumstances to be published on debian-private. It was calming to me, > so your interpretation is not correct. Thank you for the correction! I'm sorry for having misunderstood you. You'd made other statements about how you received that warning that I have apparently misinterpreted. > Finally to my original point, I believe that your conclusions contradict > mine so frequently because you overlaid your opinion onto mine, i.e > projected your perception onto mine. It's certainly possible. I find it very difficult to understand where you're coming from, and the only way I have of understanding other people is through empathy, so I do continue to try to map your reactions to a model that I can understand in order to try to understand your point. Regardless, my intent in this conversation is not to talk about your warning specifically. That was something you brought up in this discussion, and I don't feel like this is the place to talk about it nor is it something I want to dig into. I'm trying to make a general point about the impact of the current process, which I think still applies even if it wasn't relevant in your specific case. It sounds like you may disagree with my opinion about the process. Great! That's part of the discussion. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Questions around Justice and Our Current CoC procedures
Felix Lechner writes: > On Mon, Feb 21, 2022 at 9:38 AM Enrico Zini wrote: >> Then you need to start taking responsibility for creating conflict when >> there was none, which is sadly something I see as a recurring pattern >> in the way you participate in Debian interactions. >> Is this something you'd acknowledge and would be willing to work on? > This, too, is a projection. > I did not address Steve. He wrote to me. I don't think that's what Enrico is talking about. I think he's talking about the way that you attacked me in response to a message in which I was expressing support and sympathy for your position, based on a misunderstanding of my message and what looked to me like an assumption of bad faith. This is also not the first time that you've done this to both me and others, you have never apologized, and you seem to be intent on continuing to do that with me and others at random intervals instead of extending a presumption of good faith and trying to find a non-hostile reading of other people's words. My phrasing doubtless could have been better or clearer. It always can be. But you can ask questions rather than making assumptions! When you do this and then, a few messages later, talk about how you think Debian should have a warm and inclusive culture of compromise, it's quite frustrating and confusing. If your goal is to create a warm and inclusive culture, please start by not assuming other people are trying to attack you. Right now, you are doing exactly what Enrico described: creating conflict where there was none. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Questions around Justice and Our Current CoC procedures
Marc Haber writes: > But please don't forget that a person vanishing from a heated discussion > just in a whim creates the feeling of victory in the orht discussion > parties. > And I KNOW what I would do as participant of a heated discussion after > receiving a DAM warning. I think the way you've framed this captures a lot of what we're struggling with right now. Why is victory a desired outcome in discussions? Why is victory something we're trying to prevent other people from feeling? (And this is not just you, to be clear; I completely recognize the feeling that you're describing.) How have we managed to make vanishing from a heated discussion a bad thing? Shouldn't it be good to back away from something that's too heated and let it calm down? Part of the problem you're getting at, I think, is that we feel like we've lost the capacity for constructive discussion in some areas, and the options are either to win a heated discussion or to vanish. This is a very bad place to be. That's a sign of an unhealthy community and an unhealthy project, and Debian is not going to survive if that's where we stay. My goal is to have non-heated discussions and a clear decision-making process. If *everyone* stepped away from heated discussions, the heated discussions would end, and that would be great. What I think you're identifying is the worry that one side is going to "win" by default, and to me the answer to that is to end the heated discussion, but not the *discussion*. To ensure there is some explicit decision point that you will not miss by leaving the uncomfortable and draining discussion that has gotten too heated. There are some decisions (although I hope not very many!) where we have a fundamental disagreement over the path forward and still have to decide, and some group is going to feel like the project is going in the wrong direction. We should try to minimize those, but they exist. But that still doesn't mean we need to have a heated discussion. We can identify the core points of disagreement, try to narrow them down as much as possible, and resort to a vote. That's why I care so much about GR process; it gives us a way to make a decision that doesn't involve one group of people yelling down another group of people until they achieve some sort of victory. I think those victories are pyrrhic. Sometimes I'm going to be in the minority in the project on something that matters to me and I'll have to decide whether to live with that or whether that means Debian is no longer aligned with my goals. That's hard to deal with, but at least if it comes in the form of a clear vote, I'll have concrete facts to work with. It can't come in the form of people willing mailing list arguments by attrition, since then I'll never be convinced that I really was in the minority as opposed to just being unwilling to shout loud enough. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Questions around Justice and Our Current CoC procedures
Scott Kitterman writes: > The reason it feels like a threat of expulsion is precisely because it > is a threat of expulsion. The minimal possible solution to people > feeling threatened would be to not threaten them. That may not be > enough, but that would be a first step. Focusing on the feeling shifts > the blame and buries the lede. It's a balance, because if people would always course-correct without being told they have to with someone with perceived authority, we would not be having this discussion because it wouldn't be necessary. I get the impression you think I'm hair-splitting, any communication from DAM is inherently a threat, and we should just accept that. I think it's true that any formal communication from someone who can kick people out of the project has some level of implied consequences, but I don't think it's true that we can't fine-tune the implication. I think it matters a lot whether it's public or private, for example, and whether we explicitly raise expulsion or not. That said, it is entirely possible that I am being far too optimistic about the number of people who are willing to ignore peer feedback but are willing to substantially change their behavior when they get DAM feedback. Maybe the people who are unwilling to accept feedback unless it comes from someone in perceived authority are already too harmful to the project to try to spend more time and energy on, and a direct warning of expulsion *is* the right way to go about it. I hope that isn't the case, but I admit that it's very worrisome when people won't hear peer feedback and I admit I personally don't want to spend a lot of time working with aggressively confrontational and draining people in the hope that they'll change. Regardless, though, I really do not like that we've backed ourselves into a corner that involves public shaming (even if it's not intended to be that) as part of the process. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Questions around Justice and Our Current CoC procedures
Felix Lechner writes: > On Sun, Feb 20, 2022 at 10:43 PM Russ Allbery wrote: >> Or, let me put this another way: one of the fears that I've seen >> expressed around warnings is that it's a permanent record sort of >> thing, or it starts a file on someone, or otherwise creates a >> presumption of future bad behavior. [...] This bothers me a lot. I >> think this perception is very harmful to the project because it creates >> excessive shame and anger and fear, which can be quite >> counterproductive in attempting to just get someone to shift their >> behavior. > Okay, so now you are saying I am being "very harmful to the project > because [my perception] creates excessive shame and anger and fear"? That is precisely the opposite of what I meant. What I'm trying to express is that the warning *entirely reasonably* made you feel shamed and attacked for a number of reasons, including the fact that it was public, and that making you feel that way was unnecessary and probably counterproductive. In other words, I think your reactions were understandable and are evidence that the warning system is not working the way that I think that it should because it doesn't provide enough psychological space for people to understand it as I think it should be intended. And to be clear I think this is a problem with the tools that we have available and the process we're currently using, not with how people are trying to use the imperfect tools that we have. > Your statement is plainly contradicted by the DAM warning I received. > It included this line: > If you continue resorting to personal insults when you interact with > other people, the DAMs will have no choice but to review your > membership in the project. > Upon receipt, it was reasonable for me to express, in your words, my > "fears [...] around warnings [...] that it's a permanent record sort > of thing, or it starts a file on someone, or otherwise creates a > presumption of future bad behavior." Exactly. This is why I do not like the way that we are currently doing warnings. The first step by a team that is serious enough to not be ignored already feels like a threat of expulsion. I think we're starting with too large of a hammer because we don't have the right tools to try to course-correct earlier in a way that doesn't make people feel publicly attacked, and the announcement of the warning to the project (an entirely well-intentioned process that grew out of trying to solve a different problem) makes people quite reasonably feel like they're being publicly shamed. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Questions around Justice and Our Current CoC procedures
Scott Kitterman writes: > I think that makes sense, but I think it's really pretty much the same > thing. The "perceived authority" that means people treat feedback from > DAM differently is the authority to suspend or expell. Ultimately and > unavoidably, a DAM warning comes with an undercurrent of that authority. I agree with this to an extent, but it sounded in your previous message like you felt that threat was quite strong, and therefore wanted a slow and careful process before even warning someone. This is the part that worries me. I'm worried that being too slow about warnings creates exactly the problems that the project is trying to avoid. If everything is formal and slow, that means we end up with much-delayed, very strong actions on situations that have had time to fester and escalate, which increases the chances of highly divisive membership decisions. I want a faster and more responsive process to give people effective warnings *before* things escalate and fester in the hope that this will mean fewer escalations to having to take membership actions. Yes, the fact that the DAM is also responsible for expelling developers when necessary is the reason why they can't be ignored and therefore the reason why in some cases the warning is effective, but it's still possible for a warning to only be a warning. Specifically, I want a warning that does *not* imply the sort of "three strikes and you're out" escalation path that you referred to in your message and which is indeed common in US employment situations. I do think there's a place in the project for a warning from some sort of trusted authority that is not perceived as a deferred expulsion, but is something that still clearly should not be ignored. Or, let me put this another way: one of the fears that I've seen expressed around warnings is that it's a permanent record sort of thing, or it starts a file on someone, or otherwise creates a presumption of future bad behavior. I think this comes directly from the sort of HR warning in an employment situation that you mention. This bothers me a lot. I think this perception is very harmful to the project because it creates excessive shame and anger and fear, which can be quite counterproductive in attempting to just get someone to shift their behavior. The ideal outcome in my mind for a warning is that the person warned doesn't do that thing again, and then *everyone forgets it ever happened*, at least in any formal sense. In other words, I want to extend grace and forgiveness to people, something that HR processes very much do NOT do. To do that, we need a warning that's just a warning, where nothing further will be said about it if the warning is received and understood. BTW, also on that front, I think that announcing DAM warnings to the project is a serious mistake. I understand the thought process that went into that decision, but I really don't agree with it. The effect is to make someone feel attacked and shamed publicly, which directly interferes with the goal of a warning. It's also one of the major factors in making people feel like warnings are some sort of permanent black mark against them, which I strongly do not want to be the case. To be clear, it's possible what I'm asking for is something less than a warning and to reserve warnings for essentially formal reprimand or censure. In other words, maybe the current DAM warning concept is worth keeping in some form, and we just need some new thing. > Ultimately Debian would be a better place if we were more open to > listening to each other. I completely agree. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Questions around Justice and Our Current CoC procedures
Scott Kitterman writes: > On Sunday, February 20, 2022 10:13:03 PM EST Russ Allbery wrote: >> I guess the other possibility is that people really want warnings to be >> way more serious than any meaning I personally would ascribe to the >> word "warning" and are thinking of them as formal project censure or >> something akin to that. In that case, my argument is that we need a >> warning that's actually just a warning, and the thing we've got is much >> too strong and the real problem is that we don't have something lighter >> touch. > Currently a DAM warning is a suspension/expulsion with deferred > execution. We have wildly different understandings of what a DAM warning is. Which clearly points to a problem that needs to be solved! > I think every non-government job I've had had a discipline process that > went: > 1. Verbal warning. > 2. Written warning. > 3. You're fired. > No, Debian isn't an employer, but I think the sense that DAM warnings > are used is similar. That seems like a mistake to me. Anything that makes Debian seem more like an employer seems like a mistake to me. We just aren't; we're a voluntary association that doesn't have any of the same requirements and does not have the employees or facilities to have the same type of formal process. We should actively avoid creating spurious parallels to employment processes that we are not following, going to follow, or are capable of following. > I agree with the idea that more feedback with a lighter touch would be a > good idea, but I think anything with a lighter touch doesn't need DAM to > do it. We are all empowered to provide other developers feedback when > we see concerning behavior. People just need to do it. It doesn't take > any new rules. We do need DAM to do it sometimes because sometimes people refuse to change their behavior unless someone with perceived authority tells them they need to. Otherwise, they just counter-attack and escalate with the person who tried to give them feedback. I'm not calling out anyone specific here. I truly don't have anyone specific in mind. This is just standard human stuff; in any sufficiently large group of people, and Debian is more than large enough, there are going to be a few people like that. It would be nice if peer feedback were always sufficient, but this isn't how humans work. Given that, and given that we clearly don't want to boot everyone who does that (even apart from the fact that the project is loathe to boot anyone for almost any reason, sometimes people really do change behavior once someone they can't just ignore points out the rules of the community), some sort of ability for someone with perceived authority to give a warning that's actually just a warning, not an "expulsion with deferred execution," is useful. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Questions around Justice and Our Current CoC procedures
Sam Hartman writes: > Figuring out how to accomplish requesting a statement is a little > tricky, but I think it is worth the effort. DAM takes membership > actions (including warnings) by consensus. It's fairly difficult to get > all the members of DAM together. > I don't think it would work in practice for the request for a statement > to be a consensus action and to be followed shortly there after by > another consensus action to take a decision and to write it up. That > would require DAM to get together as a group twice in short succession; > given how hard it is to schedule DAM action, that would not work. I think Debian is in danger of a degenerative spiral, both here and in other places. We make fewer and fewer decisions, slower and slower, which raises the cost of reversing a bad decision because it requires a second decision, which will also be slow. This raises the stakes of each decision, so they have to be made more carefully. This makes the decision take more effort, and thus we make even fewer decisions, and those decisions then carry even more weight. That in turn leads people to want them to be made even more carefully, and the spiral continues until we talk endlessly and make no decisions at all. We need a careful and slow process for kicking someone out of the project because that's a big deal. Having a careful and slow process for issuing a warning is faintly absurd, and I think we've only arrived at that state because it's so hard to decide to ever do anything that they've reached an unrealistic level of apparent importance. I think the solution in many, many places across Debian is to make more decisions, faster, and allow some of them to be wrong. Lower the stakes and consequences of a bad decision, and lower the perceived weight of a single decision, rather than trying to make every decision perfect. Anyway, to be more concrete, what your description of the process says to me is that ideally DAM would be much larger and would deal with more minor things, such as warnings, in panels. Have a rotating "on call" or something similar, empower them to make decisions on anything that comes up while they're on call, and if someone thinks their decision is profoundly unfair (I still think people are making far too much out of warnings), or if some more serious issue comes up, it can be reviewed by a different panel, a larger panel, or by DAM as a whole, but that would be rarer. Having more people empowered to make decisions faster would also lower the perceived significance of each decision, since there's going to be some minor human inconsistency and I think that's actually healthy. The goal of warnings is not to precisely measure and describe exactly what someone did wrong to some nonexistent objective standard. It's to say "hey, this is making things shitty for other people, you need to knock it off." People can grumble about that all they want; the grumbling doesn't require a response. If they think twice about doing the thing that was making things shitty for other people, mission accomplished. If it turns out that what they were doing was fine in context, great! It was a warning; no one did anything. If that was the first warning someone got for something they didn't actually do, they've led a way more sheltered life than I have, and my life has been pretty sheltered. I dunno, I realize I may be being too cavalier here, but see the point above about making more decisions, faster, and accepting a few mistakes. If we end up with a rash of bogus warnings, we can reconsider. But right now warnings are about as frequent as Papal encyclicals, and I think partly as a result people have gotten really weird ideas about them. I guess the other possibility is that people really want warnings to be way more serious than any meaning I personally would ascribe to the word "warning" and are thinking of them as formal project censure or something akin to that. In that case, my argument is that we need a warning that's actually just a warning, and the thing we've got is much too strong and the real problem is that we don't have something lighter touch. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: New DEP: Usage of SDPX in debian/copyright
Jonas Smedegaard writes: > Are we discussing one (or more) of those topics here or at d-devel, or > both?!? Sorry, I for some reason thought the DEP discussion was moving here and had it stuck in my head that debian-project was where DEPs are discussed. I'll discuss this in debian-devel instead. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: New DEP: Usage of SDPX in debian/copyright
Jonas Smedegaard writes: > Quoting Stephan Lachnit (2022-02-08 16:02:20) >> I would like to request to take the next available DEP number (17 as of >> today). It is about using the SPDX specification as an alternative to >> the machine-readable debian/copyright (previously DEP-5). An initial >> discussion was started on debian-devel [1], and since there have been >> no large objections I would like to formalize it. > Sorry that I initially missed it - I have now shared my objection to the > idea at that thread: > https://lists.debian.org/164433477648.2636895.1692225734052...@auryn.jones.dk The point, as I understand it, of the SPDX specification is to be even more machine-readable, which implies to me that we could generate the current debian/copyright format from it, and possibly vice versa. I think the best way to move forward with compatibility with SPDX may be to improve our side so that we can consume that format and capture all of the same information (think JSON and YAML interoperability), which would allow us to use tools from their ecosystem while still producing the same output files that people are used to today. This is a hindsight is 20/20 sort of thing, and I was among the people who resisted doing the right thing at the time (mea culpa), but we kind of shot ourselves in the foot with the current debian/copyright format. No one uses our RFC-2822-style thing except us, and no one has tools for it, so people are understandably quite reluctant to adopt it. In hindsight, it really should have been (a restricted subset of) YAML or something else that everyone else knows how to use; if it had been, I'm not sure we'd be in a situation where the rest of the industry is going in a different direction. But that's where we're at, and I think we're at significant risk of ending up in a dead end and thus not being able to take advantage of a ton of licensing work that's being done upstream but is in a format that we don't use, requiring us to tediously recreate that work instead. My goal in this discussion is to avoid that. I don't really care that much about what the canonical output format is because, if done properly, I think we should be able to generate multiple output formats from the same data with minimum effort. My hope is that we can reuse standard data in a format that upstreams will start supplying, thus reducing the amount of Debian-specific work we need to do. To make that concrete, I want to ship structured copyright and license information with all of my upstream packages. I'm currently doing that in Debian's format, but Debian's format is not useful to anyone other than Debian. I plan on switching to SPDX or REUSE or something similar because then someone else has a hope of being able to consume that data. The thought of then having to do additional work when packaging to cater to Debian is very unappealing; I want to be able to fully automate generating the debian/copyright file from the data that I'm already maintaining upstream. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: New DEP: Usage of SDPX in debian/copyright
Stephan Lachnit writes: > I would like to request to take the next available DEP number (17 as of > today). It is about using the SPDX specification as an alternative to > the machine-readable debian/copyright (previously DEP-5). An initial > discussion was started on debian-devel [1], and since there have been no > large objections I would like to formalize it. Thank you very much for working on this! I've been looking at adopting this for all the packages for which I'm upstream, and really appreciate other people also looking at it so that we can figure out the best approach. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Draft GR for resolution process changes
Hi all, I have been working on a draft GR to modify the process used by the Technical Committee and for General Resolutions to prepare a ballot for vote, with a goal of fixing several issues that were uncovered by recent votes. My plan is to propose this formally as a GR on November 13th. If you have not been following debian-vote where those discussions have been happening, you may want to read the draft resolution and the previous discussion. Constitutional changes require a 3:1 majority, so my goal is to reach as broad of a consensus in the project on these changes as possible. All feedback welcome, and also let me know if there is a reason to postpone making this a formal GR and thus starting the discussion period clock. The most recent draft is at: https://lists.debian.org/debian-vote/2021/11/msg00034.html Previous drafts and resulting discussion are at: https://lists.debian.org/debian-vote/2021/10/msg2.html https://lists.debian.org/debian-vote/2021/09/msg00010.html and also see the discussion thread starting here: https://lists.debian.org/debian-vote/2021/10/msg00019.html -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Add my CA cert in trusted certs
Миша writes: > "This is neither easy nor cheap, and we cannot help > you with that either." You can add my cert in source code. Right, but we won't. This is nothing against you personally (I know absolutely nothing about your CA or how you run it). It's for several other reasons: 1. Verifying certificate authorities use good practices is a complex and complicated problem that is way outside of Debian's area of expertise. 2. It's not very useful and causes lots of problems if different distributions use different sets of trusted certificates. There's a lot of merit in standardizing the default trusted root CA list across multiple distributions and web browsers. We instead defer decisions about the default trusted root CA certificates to Mozilla and copy their trusted store. For local root CAs, we provide a mechanism for you to install your own trusted certs on the systems you maintain. See /usr/share/doc/ca-certificates/README.Debian for more details. For most situations, the right answer is either to use Let's Encrypt (for public-facing services) or to automate installing your own CA on your systems (for private PKIs). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: DEP-16 Confidential votes
Timo Röhling writes: > I would like to implement a cryptographic protocol that provides the > same level of verifiability for secret votes as the currently used > public votes. In particular, I would like to see some additional proof > that the published hash values actually belong to eligible voters. As Kurt mentioned (but buried in one of those debian-vote threads), take a look at Belenios if you aren't already familiar with it. https://www.belenios.org/ It presumably would need some work to be usable for Debian votes due to needing integration with PGP signatures and our keyring, and unfortunately we can't use the really cool homomorphic encryption mode because we want to do Condorcet, but it otherwise seems like the right sort of direction. As a bonus, the developer is a member of the Debian project. I would rather an existing system like that, which has already undergone some cryptographic peer review, than for us to try to come up with something novel. Secure online voting is an insanely hard problem, and while we have enough unique conditions that we can probably relax the constraints that make it unsafe for general population political elections, there are still a lot of ways it can go wrong that are very inobvious. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Debian should not engage in politics and stay neutral [was: This is not the direction that will lead to hearing each other]
We just had a week of this on debian-vote. Can we please not have another week of it on debian-project? It's one thing to debate larger issues about the project's stance on politics more generally, but at this point we're just rearguing the GR in progress, which has already gone through a discussion period. Everyone's repeating the same things they already said, and the chances of anyone changing their mind are slim. You can now go vote your opinion rather than having to write more mail about it. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Debian should not engage in politics and stay neutral [was: This is not the direction that will lead to hearing each other]
we're going through that process now. This is all healthy and normal. But I think it's important to emphasize that even if Debian as a project takes a political position on something, that does not imply that every individual in Debian agrees with that position, or that one has to leave the project if one does not agree with that position. That's a separate and much more serious additional step. In some cases, we may wish to take that step. For example, if someone wishes to advocate within the project that free software is an evil plot to steal the intellectual property of the world's great software companies, Debian is probably not the place for them and there's probably no benefit to either them or the project to try to make that work. And there will be arguments over when to take that step, and vigorous debate, and then we have a governance process to use to make those decisions. But we should not confuse the two. Taking a political position as a project is not the same thing as setting rules for what type of advocacy we are willing to let people do with project resources, and that is not the same thing as setting minimum standards of behavior for project members, and none of those things are the same thing as trying to restrict people's *thoughts* (which is something we absolutely should not ever do). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Fwd: protontypes wants to support the Debian Project with LibreSelery
Tobias Augspurger writes: > 5. After the split is done, we distribute the money to the email address > via the Coinbase API. Are you investigating other payment options, or is LibreSelery expected to only support Coinbase? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Keysigning in times of COVID-19
Jonas Smedegaard writes: > Any opinion on the "votes twice" part? Anyone? How many decisions have we had that were decided by a slim enough margin that you believe fraud could have changed the outcome? What have we voted on that you think anyone would care sufficiently about to do the tedious and time-consuming work required to get a fake identity with voting privileges? I'm dubious of the threat model. Injecting malicious code into the archive seems to have a far, far higher reward to effort ratio than voting in our rare and generally not very close project votes. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: [Summary] Discourse for Debian
igation to engage with their idea and try to spell out my concerns if it's important to me. Most of the bad ideas will be filtered out before that point, so the chances are much higher, when something reaches that level, that other people are seeing merits in something that I'm not seeing, and it's worth the time and effort to dig into why and where the points of disagreement really are. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: [Summary] Discourse for Debian
Karsten Merker writes: > I don't agree with your assessment that there has been hostility against > Neil. There has been criticism - sometimes strongly worded criticism > that one might perhaps call hostility - against replacing our > mailinglists by something that quite a number of people in this thread > consider worse than the existing situation. Nothing of that has been > any form of hostility against Neil - you are IMHO assuming an ad-hominem > where there is none. This paragraph, through no intention of yours, is an excellent example to me of why Debian is such a difficult project to participate in, and why it's so hard to remain motivated to contribute rather than moving to another community that isn't as hostile. Hostility and ad hominem are not synonyms. Just because people are not attacking Neil personally doesn't mean people are not being hostile. An environment in which people express negativity at nearly every proposed change, even without personally insulting someone, is still deeply unpleasant to be in. My impression is that people are reacting out of fear and anger because somehow what Neil is doing feels very threatening. I have some empathy for that, but the way that it's playing out is awful for our community and is exactly the sort of thing that makes it less likely people will continue to participate in the project. People are acting like the shutdown of every mailing list they care about is imminent and they have to express their objections as strongly as possible to protest something that's about to happen. This isn't remotely how any of this works, and it makes productive discussion nearly impossible. It is also deeply discouraging to anyone who might ever want to attempt to change something in Debian. > I (and I suppose everybody else in this thread) very much respect > Neil's efforts to make Debian better, I believe that you *want* to respect his efforts, and that you may internally be feeling respect. However, what people have done on this thread is not respect. Actions speak louder than words. Saying that you respect his efforts is not the same thing as respecting his efforts. Respecting his efforts involves doing things like pausing, realizing that sending a negative reply to a mailing list is much easier than the work he's putting in, and deciding to take additional time to rephrase assertions as questions and rephrase objections as requests. Respecting his efforts means using phrasing like "here are the things that I think I would miss from email" or "hm, these features seem contrary to our project goals; can we disable them?" or "interaction without a web browser is very important to me; what improvements to the email interface can we realistically make to make that interaction style work?" In other words, respect looks like collaboration and partnership. How can I make this idea better? How can I improve this proposal so that it's something that I would like? Or if I truly think that's impossible, how can I listen very deeply and carefully to the goals underlying the proposal, and what alternatives can I imagine that meet those goals as well as mine? Or, if that's impossible, and you believe all movement in this direction will definitely be bad for Debian (and wow, that's a strong stance that should require *substantial* justification), it's okay to be confident there will be a future opportunity to make a *decision* rather than a *test* (which is what's going on right now), and be silent until then. Or, if you must, ask a question like "what will the decision process look like before we create a parallel forum for a mailing list, and how can I be involved in that decision?" Respect also means recognizing that some decisions may not affect you and thus may not be about you. Perhaps Discourse won't be a good solution for debian-project or debian-vote as Neil was hoping, but perhaps it's the *perfect* solution for some packaging team of which you are not even a part, and whose mailing list you never interact with. Maybe they'll move to Discourse and you'll *never notice*, because it doesn't concern you, and they'll be very happy. Drowning the project in negativity right now could prevent that sort of discovery from happening. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: [Summary] Discourse for Debian
writes: > On Wed, Apr 15, 2020 at 12:45:13PM +0100, Neil McGovern wrote: >> If there is sufficient pushback, I'll delete the instance, move on with >> my life, and conclude that no one in Debian can possibly try and >> innovate or do new things unless it is either: >> * 100% optional for people, or >> * made completely compatable with the old way of doing things > Oh, now. This wasn't necessary. I think it was. The amount of hostility with which Neil is being met for even trying something new is kind of staggering, and if I were him, I would be equally upset. It's way easier to say no than to try to build something new. I wish people would take that into account and try to engage with what someone is attempting to accomplish and respect the effort that they're putting into trying to make Debian better, even if they don't think this effort will succeed. For example, a whole lot of people have piled on to declare things that they consider misfeatures in Discourse to be "completely unacceptable" or other wording of that type, and very few of those people have asked the obvious question of whether these are things we could simply turn off, and what would be lost by doing so. It's easy for the negativity to feel highly asymmetric, and to quickly reach the conclusion that Debian is not a useful environment for attempting to accomplish anything new because it's so much easier for people to block things than it is for people to build new things. A lot of strenuous objections are equally effective when phrased as questions about capabilities and configuration options, and are much easier and less stressful to engage with in that form. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Testing Discourse for Debian - Alternate interactions
Ihor Antonov writes: > I do apologize if I came across offensively in this thread. English is > not my native language and often I lack communication skills to express > what I want in a less blunt way. And often re-reading my own emails It > picture myself as an angry enraged, which is not how it really is :) On > top of that I tend to get carried away with metaphors, which was aptly > noted by Russ. Thank you very much for saying this, and no worries at all here. I know all too well how sometimes I run away with a figure of speech in the middle of writing a message. I completely understand your reluctance to assume that everyone has Firefox or Chrome and wants to interact with a web site. And I also do appreciate people watching out for overuse of moderation! I personally don't think Debian is likely to have that problem, but other organizations have, and it's always worth being thoughtful about. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Testing Discourse for Debian
Dan Purgert writes: > I think your younger colleagues are perhaps in a similar situation as me > then -- the first place they've experienced *real* email volumes is at > their first actual professional position; and they don't know how to > cope with *everything* being placed into their inbox. I mean, I can't > think of any other time before "work" wherein I was getting more than a > handful of "important[1]" emails per day; and now I'm suddenly in a > position where 30 people all have something "important[2]" to send me. I have had this conversation with people before about filtering. The valuable counterpoint is "rather than investing time and effort into filtering email into buckets and then working out a strategy for when to read those buckets, how about instead we adopt a system that discourages people from filling my inbox with crap, and instead allows me to find that information when I need it rather than broadcasting it to the world just in case?" It's rather hard to argue with that. My current employer uses email so little that at least half the time I go more than a day without bothering to open my work email. All the important stuff is in a ticket system, on pull requests, or in tech notes that are indexed and searchable. I haven't missed the email at all. I too am very proud of my email filters, but the best email filters are the ones that prevent the email from being sent in the first place. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Testing Discourse for Debian
Dan Purgert writes: > Who makes up the "younger" crowd? sub 30? sub 20? I mean, I personally > was in my mid-20s when I first started using Linux (college), and I had > otherwise only been introduced to the internet via AOL. Sub 30 was what I was thinking of. I'm only saying there's a bit of a statistical tendency, not that this applies to everyone, obviously. But when I look around at the broader development world, the majority of the newer projects seem to not use email at all. Even when they do, it's not where the most useful conversation happens. Now, in a lot of cases the real conversation happens on GitHub, which isn't exactly the same thing as a forum. But forums seem to play a large role in some of the more vibrant communities (Rust, for instance). > There is something to be said for educating "younger people" with the > old ways -- I mean how many of these "Modern" things are just > re-implementations of what previously existed (except with centralized > control and "oh yeah, pay us"). This may be the case, but I think those of us who are familiar with email have a bit of a tendency (I'm *definitely* including myself in this) to jump straight to "let me explain to you how email already does everything you want if you just use it properly" without bothering to ask people what features they like and really listen to them. Professionally, I can tell you that my younger colleagues tend to hate email and far prefer other communication mechanisms, and that's not because they're unaware of how email is used. The most commonly stated reason is that email is full of noise and pointless messages that aren't worth reading, compared to other approaches. That's just anecdotes, not data, obviously, but it made me curious to understand what I might be missing. (My past experience is that when younger colleagues get excited about a new way of doing things, I should pay attention, because there are probably things that I'm missing and that I will appreciate if I look into them more deeply.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Testing Discourse for Debian
Russ Allbery writes: > There does indeed appear to be some sort of problem (I haven't received > the list copy of your message either), but your message was approved two > minutes after you sent it, so I don't think it's with the moderation. Ah, apologies, I was also confused by a change we made in how the messages were processed and thought it was approved when it wasn't. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Testing Discourse for Debian
Ihor Antonov writes: > Well, now I notice, thank you very much. > Apr 12 21:43:38 mail.antonovs.family smtpd[46138]: bcb7c45eb6e6a5bf mta > delivery evpid=95394d1f34ea1dd5 from= to= proj...@lists.debian.org> rcpt=<-> source="10.193.1.100" relay="82.195.75.100 > (bendel.debian.org)" delay=6s result="Ok" stat="250 > > Apr 12 21:43:48 mail.antonovs.family smtpd[46138]: bcb7c45eb6e6a5bf mta > disconnected reason=quit messages=1 > 2 hours later it is still not in the list > As far as I can tell my message was dropped after MTA accepted it. There does indeed appear to be some sort of problem (I haven't received the list copy of your message either), but your message was approved two minutes after you sent it, so I don't think it's with the moderation. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Testing Discourse for Debian
Ihor Antonov writes: > On Sunday, April 12, 2020 11:51:27 AM PDT Russ Allbery wrote: >> The forum to which you sent this message is already moderated and has >> been for months. I suspect you didn't even notice. > So how then you need more moderation possibilities with Discourse? So, I should be clear that I personally have only a small amount of experience with Discourse and haven't looked into the details of its features. But there are a lot of reasons for investigating that sort of forum software, more generically. Here are a few. 1. A database-driven discussion system that supports updates lets you go beyond the moderation that you're worried about (rejecting messages) and do other forms of moderation that help improve the quality of discussion without removing messages. Examples include splitting threads that have digressed from the original topic to create more focused discussions, pinning important summaries so that people see the current status of the discusison quickly, closing old threads so that people properly open a new discussion instead of replying to some resolved discussion with a different problem, and even just sorting, classifying, and tagging threads so that people can find the discussions they care about more easily. 2. You can indicate agreement with a proposal or message without adding more words that everyone has to read. The +1 reply in email is clunky and adds a lot of noise. Often it's useful to be able to get a quick count of participants who agree with an idea but don't want to write their own extended message about it. 3. There is some age correlation with the type of communication mechanism one is comfortable with, and reason to believe that younger people skew towards being more comfortable with forums than with email. If you didn't have to learn email client skills (particularly the type that Debian demands, which are drastically different than how email is used in most jobs), it's not very welcoming to have to learn those skills in order to participate in the project. They're a lot less trivial than I think people who have been using email for a long time realize. I've had nearly 30 years to hone my ability to quickly sort through huge quantities of email and reply in a readable way, which means it's easy for me to forget how much work that took, how much effort I've put into customizing and learning a top-end email client, and how many of the rules are inobvious and arcane. Not everyone cares about this sort of thing, but I would wager that Debian is currently skewed towards people who cope well with email because we have good email skills as a bar to entry. Expanding the set of people who can effectively contribute requires looking outside our own comfort zone. > I do not advocate for free-for-all. It is just the ability to decide on > who gets to say what should not be in the hands of a single person / > small group, it is way to easy to get corrupted/biased/controlled. And yet the Internet is full of successfully moderated forums that create very little drama because they're just quietly more usable. You have to trust the moderators, and you have to have some mechanism to evaluate that trust and to discuss it and possibly revoke it if something goes horribly awry. This is work that should be done, but it's work that's very doable. I think it's also worth pointing out that Debian users currently trust Debian developers with the security of their computers, which I think is a higher bar than trusting other Debian developers with the moderation of our discussions. These discussions often strike me as being weirdly disproportional and inconsistent about how we extend trust. We trust each other with hugely important and critical things, and then are full of mistrust about minor and often quite trivial things, such as whether or not one gets to have the final word in some war of words that nearly everyone will have forgotten by next month. > Coming from a corrupted-to-the-bone post USSR country I speak from > personal experience of being on receiving end of that situation. You may > think that it is for the best, but it is not. This is a common argument, but I find it entirely unpersuasive. Censorship is highly concerning when done by a government because the government can use force to prevent any other form of discussion except the one the government controls. The idea that Debian could do this is absurd. If moderation of Debian forums suppressed some problem that a lot of people really cared about, there would be an explosion of discussion elsewhere, huge uptake of the discussion in other places over which Debian has no control (LWN, for instance), and alternative forums being repurposed or newly created all over the place. This is a community full of people entirely capable of setting up a new mailing list or forum on the
Re: Testing Discourse for Debian
Ihor Antonov writes: > And separately, I got interested in Debian because it was using mailing > lists in the first place. Mail is decentralized by design and this is > why it is so important for freedom of speech. I don't understand this comment. Mailing lists are inherently centralized by design. > Now you suggest a centralized platform for communication, because it is > easier to moderate (oppress freedom of speech). To me it sounds like: > "Yes you can talk, but only if you do it on my terms, on my territory". > Moderation is a slippery slope, using centralized communication platform > is one step closer to dictatorship. The forum to which you sent this message is already moderated and has been for months. I suspect you didn't even notice. That said, I will argue that "yes, you can talk, but only if you do it on my terms, on my territory" is a message that the Debian project should send about its own communication channels. (Obviously people can go create their own and that's no business of ours.) That's how we create a community that can get things done together, rather than a 4chan free-for-all full of abuse and trolling. We should think carefully about both the terms and the territory and be both gentle and understanding, but we will not successfully create a free Linux distribution (the actual point, after all) within the noise of complete freedom from consequences in communication. I don't believe Debian is or should be a welcoming home for people who care more about the ability to say anything they want whenever they want in project forums than about making a free software distribution together. And yes, these two goals do sometimes come into conflict (although we can try to minimize how often that happens). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Salsa as authentication provider for Debian
Luca Filipozzi writes: > I think that our services -- such as SCM, CI/CD, Wiki, RT, etc. -- > should evolve indepdently from the SSO infrastructure. One could argue > that RT has a user database thatcould be used as authenticaion service > if exposed correctly. Or the Wiki. Let me try to rephase this and see if I understand. Your concern is that by using Salsa as the IdP, we're coupling identity in Debian too closely to one component of our development infrastructure, and thus possibly creating roadblocks in the future? For example, we might want to switch to a different SCM platform that doesn't provide an IdP, or we may want IdP features that aren't a priority for GitLab? That argument does make sense to me. This path more tightly couples the project to the Salsa deployment. However, I personally am not *too* worried about this because OIDC makes it possible to migrate IdPs without too many problems. This is where a standardized protocol helps considerably. There would still be some challenges in exporting and converting the Salsa identity database, but we have all that data and could do that work. I agree with you that this is a risk, and it might be good to do some planning work up-front to identify the data we're storing in Salsa that we may want to move to some other platform like Keycloak in the future, but I think it's a risk we can mitigate. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Salsa as authentication provider for Debian
Luca Filipozzi writes: > On Fri, Apr 10, 2020 at 11:48:22AM -0400, Sam Hartman wrote: >> * Note that if you want to you can host accounts in gitlab and have >> keycloak act as an OIDC consumer for gitlab. So, if you decide you >> like Gitlab as an IDP but find you need Keycloak's transformations, >> you can have people login to Keycloak using their Gitlab accounts. > I reiterate my point that an SP being an IdP. I don't view using > Debian's Gitlab as an IdP to be a prudent move. I don't understand this objection. The relying party and the identity provider are certainly different components with different functions, but that doesn't imply that they can't be combined in the same software suite. There's quite a lot of shared code between an SP and an IdP, so in some sense that's easier than maintaining them as entirely separate projects. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Request to Mini DebConf Montreal Organizers: Fight Israel not the DC20 Team
Ansgar writes: > If you have 80-90%+ of parliament, from pretty much all parties, agree > on something, then it *is* pretty much as uncontroversional as it gets > there. This is an entertaining example to use in a project whose mission is free software. I'm pretty sure that by that standard it's entirely uncontroversial that Windows is the best operating system, that software copyright has no social downsides, that software patents are a good thing, and that proprietary software companies are a vital backbone of the economy. I can assure you, as a US citizen, that the idea that BDS is inherently antisemitic is very controversial in the US. Your beliefs about the political consensus in my country are uninformed. Political consensus in the US is not well-represented by voting ratios in Congress, particularly in the absence of a lot of complex context. I will not try to tell you what the consensus is in Germany since I'm obviously not qualified to do so. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Announcing miniDebConf Montreal 2020 -- August 6th to August 9th 2020
Daniel Lange writes: > "active apartheid regime" is politically loaded lingo and shows where you > stand. This is another way of saying that it clearly communicates a political point of view. Perhaps that was the goal. If one holds the position that this is an inherently political decision (as Ian stated and which I also agree with), stating an opposing political position is a reasonable part of that conversation. > Employing it disqualifies rational arguments, if you had any. Why? Rational is not the same thing as apolitical. I object to reserving "rational" for only political viewpoints that agree with the speaker's. The Debian Project made, through its delegated processes and procedures, a political decision to host DebConf in Israel. That decision was made on the basis of various good, well-intended, and entirely reasonable arguments, including (quite significantly in my opinion) expressing support of the project members from Israel regardless of one's opinion about the actions of their government. Speaking as someone who also lives in a country whose last two national governments have taken numerous actions I find reprehensible, I find that argument persuasive. That decision was also opposed on the basis of good, well-intended, and entirely reasonable arguments about the impact of Israeli government policies, on the efficacy of boycott by analogy to other historical struggles, and on moral arguments about what obligations the rest of the world has towards oppressed peoples. Obviously, those arguments also rest on facts which are in dispute by multiple parties, but just as with the arguments for holding DebConf in Israel, they are largely made in good faith. Both positions are *inherently* and *inescapably* political. The Debian Project is also not going to somehow reconcile those positions and arrive at a consensus political agreement on a political problem that has challenged the world's most adept diplomats for well over 70 years. This discussion is unavoidably political, and there's no point in trying to argue that we can or should leave politics out of it. All positions that one can take carry political ramifications. We might prefer that the project somehow manage to stay out of issues like this, but I'm afraid that's not possible; both accepting and refusing to consider a bid for a conference in Israel are political positions. And whatever way the project decides, it is certain that groups in the project will continue to (strongly) hold the opposing view. Politics is not a dirty word. Politics is how large groups of humans argue and coordinate. It's inescapable among large groups of people. All we can do as a project is to decide what political positions we're willing to take, how to mitigate the effects of those decisions where appropriate, how to manage the effects of those decisions on members of the project who disagree with them, and how to provide enough space in the project for opposing views such that political positions that are not *intrinsic* to the project cause as small of an impact on project unity as possible. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
Sean Whitton writes: > The main reason I referred to dgit's copyright file in this discussion > was because I think the "Contributions are accepted upstream ..." > section is useful to include in d/copyright rather than somewhere else > in the source package, as then all licensing and copyright information > is in one place. I don't think its inclusion there would noticeably > slow down NEW review. I'm going to disagree here (although I don't feel strongly about it): I don't think this belongs in the debian/copyright file. I think of the copyright file as a repository for the licensing information and mandatory notices for the package as delivered as a Debian package, and this isn't any of those things, so it makes the file longer and is more for anyone reviewing licensing to read through, while (I think) not being relevant to the license of the code or binaries. This sort of upstream contribution policy in my mind should be put as close as possible to the place where someone is submitting code upstream. If the project is based on pull requests, for instance, it should ideally be prominant in the interface where one submits a pull request. For a package where most contributions are expected to come through the BTS, I would instead put the "Contributions are accepted upstream..." paragraph in README.Debian and the certificate of origin in a separate file in /usr/share/doc, since I think that would increase the chances that someone who was preparing a patch would read it. (I personally would never look at debian/copyright when submitting a patch to the BTS, but would probably read README.Debian.) This is just one anecdotal opinion, though, so please take with a grain of salt. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
Mo Zhou writes: > Don't know what Red Hat family does, but at least Archlinux and Gentoo > treat the license checking problem in a very permissive way. However, > Debian is sometimes an important reference to these friend distros when > they encountered some problems about license. I do think we can maintain that property without hand-checking every file in every source package we upload. My sense (I could be wrong) is that other distributions look at us more for our analysis of the license terms than for our ability to dig out obscure issues from source trees. And even if it's finding obscure issues in the source tree, we still have a lot of eyes and a community that cares about these things and it's always possible for people to do volunteer reviews. Another option that I forgot to mention is that we could continue to ask the package maintainer to do a thorough license review and treat licensing problems as bugs. One way to think about the current ftpmaster review is that we treat licensing bugs far more seriously than other bugs and thus have mandatory code review for licensing issues but not for anything else in Debian. And again, that could be exactly what we want to do, but it's worth calling it out as a deliberate choice. We could decide to treat licensing bugs as less special (with appropriate legal advice, of course). > Making that process scalable seemed like a workflow change, which often > takes centuries to enforce in this community. Even if that process can > be scaled to a larger group of workers, without proper tool every worker > node will still work in low efficiency (and still easily get mentally > bored). Well, in this case the workflow is already centralized, so I think it's more tractable than that. But yes, thank you for starting the discussion of the tool. I think such a tool is extremely valuable for maintainers regardless, and will make any workflow that involves any central review under any circumstances much easier. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
Jonas Smedegaard writes: > Beware that I say we must _check_ every file - not that we must _list_ > every file in debian/copyright. > All that Debian distributes must be legal to distribute. > You may argue that you need not check e.g. if PNG files in your package > contain embedded non-free ICC profiles, but that just means that you > rely on ftpmasters to check it on your behalf. > You may argue that your upstream has already checked that for you. I'd > call that a sloppy check, and there is a real risk that again you then > burden ftpmasters with digging out dirt because upstream has a different > view than Debian what is legally acceptable. Requiring ftpmasters to do this check is a choice that Debian has made. Maybe it's the right choice, but other choices exist, and other entities make different choices. For example, we could chose to trust upstream license assertions and fix them later if upstream turns out to be wrong. Or we could chose to adopt a specific tool for automated license checks and base the accept decision on the output of that tool plus upstream assertions in the knowledge that this could be incorrect, and later fix problems that are drawn to our attention. (Note that thorough license review has not completely eliminated license problems that we have had to fix later, although it certainly reduces the number of them. We will be fixing some issues retroactively under any approach.) In the context of limited project resources, it seems worth asking not the absolute question of whether thorough license checks have desirable properties (obviously they do), but instead whether this is the most effective use to which the project could be putting this energy, or if we should consider alternatives so that we can redirect some of that energy to other things the project considers important. Another way of asking that question is to ask whether this sort of thorough license double-checking is something we consider a core mission of the project, or something that we're doing for secondary reasons (such as reducing the risk of legal liability). If it's a core mission of the project, then maybe we do want to reaffirm our decision to spend significant resources on it. If we're only doing this for secondary reasons like legal liability, it might be worth looking around and seeing if other organizations with similar legal risks take the same precautions, or asking for legal advice on whether this precaution is legally necessary or if we're creating work for ourselves that exceeds the legal risk we'd be accepting by doing something more automatable. To be clear, it may be that we'll ask this question and decide that yes, detailed license review is something we consider important and we want to keep doing it the way that we have been doing it, and we need to figure out how to make that work scale. But I do think it's worth occasionally explicitly asking the question and then making an intentional choice, rather than assuming we're obligated to continue doing what we're doing. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Some thoughts about Diversity and the CoC
Jonathan Carter writes: > I understand the nature of trolls and not wanting to feed them, but it > is entirely possible to denounce them without giving them fuel, even > though it can be like walking a tightrope at times. It also matters who the person is. A troll in the most classic Usenet sense is someone who isn't part of the community who drops in to post something provocative to try to get a reaction. The definition has broadened over time, but that's the sense in which that maxim was originally developed. When faced with someone from the outside with no investment in the community who is just trying to rile people up for amusement, not reacting usually means they'll get bored and go somewhere else, and was often the fastest way to end the disruption. Hence that saying. Someone who is part of the community, and certainly someone who is a member of the project, is not a troll by that definition, and I think it's very questionable whether the maxim applies. They're already invested in the community. They're unlikely to just go away if they don't get a reaction, and may not have the same motives as someone just trying to provoke reactions for entertainment. Ignoring them is less an effective way to minimize disruption and a lot more like letting your uncle go off on a tirade of abuse against your cousin. Also, it's worth thinking about the fundamental mismatch between welcoming someone as part of our community and saying they're a troll who should be ignored (not fed). I don't think those two things are compatible. Members of the community are by definition people who we don't want to ignore and don't want to assume are just poking people for their own entertainment. If they *are* doing that, they should be shown the door. Harassing other people for one's own personal amusement is abuse. It is destructive and awful behavior that will hurt a community deeply if it is tolerated. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Some thoughts about Diversity and the CoC
Adam Borowski writes: > You try to somehow equate denying a "right" to be smug over forcing > others to lie, with a direct expulsion. One of these is just a feeling, > the other is an actual severe action. I'm not sure that I parsed that correctly, Adam. I hope that you didn't just imply that asking someone to use someone else's correct pronouns is asking them to lie, and I just misunderstood what you were trying to say. > Accept my apologies that I'm not inclusive enough to demand expelling > people, and that I'm not diverse enough to demand a homogenity of > opinions. No. To avoid any appearance of doubt, I stand with my transgender colleagues, I believe that it is completely unacceptable to attempt to erase their experience, and I am completely in favor of expelling from the project anyone who insists repeatedly on intentionally referring to them by an incorrect gender or otherwise verbally harassing them or denying their existence. This principle is more important to me than the unity of the project and is more important to me than Debian. I do not believe diversity is about accepting anything including intolerance. I believe in making explicit choices, and standing by those choices. I support LGBT people and do not support anti-LGBT people. If that's in conflict with Debian's code of conduct, so be it. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Some thoughts about Diversity and the CoC
Martina Ferrari writes: > [2]: I am sorry to take aim at some other people I also have in high > regard and to grammar studies (which I actually find fascinating), but > turning this thread into a gentle discussion of grammar feels pretty > insulting, and like the pinnacle of privilege. I'm sorry, Tina. You're entirely correct, and I apologize for latching on to that part of the conversation and not being aware of the context or thinking at all about how that would come across. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Some thoughts about Diversity and the CoC
olbook grammatical rules. (I realize that this can be kind of frustrating for people who aren't native English speakers, because those rules can provide the structure that they rely on to express themselves in English.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: anti-tarball clause and GPL
Ian Jackson writes: > There are existing packages for which I consider the PFM to include > the git history. I'm not pressing this point from a legal point of > view because, well, that just generates lots of heat and no light. > I think that we should address this potential problem by arranging to > give to the history to our users and downstreams. There are lots of > other really good reasons to do this. Since I was arguing in another branch of the thread that I didn't think trying to use the GPL clause to force this made sense, I want to say here that I completely agree with this: we should make the VCS history readily available. There are tons of good reasons to do so, one of which is that it empowers our users to understand and change the software that we distribute. I don't think it's productive to try to force the matter legally, but I think it's a good place to exert effort technically. I'm dubious that the Debian archive is the best place from which to distribute full VCS histories for boring technical reasons, but I'm already convinced that we should be building on the dgit machinery as the future of how packages will be maintained and uploaded, which also provides an obvious place from which to make that history available. > This boat already sailed a long time ago. Via alioth and now salsa, and > via the dgit git server, we are in many cases distributing that complete > history already. I think it does make a (minor) difference that we're not encouraging third parties to trust us that it is legally fine to put that material on CDs, sell them, etc. The practical risk bar is lower when the material is only on services that we fully control and therefore for which we can easily respond to cease-and-desist letters with merit, etc., and other people aren't trusting our license statements about that material. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: anti-tarball clause and GPL
Adam Borowski writes: > At this moment, not yet. Obviously, old projects didn't even _have_ a > VCS, and I'm not proposing imposing a VCS workflow on the upstream. I'd > like to consider, at some point in the future, hidden private VCSes > where the upstream occassionally releases a tarball of to be non-free, > just like the same PNG image can be free if there's no XCF file but is > not if the upstream holds a private XCF version they routinely modify -- > a "preferred form for modification" is not required to be good, merely > no worse than what upstream themselves use. I don't understand why you chose the VCS specifically and alone to elevate to the level of required source. If I had to pick what additional information I'd want over and above the current source code, I'd be way more interested in the bug tracking system than the VCS. I use that an order of magnitude more often than I use Git history when developing software. There are a few other really obvious reductio ad absurdum arguments here, too. For example, most of the critical documentation for the Linux kernel that's practically required in order to understand it well enough to meaningfully maintain it is in LWN or the linux-kernel mailing list archives. Guess we need to start including those in the source package now too The line between source and supporting useful stuff that's not source is inherently arbitrary. For better or worse, we have thirty years of history behind drawing the line in one specific place. That doesn't mean there are no good reasons to change that line; it does mean that any other place we draw the line is still going to be arbitrary. Redrawing the line is a *huge* amount of disruption and energy drain because we have to relitigate endless mostly-settled discussions from the past thirty years around what source code means. The payoff needs to be correspondingly large to be worth the effort, and I'm just not seeing it. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
Michael Banck writes: > On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote: >> This probably has been floating around for some time. IMO, enough time >> so that we start to discuss $subject. > Why is this a GR and not a policy proposal? Policy changes require strong consensus, and it's very unlikely that we have that sort of strong consensus here. Put another way, Policy is already behind on documenting things that we've all already agreed about but that need some time and attention to document properly (stuff like triggers, good practices for systemd units, multi-arch, and so forth). For things like this that will be controversial (see also dropping our support level for alternate init systems, which comes up periodically), we're going to ask the project to find some other decision-making process. For a proposal like this, I think a GR may be the best decision-making process we have. (This shouldn't be taken as an opinion either way on whether this proposal specifically should be adopted.) If we do want to change our historic maintainer-driven free-for-all and start mandating specific tools, that's a sufficiently large *cultural* change in the process that, unless we can reach some sort of guided consensus like we did with dh (and I think this is more controversial and is also a much stronger statement than we arrived at with dh), having everyone vote on it is probably the right move. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Results of the Antiharassment Team Survey
Sam Hartman writes: > I understand Russ has some thoughts that I hope he'll be sharing soon. I'm afraid that for reasons unrelated to this discussion I'm not going to have the time or energy to try to expand on my thoughts, and am going to bow out of this thread. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Results of the Antiharassment Team Survey
ar short of expelling someone from the project but are still effective at putting an end to unacceptable behavior. If anything, I would like to see us concentrate our energy in finding more effective short-term ways to put a stop to behavior than to focus on mediation. The idea that there is no space between gentle coaching and mediation and some sort of destructive ultimatum is exactly the problem. This is the type of empathy that turns into paralysis. The Debian project is composed of adults who are perfectly capable of learning to control their own behavior, learning to not do things that result in someone warning or banning them temporarily from a project resource, and figuring out that a warning about their behavior is neither the end of the world nor something that they should just indignantly ignore. I don't want to be unsympathetic to people who are honestly struggling with conflicting cultural expectations, but I think we're making this way harder and way more fraught than it actually is, and are not having sufficient confidence in each other's abilities to react to conflict by modifying our behavior. Maybe we get grumbly about it, feel unfairly treated, and complain to friends; all that is a perfectly normal human reaction. As long as the behavior changes, the project can clearly draw and maintain those boundaries, and there's some escalation process leading, if we have to, up to expulsion from the project for people who absolutely refuse to modify their behavior, I think we will be in a fairly good place from an anti-harassment standpoint. Supportive mediation and coaching would be a gracious and generous gesture should someone choose to volunteer that to someone who sincerely accepted it and benefited from it, but this is a *really* high bar that practically no organization reaches, and my point in my original reply is that I don't think this should be our success criteria. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Results of the Antiharassment Team Survey
Hi Sam, Thank you for sending this analysis and the clear effort and thought that's gone into it. I'm very glad that you gathered some partial data, which is a useful addition to the normal mailing list discussions. I do have some significant concerns about the conclusions you've drawn, and around the feasibility of what you have identified as the project's goals for the anti-harassment team. Maybe they're off-base, but I'll be frank about them and see where the discussion goes. First, although I've snipped all those parts of your message, I completely agree with the concern about responsiveness and with finding some way to prioritize that. There is often a time limit on being able to effectively respond to harassment or related problems in a project, beyond which a lot of the value is lost. That also makes the job very difficult, which leads into my concerns. Sam Hartman writes: > The second is that we need to do better at actually engaging in > mediation. By that I mean helping people understand what changes in > behavior we're looking for and how to accomplish their goals within our > standards. I do not mean the AH team should routinely engage in debates > about whether particular conduct is consistent with our standards. My > hope is that by addressing these concerns we can build stronger trust in > the team. Maybe I'm reading too much into what you're saying, but I'm troubled by these statements. First, to me this feels like Geek Social Fallacy 1: Ostracizers are evil. What it feels like you're saying is that, as a project, we should invest even *more* time and energy in those people who are making Debian a hostile and negative experience for others. I believe this sends a clear if entirely unintentional message about who we value. Second, I don't understand how organized mediation can possibly be on the table at this point given our available resources, particularly since you've identified lack of responsiveness as your other serious concern. I know there are multiple factors that go into the question of responsiveness, but I can see no way in which adding a requirement of mediation could possibly improve response times. Third, I believe that requiring mediation expertise on top of the other (quite challenging) requirements for the AH team will mean that the role requirements are defined into impossibility. At that point, we're talking about a set of skills that people go through intensive multi-year training to acquire, and yet somehow we expect to staff that role with volunteers? This feels entirely unrealistic to me. I think instead we need to start with what sort of action is realistic for the type of project we are and our available volunteer pool, and then reset project expectations accordingly. On that front, I will advocate strongly for prioritizing stopping the behavior that is in violation of our Code of Conduct (on a timely basis) over making people who are violating the Code of Conduct feel heard and supported. I'm very sympathetic to the folks who are trying to navigate different cultures and different cultural expectations. We can approach this with a base standard of empathy, and we can start from an assumption of good intent, and hopefully that will soften the occasional difficult moment. But if we let empathy turn into paralysis, we're not doing the community any favors. Put another way, providing mediation is graduate-level work in AH. I don't think we have the 101-level AH work in a predictable and sustainable state. Let's start there. > However, what I find more significant is the comments made by people who > expressed support for the AH team. At least from a number of > participants, this support clearly envisioned an AH team that was > responsive and that effectively helped members of our community be > effective in their communication while following our standards. The conclusion that I personally would draw from this is that a number of people in the project have unrealistic expectations for what is possible for a voluntary anti-harassment team in a project like ours. I believe any attempt to add mentoring, coaching, or mediation to the duties of the anti-harassment team would have the effect of dooming the team, and thus significantly undermining our ability to maintain a reasonable project response to harassment. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Speaking your Mind
I think this thread has mostly run its course, but there's a point in here that's extremely important to me that I can't leave unsaid. Holger Levsen writes: > and btw, just about celebrating hispanic heritage... the Spanish were > responsible (with a bunch of other European countries) for destroying > several cultures in the Americas (and elsewhere), slaughtering people > and what not and you want to celebrate this? (Same for most other > European cultures...) > And, for the love of baby jesus^wdevil, please dont even think about > celebrating religions. The intent of recognizing the Hispanic heritage of project members, if that's meaningful to them, is not to sanction everything Hispanic or Spanish people have done in history. The intent of recognizing a religious day of significance to some project members is not to endorse or celebrate the religion. It's to celebrate and support the *people* in the project for whom this matters. I want it to be possible to simultaneously be troubled by or even outright disagree with something that is significant to someone else, and also celebrate with them the positive and affirming aspects of what that thing means *to them*, and how it enriches their lives. To be clear, this should be strictly optional. If someone has particularly strong feelings, they should be able to opt out of participating in that celebration with no questions asked and no offense taken. (And yes, I realize that's what makes a temporary logo change tricky, because while I don't think of it this way, I can see how people may feel like this is forcing them to participate in a way.) But it's still important to me to make a space for this in communities, because people's celebrations are part of their identity and part of who they are, in much the same way that writing long emails to mailing lists is part of my identity and part of who I am, and I'd get very grumpy if I had to suppress that. :) For example (chosen because I think it may be less common to some readers and therefore a bit less loaded; apologies in advance if I botch something I'm not personally that familiar with), I'm personally an atheist. For various reasons, I have extremely strong feelings about religion and its role in history, and they're not very positive ones. I also have some strong feelings about some aspects of the cross-section of religion and politics in India at the moment. But I still want to make space for project members to celebrate Diwali in a way that's meaningful to them, and support that, and I want to support that in areas of shared universality: food, beautiful displays of light, and so forth. It doesn't mean that I agree with everything they may believe. It means that I see the human being in my fellow member of the project, I see that person as an individual with cultural and religious traditions that are important *to them* even if they aren't to me, and I want them to feel welcome and seen as their whole selves. This can be a tricky balancing act, to be sure. Religion, politics, humor, offense, discrimination, identity, bigotry, history, and oppression are all tangled together and incredibly complex and fraught. But, to me, asking people to leave their moments of celebration outside of the project and to limit their project presence to purely technical contributions is essentially to ask them to cut off all of the parts of themselves that do not fit into the stereotypical norm of a Debian project contributor. And that stereotypical norm is not politically neutral. It looks a lot like the base beliefs of a white man from Europe, the United States, Australia, or Canada. I have lost track of who said this, but some wise person once said that one's politics are defined by what you don't think should be political. The things I find perfectly normal and ordinary and that I am astonished that anyone would disagree with are, in some foundational way, my core political beliefs. By asking people to confine themselves to that set of behavior, I'm not being politically neutral, even though it feels like that to me. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian supports pridemonth?
Eldon Koyle writes: > I think a big part of the issue here is the fact that by changing the > logo for only one group ever (presumably for one month out of every > year?), all other groups are marginalized. Huh, why? Organizations to which I belong celebrate all sorts of groups all the time that I am not a part of, and I have never felt marginalized by that, so I truly don't understand why this would make you feel that way. Could it be that this is just the first group for which someone thought of the idea, did the work, and made it happen? Personally, I would be delighted if Debian did something like Google did and changed our logo frequently to celebrate the enormous diversity of our project, although I'm sure we don't have the resources to pull that off. But even if we did that, I personally am not a part of any group that I can think of off-hand that we would celebrate, and not only does that not bother me, I don't even understand the process by which it would ever bother me. Celebrating someone doesn't mean marginalizing someone else. Being part of a community isn't an exercise in scale-balancing parsimony. > How do we ensure that Debian remains unbiased outside the realm of free > software? We don't. It's not possible. Debian is a collection of humans and humans have thoughts and political beliefs and are messy and social and collabortive and spontaneous. Some things will get time and attention and resources and other things won't, and that's just what working with a large collection of other people is like. What we can strive for, rather than unbiased, is to be positively inclusive, which means that if something matters to you and you're willing to do the work and it's a statement of positive inclusion rather than veiled exclusion (that bit is important; human communications come with context that matters), let's figure out how to make it happen. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian supports pridemonth?
Adrian Bunk writes: > It is also a meaningful gesture if some people are excluded from being > welcomed. > Would Debian honor a month of white heterosexual men? Do you think people with those attributes have been made systematically unwelcome in Debian, free software, or the larger world of computing? Speaking as a white heterosexual man, I feel very welcomed every day, which means that there's very little need for any special effort to make sure I know I'm welcomed. Literally the entire structure of society does that for me, constantly. I would like to pass the feeling on to others who do not have that constant background feeling in their life. The specific answer to your question is that context matters. A month of white heterosexual men, in the context of world politics at this time, is not about welcoming anyone. It's about declaring whiteness, heterosexuality, and maleness as the dominant default and everyone else as lesser, disguised in bad faith as a parody of welcoming. This sort of nuance can't just be handwaved away. That is, however, specific to your chosen example. If you'd picked a different example -- people for whom English is not their first language, for instance -- you may find I agree with you entirely. I *don't* think such folks are always made welcome, and I'd love to see some celebration in the project of the effort and thought that so many of our contributors put into working on a project in a non-native language, particularly if they would find some awareness and recognition from the rest of the project meaningful. In other words, I don't believe anyone is being made unwelcome *for being white, heterosexual, or male*. I do believe that there are people in our project who are white, heterosexual, and male, and feel unwelcome. To me, those are very different things, and if there are gestures we could make that would make those people feel welcome, I'm all in favor. But I don't believe celebrating *specifically* their whiteness, heterosexuality, or maleness would be effective except to the degree that it's a coded political message that we definitely don't want to send. I strongly suspect that the root of the concern is not that people feel like they're being made unwelcome because of their personal attributes, but rather that they feel like they're being made unwelcome for their political beliefs. *That*, unfortunately, is a much larger problem that I doubt we're going to be able to comprehensively solve because, among other things, it's mutual. I wouldn't be surprised if you felt like I'm currently making you feel unwelcome for your political beliefs; you may be surprised to know that you are currently making *me* feel unwelcome for my political beliefs. I don't have a solution for that other than both of us just living with it, and trying not to poke at each other too hard, but I'm not willing to cede celebrating Pride for our LGBTQ+ members as "poking" in this context. > Many people are offended by the fact that it is always the same groups > that are being welcomed. My default stance is to be happy for people when the project does something that they find meaningful and supportive. If some people get a lot of support, that's wonderful -- I think everyone *should* get a lot of support. If someone is *not* getting the support they need, that's a problem that hopefully we can address, but thinking of it as a zero-sum game where we can't support some people if we want to support other people is just not at all how I look at it. -- 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/>
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?
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?
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: 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: 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: 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
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
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
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
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: 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: 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: 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: > 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
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 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 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
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
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
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/>
