"Colin Walters" <walt...@verbum.org> writes: > On Tue, Jan 7, 2020, at 6:41 AM, Tom Hughes wrote: > >> I'd love to find a way to directly integrate the likes of gem, npm >> etc directly into our packaging rather than us having to repackage >> everything by hand but I just don't see any way of doing it without >> compromising what we do to the extent that we're not really doing >> anything useful at all and are just shoveling out whatever nonsense >> upstreams perpetrate without question. > > Implicit in this is the idea that value should be captured at a > secondary distribution layer. Implicit in this is the idea that > distribution forks *need* to happen. But they don't. > > In fact, everyone here can work upstream too! If e.g. someone > upstream messes up licensing, the mindset shouldn't be "oh man those > upstream developers are incompetent, let's patch it downstream". > > Join upstream. Review *code* not spec files. Fix *code* not spec > files. That's the most valuable thing for FOSS - not spec files. > > If there's an upstream that isn't doing the right thing (consistently) > - fork the upstream, don't fork it at the package level. That way, > work can be shared across multiple distributions.
This is a nice sentiment that does not reflect practice for me. I don't know that I'm a typical case, but I find it unlikely that I'm wildly divergent. I frequently patch my packages downstream, generally for three reasons: 1. Bugfix or feature I (or someone else) contributed upstream that we want sooner than the next upstream release. These of course are shorter lived, but relatively frequent. Note also that upstream involvement has caused the number of these to increase, not decrease. 2. Updating to a new, pristine upstream release would break a depdendent package that isn't ready for the change. This is rare and temporary, but happens about once per year. 3. Fedora diverges from the rest of the world in some weird way that upstream isn't interested in supporting. Debuginfo generation or SElinux quirks or systemd integration are examples here, but I've got plenty of others. These don't usually go away quickly if they go at all. To twist your argument: arguably I *have* forked upstream. I do have a (public! [1]) git repo with my downstream changes - but even if I didn't explicitly keep one, it's not too hard to generate one from dist-git. I happen to be a Red Hat employee, so that's that distro taken care of, and I'm in good contact with the Debian maintainers as well. (Their workflow is the same - Debian's dist-git analogue works differently than ours of course, but their patches are for the same reasons even if they're less frequent.) > Even ignoring others, the Red Hat ecosystem today has 3 distributions > - it's simply better to work upstream as much as possible, and avoid > duplicating work across those 3 downstreams. This is correct only for those who work at Red Hat or are involved in CentOS, neither of which are requirements for Fedora involvement. I don't disagree with the sentiment that we should make the entire ecosystem better where possible, but it's very close to an argument we've seen too much of recently that we should do $foo because it's good for Red Hat. Thanks, --Robbie 1: e.g., https://github.com/frozencemetery/krb5
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
