4 ms·
I have three main concerns - one is that the original package authors get credit... Right now it looks like you're obscuring that by totally replacing the origi
by NateDad 12y ago
I have three main concerns - one is that the original package authors get credit... Right now it looks like you're obscuring that by totally replacing the original import path with your own (leaving out the github username).
Second is that I worry that bugs won't get filled against the original repos for people using your version.
Finally, I'd be worried about your version of packages drifting away from the original due to change in one or the other that the other party doesn't agree with. And then as a package author, it reflects badly on my project if your version of my library breaks, even if it's not my fault.
- nknighthb 12y agoYour concerns apply equally to software aggregations generally -- e.g. every Linux distribution. Import paths are not the appropriate method of providing "credit". That's the sort of thing that is handled by copyright notices, documentation, and metadata. It's generally preferred that if you're using a software distribution, you either test bugs against a "pure" upstream version before reporting them, or report them to the maintainers of the distribution, who can triage and, when appropriate, forward bug reports upstream (possibly with patches).
- dchest 12y agoI have three main concerns - one is that the original package authors get credit... Right now it looks like you're obscuring that by totally replacing the original import path with your own (leaving out the github username). They get credit in README (the upstream path is there), on the website description of package, and, of course, their LICENSE, AUTHORS, CONTRIBUTORS files are all there. We do not want to take any credit from them. Second is that I worry that bugs won't get filled against the original repos for people using your version. We'll do it for them! When a StableLib subscriber reports a bug to us, after confirming it, we will file the bug upstream (possibly even a pull request fixing it), and: a) if the bug is critical or security related, and the patch is available — it gets applied to StableLib immediately, b) if the bug is minor or we couldn't figure out how to fix it ourselves, we wait until the upstream fixes it, and backport the fix to our version. In fact, we will recommend ourselves as the first point of contact in case of a bug instead of upstream, and do all the upstream bug reporting/relations ourselves. This way upstream package authors won't be bothered if the bug report is invalid, or if the bug doesn't apply to their version. Finally, I'd be worried about your version of packages drifting away from the original due to change in one or the other that the other party doesn't agree with. I'd prefer to keep the package as close to the original as possible — it's in our best interest, as merges/backports are easier if it's so. In any debate, the author always wins (if their view won't damage security of package). And then as a package author, it reflects badly on my project if your version of my library breaks, even if it's not my fault. That's why StableLib subscribers would first report bug to us. Thank you for your great points! This will help us with creating a FAQ.