Bassi: Dev v Ops

I doubt that perspective is anywhere near universal. Lots and lots of major projects are moving to meson these days, mostly from autotools and not cmake but we won't have a single leader in this space anytime soon.

Oh, come now. This barely registers on the scale.

While I personally disagree that "making their software easier to build by others" is the _most_ important thing an upstream developer can do, it's fairly high up there, because everyone benefits from more frictionless builds, including (and especially) the original developer, because it enables all manner of side denefits.

It's in everyone's interest -- upstream, downstream, and indirectly, end-users too, that the software be easily built. This reduces the burden on everyone -- upstream doesn't have to put as much work into building it themselves, downstream can re-build it effortlessly, and the end-user benefits as releases/builds can be made more frequent without undue burden.

A great example of this is Libreoffice (and its predecessor, go-OOo). They put a lot of effort into making the original OpenOffice codebase easier to build, which in turn allowed them to vastly speed up development cycles to the point where they generate full nightly (regression tested!) builds for every platform they support. Meanwhile, the complex original build process left ApacheOpenOffice unable to perform complete builds for several months, and even after they finally got their security fix release out a year after the code change was made, the underlying situation is no better, greatly raising the bar for would-be contributors.

Given the choice, why would anyone chose to contribute to AOO over LO, given the latter's vastly superior developer experience? And as an end-user, can anyone say with a straight face that AOO's approach has led to any sort of benefit?

