Ah, the Microsoft tradition of always having the wrong priorities.

I wouldn’t be too hard on Microsoft. The requirement to curate public package repositories only emerged somewhat recently, as demonstrated by the likes of npm, and putting in place a process to audit and pull out offending packages might not be straight-forward.

I think the main take on this is to learn the lesson that it is not safe to install random software you come across online. Is this lesson new, though?

it’s about deploying multiple versions of software to development and production environments.

What do you think a package is used for? I mean, what do you think “delivery” in “continuous delivery” means, and what’s it’s relationship with the deployment stage?

Again, a cursory search for the topic would stop you from wasting time trying to reinvent the wheel.

https://wiki.debian.org/DebianAlternatives

Deviam packages support pre and post install scripts. You can also bundle a systemd service with your Deb packages. You can install multiple alternatives of the same package and have Debian switch between them seemlessly. All this is already available by default for over a decade.

I feel this sort of endeavour is just a poorly researches attempt at reinventing the wheel. Packaging formats such as Debian’s .DEB format consist basically of the directory tree structure to be deployed archived with Zip along with a couple of metadata files. It’s not rocket science. In contrast, these tricks sound like overcomplicated hacks.

Logging in local time is fine as long as the offset is marked.

I get your point, but that’s just UTC with extra steps. I feel that there’s no valid justification for using two entries instead of just one.

The Philosophy section has quite a few wonky arguments; I’d skip it altogether.

I agree. I wish they moved that to a standalone section so that it could be easily skipable. Reference docs can and should have a rationale, but a lengthy rant is not what leads people to the site.

It might be just me, but I think key bindings should definitely not be easily configurable or even changed across release. They should.be standard, pervasive, and set in stone.

For those who really want configurable key bindings in Firefox I think there are already a couple of extensions that do this for you.

This is a really important principle of making APIs that people don’t really talk about. There’s a fine balance between hardcoded literals and full-gui options menu.

I think this principle might fly under some people’s radar because it has been a solved problem for decades.

Even Makefiles don’t require changes to the file to be configured. They take environment variables as input parameters, an approach that directly and indirectly permeated into high-level build systems. One example is the pervasive use of the VERBOSE flag.

After all these years I only had to tweak build config files by hand when I wanted them to do something that they were not designed to do. All build tools I know don’t require it. The ones linked with IDEs already provide GUIs designed with this in mind.

Fair enough.

Because you’d have to stash your modifications to be able to switch branch.

OP said nothing about stashing, only committing WIP commits to feature branches. I don’t think none of your remarks apply, because if you really need stuff from the WIP commits you can also cherry-pick them or checkout specific files.

git switch and git restore were introduced way back in 2019. I don’t think they count as new.

When you have 1000+ Cypress tests, for example, it takes time to run, plain and simple.

It’s one thing to claim that tests need time to run.

It’s an entirely different thing to claim that the time it takes to run tests is proportional to test coverage.

More often than not, you have massively expensive and naive test fixtures in place that act as performance boat anchors and are massive bottlenecks. Thousands of tests run instantly if each test takes around a few milliseconds to run. For perspective, the round trip of network request that crosses the world is around a couple of hundreds of milliseconds. A thousand of sequential requests takes only a couple of minutes. If each of your tests takes that long to run, your tests are fundamentally broken.

Why do you think test times are proportional to coverage rates?

If anything, I thing Stack Overflow replaced Usenet as the source of informal technical advise.

Never heard of Experts Exchange beyond the jokes.

The report of the bug is not the problem.

People in this thread are arguing otherwise.

The prioritization, (…)

Users filing tickets do not prioritize jack shit. That’s not how it works. At best they mention an issue is important to them. Not even in big corporations dealing with internal tickets things work like that. The responsibility of prioritizing work lies on the project owners, exclusively.

and demand that it be fixed quickly (…

Literally what each and every single user affected by a problem asks in their bug reports.

Again, why do you feel this is something that warrants your outrage?

That’s not even the issue. Nobody cares that MS is using ffmpeg.

You surely haven’t been paying attention to this thread.

It’s just rude to have as much money as MS does (…)

Seriously? Is this the argument you’re going with?

Unbelievable.

special treatment for free

They filed a bug report, with a reproducible bug.

Some guides on how to contribute to FLOSS projects even go as far as listing this as one of the main ways to contribute to projects.

But here you are, describing a run-of-the-mill bug report, filed among hundreds of bug reports, in a ticketing system explicitly opened to the public so that everyone and anyone in the world could file bug reports, as a request for “special treatment for free”.

Do you think every single person filing a bug report is asking to be given special treatment for free? Everyone’s bug is very important to them too. What makes you think this case is special or even any different?

They made a demand, based on a product launch time line.

If you read the same bug report I read, you wouldn’t make that claim. They expressed their personal needs, which are their own and theirs alone, and don’t extend beyond their personal roadmap.

This is absurdly rude (…)

The issue stated they found a bug that they had to get fixed. They said it was important to them for their own personal reasons. It’s laughable to describe what amounts to a run-of-the-mill bug report as “absurdly rude”.

Do you actually work on software for a living?

treating open source like slave labor

I’m sorry, what? Do you even pay attention to what you’re writing?

I have experience contributing to a semi successful FLOSS project, one that I’m 100% certain you use daily.

I’m not talking about contributing. A drive-by PR does not make you a maintainer, nor gets you to triage bugs. The problems I mention are the bread and butter of maintainers engaged in community support, which you would know if you had any semblance of experience in the subject.

And the truth of the matter is that your choice to use weasel words as seaways to a rant to go off on a tangent demonstrates your complete lack of insight and experience in the subject.

The maintainer is a human that needs to eat every day, and not just whenever their services are needed.

That’s perfectly fine.

But the maintainer is indeed explicitly making his work available to the public for free and without any expectation of retribution of any kind, isn’t it?

And this isn’t exactly something new or recent or novel, right? That’s been going on for many years.

What changed? Did anything changed at all, even?

It’s not that they made a big report. It’s that they, a multi-billion dollar company,

Why do you think this is even relevant? Again, does your attitude towards a run of the mill ticket change if you change who filed it? Why are you outraged because some random grunt from company A or B filed an issue instead of random joe X? Would you be commenting here if the very same person who filed the issue had done so with a personal account without identifying or disclosing their employer?

It’s that they do nothing for the project but expect the world from it.

I’m sorry, where does ffmpeg demand contributions or retributions from anyone who downloads or distributes their project? Aren’t they explicitly distributing their work without asking anyone to do or give anything in return? I mean, isn’t that the whole point of FLOSS?

More surprisingly, we see guides on how to contribute to FLOSS projects which state in no uncertain terms that filing bug reports and even run exploratory tests to give feedback to maintainers counts as contributing to the project, but somehow you’ve flipped over even the core principles to make it sound like a cash grab.