Debian's patches are generally out of necessity in order to use or support the upstream software in a sane way. Within Debian there is a culture of always sending patches upstream and most of the time patches not being upstream has a reason; for example there could be an unreasonable CLA, upstream might have gone proprietary, upstream might not accept external patches, upstream might not be (very) responsive etc.
Re:The Not-Forking Tool
by denton-scratch on Monday June 14, 2021 @05:33PM
(#27508579)
Hey pabs,
I don't mean to knock the Debian maintainers. I have chosen to rely on Debian for at least a couple of decades. I was only bitching because Debian is still my friend (I bitch at my girlfriend too).
I see :)
BTW, there are lots of ways to help Debian if you have the time/inclination to get involved.
https://www.debian.org/intro/help
Myself and others are always happy to help new people find a way to help out, the #debian-mentors or #debian-welcome IRC channels or the debian-mentors mailing list are good places for that.
Multiple upstream dependencies: that's a different problem.
Well, your test-and-build system should pull in the latest dependencies on commit, and run the test suite. If tests fail because of incompatible upstream version changes, then you have to pin one or both of the upstream versions, until the incompatibility is resolved.
Not ideal. What if you have 250 upstream dependencies, like Node.js developers have to deal with every day?