Comment by pugworthy
5 years ago
> It seems like the reason is (paraphrasing) "because I can't meet the resulting burden of support."
Exactly. He made that point a few times, but the replies don't always seem to address the issue he raises.
5 years ago
> It seems like the reason is (paraphrasing) "because I can't meet the resulting burden of support."
Exactly. He made that point a few times, but the replies don't always seem to address the issue he raises.
I think they proposed this:
> Would you be happier if we forked your upstream source to provide our own, or provided a similar Python package with an identical API that we can use as a drop-in replacement?
Wouldn’t this remove the burden of support from the author? Or it might be that I don’t understand exactly their proposal.
It would only remove the burden if users of the NixOS package know to go to the fork for support, as opposed to the upstream.
How would they even know to ask upstream for support, rather than the fork? If you use package bar and have a problem, you would have to do a lot of digging to even find original progject foo and ask them for help (which wouldn't even make sense since it's a separate thing)
3 replies →
I am not using NixOS but in general every package manager links to the project homepage let’s say (or name of the project which for example in a GitHub fork is clearly different than the original) which in this case would be the fork.
So for example if this will be the case with a package I use I will report the bug to the fork because the package manager showed me their link.
I will not search for name-like projects or the original one and report there if a fork was distributed to me.
This is why I am confused why a fork is not solving the burden of possible bug reports. Also the fork assumes its own maintenance this is the purpose of the fork.