3 ms·

Not sure why FFmpeg is milking karma here. The very next comment on the thread shows that the library introduced a breaking change by changing a default behavio

Not sure why FFmpeg is milking karma here. The very next comment on the thread shows that the library introduced a breaking change by changing a default behaviour, which can be restored with a new flag: > Use -data_field first as decoder option in CLI. Default value was changed from first to auto in latest FFmpeg version. Or modify AVOption of same name in API for this decoder. Which seems to have solved the problem. I have no reason to believe that the writer of the tweet is lying, but I also don't see evidence in this linked thread that Microsoft offered a one-time payment. I do agree that demanding urgent support requires you to be paying a long term support contract. And I also think the Microsoft Engineer completely blew this interaction by name dropping his company. The bug is a bug whether it affects Microsoft or Joe Blow of Illinois. There should be no reason to expect that the bug is High Priority because it's affecting Microsoft. However I also think it's possible to see that the bug is high priority despite affecting Microsoft.

Arnavion 3y ago
I think it's reasonable to *request* that a bug be treated as "High Priority because it affects my $IMPORTANT_USE_CASE". Who knows, the devs might sympathize and actually prioritize it, say because they were under the impression that it was a minor bug / rare corner case. But it's also possible that they don't, so you just shouldn't have any expectation that your request will be accepted.
ibejoeb 3y ago
That doesn't sounds like a bug. It sounds more like a change that's not backward-compatible. Who forced Microsoft to switch versions? I'm sure many of us have been on both sides of this situation. Sometimes you have to deal with breaking changes, and sometimes you want to make them to advance your product. I think it's fair enough to request an LTS contract if you want LTS.
apimade 3y ago
I don't see how a design decision made by the maintainers of this project, which is documented as version changes are made - and completely transparent given the nature of the project (open-source), constitutes a high priority support request from a software engineer external to the project? Sure, it's a pain for adopters who were dependent on the feature, but you can't criticise design decisions made by someone who offers your software for free. You can, however, fork it and take your own path with the software. Are you saying because a new version breaks the current build of a downstream proprietary application, that should constitute a high priority support request from the maintainers of the project? That doesn't compute with me. If they were paying for forwards-compatibility and had that expectation in a contract, sure. But they should be able to make changes they see fit without having to make trade-offs to ensure future compatibility with an Enterprise organisation's product. At that point they're basically making design decisions to suit the Enterprise, at which case - you're not just free resources for software engineering for the organisation, you're actively pushing your project to be vendor-compatible. I could see this reasoning if your project is largely funded by them (Chromium), but in this case, they're not.

Arnavion 3y ago

I think it's reasonable to *request* that a bug be treated as "High Priority because it affects my $IMPORTANT_USE_CASE". Who knows, the devs might sympathize and actually prioritize it, say because they were under the impression that it was a minor bug / rare corner case. But it's also possible that they don't, so you just shouldn't have any expectation that your request will be accepted.

ibejoeb 3y ago

That doesn't sounds like a bug. It sounds more like a change that's not backward-compatible. Who forced Microsoft to switch versions? I'm sure many of us have been on both sides of this situation. Sometimes you have to deal with breaking changes, and sometimes you want to make them to advance your product. I think it's fair enough to request an LTS contract if you want LTS.

apimade 3y ago

I don't see how a design decision made by the maintainers of this project, which is documented as version changes are made - and completely transparent given the nature of the project (open-source), constitutes a high priority support request from a software engineer external to the project? Sure, it's a pain for adopters who were dependent on the feature, but you can't criticise design decisions made by someone who offers your software for free. You can, however, fork it and take your own path with the software. Are you saying because a new version breaks the current build of a downstream proprietary application, that should constitute a high priority support request from the maintainers of the project? That doesn't compute with me. If they were paying for forwards-compatibility and had that expectation in a contract, sure. But they should be able to make changes they see fit without having to make trade-offs to ensure future compatibility with an Enterprise organisation's product. At that point they're basically making design decisions to suit the Enterprise, at which case - you're not just free resources for software engineering for the organisation, you're actively pushing your project to be vendor-compatible. I could see this reasoning if your project is largely funded by them (Chromium), but in this case, they're not.