Re: Dispute resolution in Debian
Hi Sean, On Wed, Jul 29, 2020 at 1:10 PM Sean Whitton wrote: > > So what you are proposing would correspond to the last of our > proposals -- try to remove the meditation role the TC presently has? I am sorry you read my proposal as curtailing TC's "territory". I merely meant to write that mediating between people and making good long-term technical decisions for the project are probably two different things. Your original email stated as much when you wrote that "[often] the conflict is not at the technical side." Kind regards Felix Lechner
Re: Dispute resolution in Debian
Hi Sean, I hoped respected members like Sam would send additional ideas first, but then did not wish to keep you waiting. On Mon, Jul 27, 2020 at 7:01 PM Sean Whitton wrote: > > Do you think it shouldn't have those other roles, maybe? That would > correspond to the last of our proposals, I think. As a computer project, Debian's highest decision making body should probably be a Technical Committee. Current committee members who like to adjudicate more along human lines, under my proposal, may wish to join the Community Team. > I think we think of the community team as mostly about the CoC Please keep an open mind. The Community Team would quickly shed its image of a pronoun-wielding social reformer and become a universally respected arbiter of justice—especially when elected. They have the human touch. Debian needs more empathy. People are not logical like machines. They are burdened by ideas and have fears and hopes. Plus, some do not lightheartedly express how they feel. Solving conflicts in a unified system brings all that out in one place, and makes peace. Kind regards Felix Lechner
Dispute resolution in Debian
Dear Technical Committee, In deviation from community standards, I top-post. I hope it provides a simple and coherent narrative that is also compelling. You should be familiar with the issues raised in Sean's email. I would model access to conflict resolution on the US courts. There should be two levels of jurisprudence: One is quick and easily like small claims, the other is for appeals. Both can issue rulings that bind everyone, including delegates and the DPL. Private side conversations should remain off-limits. They create an incurable attack surface that lowers credibility. Decision makers who expressed an opinion outside the official process must recuse themselves. To seek their opinion, please file a case. As Sean wrote, many problems at Debian are social in nature, I would make the Community Team the first legal instance before a party can appeal to the Technical Committee. Cases at Community Team level should be heard before a single member unless someone requests a hearing en banc. That effectively makes the Technical Committee Debian's Supreme Court (which hears all cases). In some way, this resembles Sean's Proposal 2. Like any court, the Community Team and Technical Committee should be able provide independent solutions of their own design. Ideally, the judges at the lower level, i.e. the Community Team, would be elected. Thank you for your hard work on the Technical Committee! Kind regards Felix Lechner -- Forwarded message - From: Sean Whitton Date: Sun, Jul 26, 2020 at 1:37 PM Subject: CTTE requesting questions for DebConf20 BoF To: Hello everyone, ... The technical committee has served the project for many years, acting as a conflict resolution body of last resort. The TC is established in the Debian Constitution,[2] which means that it's a highly regulated body and it's hard to change it. The current setup of the TC has several problems that need to be addressed. This document is split between first a description of the current situation and the problems identified, followed by a bunch of different proposals that we could implement to try to solve said problems. Problems Perception -- Because everything is mandated to be public, discussions must take place in a public forum where anybody can jump in and add wood to the fire. This can be very taxing, so there are community members that just check out and refuse to participate in the discussion even when their input would be valuable. And even those who participate can feel that their voice is being drowned by whoever sends the most emails. The committee strives to hear all opinions equally regardless of how many emails were sent, but the participants of the discussion can still end up with a bitter taste because of how it devolved. Going to the TC is seen as a nuclear option, as a stick to beat others with. This is partly because of how the Constitution establishes that the role of the committee if to be a last resort decision maker. But also because of historical reasons that are very hard to change, even when the committee members have all changed by now. People don't like being on the "losing" side of a decision, but even if they are on the "winning" side of it, lots of people don't want the level of flamewar and attention that an issue raised to the TC brings. Some people would rather orphan a package than participate in a discussion with the TC. Social vs Technical --- Most of the problems that reach the TC are not purely technical. There's a lot of "human stuff" going on. People with different goals or interests that fail to agree on how to move forward, but the conflict is not at the technical side. For discussions around social issues, discussing in the open is like being on public trial. It's very stressful and very hard to find a good resolution. On top of this, because this is the *Technical* committee, we're forced to focus on the technical side of a problem. In various occasions this means that there's really no solution we can offer. We're not explicit mediators, we don't have the authority to be mediators and we're definitely not set up in a way that leads to good mediation outcomes. Speed - In many occasions in the past, the committee took too long to make a decision. There's many reasons for this. Perhaps we wanted to be thorough in looking at the problem from all angles. Perhaps we wanted to explore different alternatives to solve the issue. Perhaps we were busy with other priorities and the discussion just moved slowly. Whatever the case, the long time to resolution also devalues the role that the committee has in solving issues (technical or not technical). If the TC is going to be of value to the project it needs to act quickly when dealing with urgent matters (for example, right before a freeze). It's important to note that the questions brought to the TC typically have no easy and quick solution, that's w
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hi, On Wed, Nov 18, 2020 at 10:21 AM Matthew Vernon wrote: > > I invite the technical committee to rule that: What a great read! This message must be among the best prepared, and most polite, to come before the committee. Kind regards, Felix Lechner
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hi, On Wed, Nov 18, 2020 at 11:33 PM Josh Triplett wrote: > > I do not believe it falls within the scope of the technical committee > to override a decision already decided by a project-wide GR In the State of California we follow such a strict interpretation of ballot measures. While consistent with direct democracy, it is also widely blamed for a dysfunctional state government. [1] But even here, courts enjoy some leeway. Please consider Proposition 8. Widely publicized in 2008, it was a successful ballot initiative that banned same-sex marriage by amending the state constitution (yes, California can be conservative). A Federal District Court later ordered the State to ignore the people. While the appeals failed on narrow grounds, the original opinion that ended up standing was described as ruling that "the amendment was unconstitutional under both the Due Process and Equal Protection Clauses of the Fourteenth Amendment, since it removed rights from a disfavored class with no rational basis." [2] In Debian, users of 'sysvinit' strike me as such a "disfavored class". Personally, I find it outdated and would never use it again, yet based on how often the topic reappears, there are clearly people who think differently. Now similarly to Proposition 8, I believe the GR should bind the DPL and all delegates—but not the Technical Committee. It is our supreme court. Like Josh's message, I make a point of procedure. The Technical Committee should be free to rule. They could also decline, for example by citing the GR. As an aside, the Debian Constitution lacks any elevating language that by itself would make such daring projections of universal justice possible. In fact, our constitution mentions no "rights" whatsoever (except for a copyright notice at the bottom). That is why I had to resort to an outside precedent to make my point. The constitution's text also leads me to renew my call: Let's rewrite Debian's foundational documents together to promulgate inspiring ideals we can hold up in the sky. [1] https://openlibrary.org/works/OL16420003W/California_crackup [2] https://guides.ll.georgetown.edu/c.php?g=592919=4182204 [3] https://lists.debian.org/debian-devel/2014/11/msg00174.html Kind regards, Felix Lechner
Re: Bug#971515: kubernetes: excessive vendoring (private libraries)
Hi Dmitry, On Tue, Oct 20, 2020 at 5:24 PM Dmitry Smirnov wrote: > > Let's not attempt to fabricate perception of consensus please. Consensus is a worthy goal and perhaps even possible, per below. > We favour technical elegance > often in expense of maintainers' comfort. Is our approach really either one of those? I think our response to the vendoring explosion is at odds with the trends in many languages. It's time to retool. At the two ends of the solution spectrum, I see 1. Fully vendored source packages; or 2. A packaging system that allows different vendor versions to co-exist. Either one allows dependent sources to consume whichever versions they require, but in my view solution (2) is otherwise superior---provided that the packaging process is automated. (A language's build system also has to distinguish the installed versions.) For each language so affected, could we make (2) our goal, and allow (1) until then? Kind regards Felix Lechner
Re: Bug#971515: kubernetes: excessive vendoring (private libraries)
Hi Dmitry, On Wed, Oct 21, 2020 at 12:50 AM Dmitry Smirnov wrote: > > Yes, at first there will > be a significant effort but then it will become easier. I know you put a lot of effort in (as did Michael Stapelberg, with whom I spent some time before he left), but I don't think our current approach makes anything easy. It is also why the world is moving in another direction. > You are advocating for disruptive > changes therefore your proposed theoretical solutions have to be available as > a proof of concept for review. Did you catch the part about different versions being co-installable? It would be similar to the freedom we grant to major numbers of shared object libraries. My point is theoretical only because we do not presently have it. > Personally I'm not satisfied with either of those inferior proposals. How is the second one inferior, please? I think it includes a crucial missing feature (co-installable versions). > Look how many packages we already have: > > > https://qa.debian.org/developer.php?login=pkg-go-maintainers%40lists.alioth.debian.org+team%2Bpkg-go%40tracker.debian.org It's an impressive list; thank you for forwarding it. I am proud to be on the Golang team. :) > In the meantime you could follow the established practice that is > demonstrated to be working on several packaged heavy Golang applications. Not sure about heavy Golang applications, but our established practice does work well for the relatively lightweight 'gocryptfs', which I maintain. That source moves very fast. I often have problems finding the proper go-fuse or xattr prerequisite required for a new version. Sometimes they are incompatible with the needs of other packages in the archive. As a side note, several "library" packages that gocryptfs relies on should really be marked "Architecture: any" to exercise their test suites properly. It is another example of the impedance mismatch in our current approach. We are confusing sources and libraries, and our method of shoehorning one into the other ought to be rethought. > Besides un-vendoring libraries can prevent some CVE issues as well. Packages could declare vendored sources (or Lintian could scan for them) for an effective match with their security status. > If we tolerate full vendoring now, because "there is no better way" yet, then > there will be no better way for sure. Please do not despair. I offered full vendoring only in the interest of compromise, which I believe is a worthwhile goal just like the consensus we are working on. As a project, we are looking for a better endpoint together. Kind regards Felix Lechner
Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages
Hi, Sorry to comment so late. A meeting about this bug may already be in progress. On Sat, Jan 16, 2021 at 4:15 AM Matthew Vernon wrote: > > The maintainer won't talk to me, nor will they engage with me (or anyone > else) on this thread, though they will it seems talk to the TC in private. In most places, a failure to respond would result in a default judgment for the aggrieved party—in this case Matthew. Here, the situation here is more complicated. There was a private communication with the committee, but such side conversations are unfair: How can Matthew ever feel that justice was served? I would personally not feel closure unless I saw all such communications and had an opportunity to respond. Secrecy, if it is really needed, should instead be implemented by requiring all parties involved to keep sealed records confidential. I urge the committee to please reconsider its willingness to engage with one party without the other present. The dignity of the Technical Committee—Debian's highest and most hallowed body—could suffer. Thank you! Kind regards Felix Lechner
Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages
Hi, On Tue, Jan 26, 2021 at 5:48 PM Sandro Tosi wrote: > > the ability to talk privately with the committee is something CTTE has > allowed for a long time Debian has many great traditions, but the Magna Carta is much older. I found a great article about it ([1], p. 5): "the simple human need for fairness, reflected in western jurisprudence since at least 1215 when it was pronounced in the Magna Carta, underlies the legal concerns about ex parte communications during administrative decisionmaking processes. Fairness certainly requires an impartial decisionmaker, and often the appearance of impartiality can become as important a factor in the legal review of fairness as actual impartiality." The State of Hawai'i publishes a simpler guidance prohibiting private communications with a judge. [2] Kind regards Felix Lechner [1] https://www.cacities.org/Resources-Documents/Member-Engagement/Professional-Departments/City-Attorneys/Library/2016/Annual-2016/10-2016-Annual_Calonne_Lets-Ex-Parte!-The-Limits-a.aspx [2] https://www.courts.state.hi.us/self-help/exparte/ex_parte_contact
Bug#978636: move to merged-usr-only?
Hi, On Tue, Jan 26, 2021 at 3:45 AM Wouter Verhelst wrote: > > You can start writing a lintian check today Here is a Lintian check that follows Ansgar's specification in the second d-d thead. Of course, it will not be merged until the project works out a suitable consensus on this controversial topic: https://salsa.debian.org/lintian/lintian/-/merge_requests/349 Thank you! Kind regards Felix Lechner
Bug#994275: Reverting breaking changes in debianutils
Hi, On Mon, Oct 11, 2021 at 1:45 AM Sebastian Ramacher wrote: > > the lintian tag > possibly-insecure-handling-of-tmp-files-in-maintainer-script still > recommend "tempfile or mktemp". Lintian's last remaining reference to 'tempfile' was dropped. [1] The updated tag description is now live on our website. [2] Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/commit/af93172c7a9ef326a68fd337c5089c52b74eb3f5 [2] https://lintian.debian.org/tags/possibly-insecure-handling-of-tmp-files-in-maintainer-script
Bug#1007717: Native source package format with non-native version
Hi, On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery wrote: > > We should define native and non-native > packages in terms of version numbers, and allow both native and non-native > packages to use single-tarball source package formats. I co-maintaintain several Debian-internal tools, and that description is backwards. "Native" sources are characterized by their lack of Debian patches. On that note, the term "native" is also not great. The words "patched" and "unpatched" describe the relationship between sources in the archive and their respective upstreams more accurately. As for version strings, we need no additional restrictions. The use of patches is declared in source format 3.0. Some folks even use Debian revisions for unpatched sources. [1] Most significantly, Lintian's parser is unable to deduce "nativeness" from the version number. The native status is a required input! [2] Please do not "define" a source's patch status via the version string. It's what got us here in the first place. Debian version numbers are complicated enough already. Thank you! Kind regards, Felix Lechner [1] for example, https://tracker.debian.org/pkg/python3-defaults [2] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Changelog/Version.pm#L79-80
Bug#1007717: Native source package format with non-native version
Hi Ian, On Tue, Mar 15, 2022 at 11:54 AM Ian Jackson wrote: > > I do remember this coming up > before, but I don't seem to be able to find a record of it now. Perhaps you were thinking about this discussion in a bug against Lintian? Ideally I would like dpkg-source to permit source format `3.0 (native)' packages to have a non-native version number. [1] Kind regards, Felix Lechner [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953554#30
Bug#1007717: Native source package format with non-native version
Hi, On Thu, Mar 17, 2022 at 11:57 AM Russ Allbery wrote: > > source package format While everyone is receptive to new labels, I prefer "upload format" or "archive format". Either one helps us to distinguish the intermediate product from any workflow objects a maintainer may have. > single tarball as a source package format It is also not necessary to "define" unpatched sources in the archive by how many tarballs they have, or any tarballs at all. In fact, I wrote a manifest utility that could one day replace tarball signatures with per-file hashes. The latter remain useful even when sources are repackaged, because manifests can be cryptographically daisy-chained in a "chain of custody." Of course, they would be more often used for patched upload formats. Kind regards Felix Lechner
Bug#994388: dpkg currently warning about merged-usr systems
Hi, On Fri, Apr 8, 2022 at 1:48 AM Wouter Verhelst wrote: > > The nuclear option here is obviously to take maintenance of dpkg away > from the dpkg maintainer unless and until he decides to follow the > rules. This song is for Guillem: https://www.youtube.com/watch?v=cnoX81TC6jk Kind regards, Felix Lechner
