311–320 of 363 posts
If you don't understand the authors frustration, read Daniel Stenberg blog about what kind of requests he gets about curl. It's insane and ridiculous, not everybody is capable of/wanting to deal with all kinds of shit and hostile users like Daniel.
Earlier quoted context omitted.
From what I can see in the thread (and I'm not very familiar with the tech so I'm working off of inference here) it looks like the library fetching tool is well equipped to fetch the freshest branch from his repository directly. His responses are very minimal but it sounds like he's objecting to older versions of his library being bundled in and causing breakages on the client side - forking would potentially just ma…
The point about shipping old versions is rather moot in this case however, because the NixOS package was using the version required by the latest version of Home Assistant.
Earlier quoted context omitted.
I think he’s so focused on time management (from his about page), that he is catastrophizing about the future. He also clearly wants the fame from having a library in Home Automation, but doesn’t want to provide any support.
He is a paid Home Assistant core developer. (Hired by the company the project's founder created to generate sustainable income for developing the project by offering optional value-add services). This library was written specifically to be used in Home Assistant, as per project policy the code that interfaces with devices needs to live in a separate python package. So there is no real fame to be had from this particu…
Earlier quoted context omitted.
Honestly, I think the best solution in this case is to fork his repo from a version still under the MIT license and work with home-automation to replace their dependency.
He is a HomeAssistant community admin and they took his side, this is a case of two FOSS communities with irreconcilable differences.
Earlier quoted context omitted.
> they make sure the user get a specific version that is (hopefully) vetted and know as working properly This is exactly what nixpkgs maintainers do, using more reliable and explicit tools than the likes of pip. A significant effort is made to enable tests on as many packages as possible, meaning that when you get a package from nixpkgs, it has been tested against the exact dependency chain (down to the libc) it is b…
there is a reason if pretty much all distribution follow this approach :)
Really seems like you need to respect the author’s wishes here, but the tension between author and community can get complicated with FOSS. Open source is a contract with your audience that the code can be used freely. Authors gain their audience because of that contract, so there’s some obligation for them to respect that. That said, respect flows both ways, and I’ve had FOSS code get repackaged to steal credit whic…
> Open source is a contract with your audience that the code can be used freely. Not in common-law jurisdictions, where an open source license without consideration is a bare license and can be revoked at will by the licensor.
Earlier quoted context omitted.
From what I can see in the thread (and I'm not very familiar with the tech so I'm working off of inference here) it looks like the library fetching tool is well equipped to fetch the freshest branch from his repository directly. His responses are very minimal but it sounds like he's objecting to older versions of his library being bundled in and causing breakages on the client side - forking would potentially just ma…
It seems to me he states pretty clearly that his issue is the support burden, not some paternalism over users: > If users experiencing issues with the ambee library in this package, they will knock on my door. And I'm not willing to support that or accept that burden. Especially as I don't see a good repacking reason in this case. I absolutely agree that there is a legitimate reason to say "look, I can't handle the s…
French stated he doesn't want to support broken distributions of ambee, like the version in the PR. Reminds me of this story: http://wiringpi.com/wiringpi-deprecated/
Earlier quoted context omitted.
The point about shipping old versions is rather moot in this case however, because the NixOS package was using the version required by the latest version of Home Assistant.
If anything, the Nix packaging of Home Assistant should (tm) be running on a known good working set of deps.
Earlier quoted context omitted.
> This is the absolute antithesis of the intent of open source. I disagree with this assertion (...and with Frenck too). There was no need for NixOS packagers to involve HA here, they are outsourcing work upstream. Imagine some small-time driver author/maintainer asking Debian to remove their driver - and Debian's solution to honor this request is to ask Linus to drop the driver from his upstream tree! The long-held…
I think you've mistaken my assertion. HA are perfectly entitled to continue including the package. The NixOS dev opening that thread was doing so with the intent of warning them about a potentially problematic upstream maintainer. There's an argument to be made that that dev was overstepping, but they weren't making any demands: their intent was informational. The community response was multiple HA admins expressing…
To me - the subtext was NixOS still wants to do both: have reproducible builds that match HA and honor lib authors wishes. Lib author "rejected" forks, so one way was for NixOS to ask upstream HA to drop the library as a dependency. It doesn't sound like a friendly heads-up to me, from the thread title.