So yes, you're correct in that an upstream developer's primary job is to make software that scratches their own itch, and F/OSS or not, they owe nothing more to anyone (I've said something similar here many times, including earlier in this thread). But making something easy for others to build (and thus, contribute to) greatly improves the developer experience, which surely improves the end-user experience if only because it leads to better software, delivered more rapidly. That is hardly an arrogant position to take.

> There is no way outside of the most remarkably toxic and self-centred mental state, that it could be reasonably be said to be to please distribution maintainers. And distribution maintainers who can't grasp that will, I guess, continue to be angry and baffled by the way they become less and less relevant.

Nine times out of ten, the stuff distribution maintainers ask for will, in the longer run, disproportionally reduce the support burden on the upstream author. Or are you seriously saying that shouldering all the stuff that distribution maintainers currently do is somehow less work?

When it's framed as an isolated statement without context, it certainly does come across that way. Don't do that?

Only if you simultaneously archive the set of source files and some records about the environment you used for that particular build. You know, like distributions do for every single package they build, if only to be able to point at the source corresponding to a particular binary package.

If you don't do that, bundling just the object code actually makes the problem worse. People might start to rely on the program just to get hit by the shit hammer months down the road when they realize it can't be rebuilt from sources anymore and no one really knows what it was built from anyway because the build happened on some developer's personal laptop that suffered a coffee-related death long ago.

If you have the resources to pull these things off (and others, like running your builds and test suites on all the kinds of hardware that people care about), then good for you. Many upstreams don't, despite producing useful software. That's where distributions tend to add a lot of value.

Insulting, absolutely (and deservedly so!) but bullshit, nope -- two decades' experience in the trenches has shown me that "quality" is nearly always at the very bottom of the priority pile -- especially if it has implications outside the application writer's own (metaphorical) sandbox or will impact short-term schedule/deliverables (and remember, time is money!)

> Anyway, you're wrong all the way down: an OS is something for applications to run on, not the combination of the thing the applications run on and the applications themselves.

You're correct -- but in only in the same way that the ISO/OSI model relates to how network stacks are actually written. In the real world, the "operating system" is everything that you can count on being present as an application writer.

This includes an ever-growing pile of libraries that aren't technically the OS (according to the textbook definition) but aren't part of the application either -- minor stuff like language runtimes, graphics/multimedia libraries, UI toolkits (including web browser widgets), database engines, location services.. the list goes on and on, and they're all part of the "operating system" as actually shipped to an end-user, with each successive version of said OS bundling ever more stuff.

Oh, absolutely. Depending on who you ask, the distro model is either over-specified or under-specified. Or both.

> But eventually people are just going to continue making more and more elaborate work-arounds until somebody stumbles on a solution that will allow users to by-pass distribution repositories completely for most of their software.

That's not going to happen, for one very simple reason -- because it's a great deal of work, from a whole lot of people, that needs to be done in a coordinated manner -- And none of that is going to do or fund itself.

> Putting your head in the sand and continuously beating on the drum of 'quality' isn't actually going to get anybody quality or solve these issues. It's just ignoring reality at this point.

And it's willfully idiotic to pretend that the 'quality' drum didn't come out of utter necessity -- something that even TFA acknowledges.

> Reviewing and curating the software is not remotely close to what the problem is here. If distributions want to have a hand in making sure that application quality is ensured they are going to have to adapt to the world rather then demanding the world adapt to them.

Let me remind you what you wrote: "The real problem is that distribution package managers are losing their relevance because they are stuck on a mindset that says that the _ONLY_ way that they can ensure quality on the OS is to be the gatekeepers between what application developers make and what end users consume."

Literally everything you wrote in these last two paragraphs is what all major/mainstream platforms are either already doing (Apple, MS) or attempting to do (Google). They even proclaim their gatekeeper status as a feature, necessary "to ensure quality" on their platform. And I might add, all three of those players are forcing the world to adapt to them, rather than the other way around! (Apple is the most egregious of these players; Witness every new iOS version!)

So, please explain how distros' "quality" practices are different (in principle) from Apple, MS, or Google's, and how eliminating them will result in a better end-user experience -- because a better end-user experience is supposedly the whole point.

CVS behaviour was fixed first. When Emacs 21 was removed, the bug was reassigned to Emacs 24. There's a note that says that the problem wasn't found again when it was tested with Emacs 24 and a note that it was fixed by the time of Emacs 24.4.

There's been a tidy up of the bug tracking system and a mass closure of old bugs that no longer apply to older versions - there's not a lot of point in keeping bugs open that were not release critical for obsolete versions of Debian. So yes, this was fixed a few years ago.

If you were using the upstream version - yes, this might still be a bug, depending on when you self-installed Emacs, whether you built it from source etc But this is where the distributions maintaining stuff and tracking issues adds value and is different from, say, grabbing a random Github repository and building it / a small app to use my Android phone as a compass or whatever else you might consider.

> That is not necessarily true. Proof: this hasn't happened for Web applications.

What about all the standartisation groups? Aren't they just that? An effort to agree on common rules?

Also, the average quality of web applications is quite low: you don't have the same browser on the same OS and the same device as the funky dev? Too bad, because you should /upgrade/ (i.e. throw away your device). Or downgrade to a "stable" browser. With "stable" Java. Or Flash. Or whatever. It's quite a colorful mess IMHO so I'm not sure the web serves as a useful example to demonstrate how things "are working" despite there not being a gatekeeper that mandates quality standards.

Sourceforge has done ratings for years, and now Gnome has its own "Software" app with a rating system. I never found these useful, but a person new to free software might, I guess, before they realize it's not necessary.

Can these vendors find the important comments? Can other users? Can you do *anything* useful with a multi-gigabyte-long shoutbox, 5 comments per page and no search function?

Can you find the Play Store version of Debian's “Chromium keeps my computer's microphone hot at all times without warning” whistleblowing thread?

No, the UI's built to “optimize engagement” or some other meaningless SEO word salad, while keeping all the cries for help safely tucked “below the fold” alongside a sea of unintelligible trash and automated spam. These systems are designed to throw upset people into a tarpit, so as to prevent them from going out and actually making a difference.

By the way, this “proles and animals are free” mentality you're espousing is downright terrifying. We have enough of that empathy-devoid insanity in the world as it is, keep it the hell out of Free Software.

Fedora, Suse, and Ubuntu have such infrastructure for others to use. I believe there's no "private" option for the first two, though I think Ubuntu has some sort of commercial infrastructure-as-a-service offering)

> The goal is to start having libraries that don't break backwards compatibility at a whim. So libraries that are using these best practices (outlined in the article) are promoted and considered safe to use for 3rd party.

Application writers can and will use whatever libraries they want. If it's not part of the distro/runtime/whatever, they'll just bundle it instead. And even if the library is already there, they may want to modify it in some incompatible-with-upstream way and bundle it anyway. (I'm looking at you, Chrome!)

I also don't think it is "hilarious" that people are pushed into having to use GMail because various mail/groupware applications were almost abandoned by otherwise well-resourced organisations. Maybe you can think of at least one example.

Or that people are obliged to work on platforms like Google Docs (here I obviously also include whatever Microsoft's product is), where data protection regulations are most likely being broken, through genuine or feigned ignorance, the latter sometimes through agreements that tell the customer what they/their lawyers want to hear.

Then the new Flatpak is uploaded to a "testing" OSTree repo, an email is sent to the people interested to test new versions, and if the new version works fine, the Flatpak can be moved to production.

Should be entirely doable.

> Suddenly you need to build a new Flatpak when your dependencies have changed

Quite the contrary, you generally *don't* need to do anything because you update dependencies on *your* schedule, i.e. when you need specific features or fixes. And when you do those updates, you test them thoroughly ... which distro vendors don't do.

The exception is security updates; but then, if you're an application vendor that supports at least one platform where you have to bundle dependencies (i.e. pretty much anything other than desktop Linux), then you have to track security issues in your dependencies and make releases containing those fixes for your non-desktop-Linux users. And if you're doing that, doing releases for your desktop Linux users at the same time is not that much extra work.

So if you don't use that particular distribution, it's a big hassle.

But more to the point, you are describing the process from a professional developer's viewpoint. You have the tooling all set up.

Imagine the process from an amateur's perspective. You are writing software for a particular use that you have domain-specific interest and expertise. You get it working and well tested on your system. You figure out all the dependencies. Now you want to offer it to the world. What dependencies does each distro need? How do they label them? It's a lot of work and not much pleasure, and a big disincentive to improve your application since not only do you need to test functionality, you also need to test each packaging.

Clearly it's worth doing, but it could be much easier.