I've seen this kind of thing happen not through bias but because good people know good people, where by "good" I mean highly competent. They knew each other through university and other regional connections, so they happened to have the same ethnicity as one might expect from such a regional commonality. One got hired, referred another, and it cascaded. They were great to work with and highly competent, so I don't think there was bias even though it might appear that they're was.
All the items being discussed are useful things to think about and cover in the commit message. Certainly if after reading a commit message I do not know what was intended (eg. “is this a refactor that is not intended to change behaviour or not?”) then the commit message is missing something. What I object to is overloading all of this into the first line. The subject should be reserved for the most relevant information and is limited in length. Forcing committers to collapse a bunch of metadata into it makes it less useful for that purpose.
> sometimes resulting in arguments with authors that the editors need to smooth over
This is an understatement. A friend of mine is a published author in a field that requires correctness. The "legions of people" all got in the way, continuously introducing errors and unable to use a system with any kind of change control, so my friend had to keep rechecking the whole thing and finding further errors that had been introduced without being told about them. This included introducing errors of fact as well as simple things such as not fixing references to areas that they themselves changed. This was from an established publishing house and apparently this is normal. As far as I can tell, the roles that once added professionalism have been eroded both in skill and in budget, such that now they fail to make use of technology and just get in the way. They didn't seem to add any value in my friend's case, anyway. Perhaps it does add still add value to authors who start with a low standard of work. And perhaps the quality of publishers varies massively, resulting in hugely different experiences.
> ...upstream package maintainers who are expected to deal with bug reports from ancient versions...
They are not expected to deal with this. This is the responsibility of the Debian package maintainer.
If you (as an upstream) licensed your software in a manner that allows Debian to do what it does, and they do this to serve their users who actually want that, you are wrong to then complain about it.
If you don't want this, don't license your software like that, and Debian and their users will use some other software instead.
If package maintainers were always fine upstanding package maintainers as you imagine them to be I wouldn't be complaining, but I have in fact had Debian ship my software and screw it up and gotten a flood of bug reports, so... :)
I think you need to chill out. Relicensing the way you suggest would be _quite_ the hostile act, and I'm not going to that either. But I am an engineer, so of course I'm going to talk about engineering best practices when it comes up.
You don't have to take it as an attack on your favorite distro - that really does pee in the pool of the upstream/downstream relationship between distros and their upstream.
> I am an engineer, so of course I'm going to talk about engineering best practices when it comes up.
The trouble is you seem to be assuming that best practices for you, in your opinion, also apply to everyone else. They don't. Not everyone sees things the way you do or is facing the same issues or is making the same set of tradeoffs. There are downsides to what debian does but there are also upsides.
At this point, given the plethora of high quality options available as well as how easy it is to mix and match them on the same system thanks to container-related utilities and common practices I really don't think there's any room for someone who doesn't like the debian model (ie in general, as opposed to targeted objections) to complain about how they do things. If you want cutting edge userspace on debian stable at this point you have at least 3 options between nix, guix, and gentoo. There's also flatpak and snap which come built in.
We're in the middle of a huge spike in LLM discovered security vulnerabilities, which means not everything will get assigned a CVE, a lot of people are watching repositories to look for exploitable bugs, and in the frenzy of backporting that people are now having to do things will get missed.
I wager it's only a matter of time before we see a mass rooting event that hits Debian hard while everyone running something more modern has already been patched.
I think that might be what cuts down on the grandstanding about "freedoms" and "that's how we've always done things". You certainly are, up until it becomes a public nuisance.
No one is grandstanding about freedom here though? I claimed that the approach debian takes has both upsides and downsides. I stand by that. Personally I pull my networked services from testing while running stable on the host. I absolutely do not want constant churn of the filesystem code or drivers on my devices but I would also prefer not to run some franken build of ssh or apache or what have you. However I can also sympathize with others who need a more structured process and substantial lead time in staging prior to making major changes to production.
Why would you expect LLMs not to be simultaneously leveraged to catch backports that were missed or inadvertently broken?
Given recent headlines I think it's far more likely that we see a mass rooting event hit one or more of the bleeding edge rolling release distros or language ecosystems due to supply chain compromise. Running slightly out of date software has never been more attractive.
Refactoring and rewrites prove time and time again that they also introduce new bugs and changes in behaviour that users of stable releases do not want.
For what you want, there are other distributions for that. Debian also has stable-backports that does what you want.
No need to rage on distributions that also provide exactly what their users want.
Debian has had a better "software supply chain" posture than any other player in the ecosystem since before the turn of the century. While we all face the risk of malware from upstream, Debian is the least at risk of being affected by it. See for example the stream of issues from npm et al. None of it has affected Debian.
It's npm that's affected, therefore it's not even considered when choosing language/ecosystem for writing distro tools. You'll find no sane distro writing package manager in javascript precisely to avoid this joke of a supply chain.
I quite like the OpenBSD approach to Go and Rust projects in ports. They store all the dependencies and their hashes in the build recipe, not trusting the project ones. And they’re more readable.
Here is jujutsu’s list of dependencies[0] and their hashes[1]. As an aside, that’s why I don’t like those packages managers. Something like Python’s numpy or lib curl, get sliced into atomic portions.
> It boggles my mind to see legal firms increasingly rely on consumer-oriented cloud services while acting like they are retaining custody of the data entrusted to them.
My theory is that lawyers tend to lean on the law to protect them more than others might. "I can ensure that it would be illegal for them to them to expose this data; therefore this method is safe" vs. "If they expose this data, is that a situation I want to deal with?".
I've seen this kind of thing happen not through bias but because good people know good people, where by "good" I mean highly competent. They knew each other through university and other regional connections, so they happened to have the same ethnicity as one might expect from such a regional commonality. One got hired, referred another, and it cascaded. They were great to work with and highly competent, so I don't think there was bias even though it might appear that they're was.
reply