The challenge about upstream is when they lack activity for years and
contributions are very difficult when users lack knowledge of coding
without proper guidance. For example, attempting to improve say
CellWriter (sorely missing due to the lack of port to Wayland
compositor) and howdy, a Windows Hello facial recognition like for
convertible laptops turned out too much as a graphic designer and trying
to get someone knowing to code turned out complex than anticipated.
Only options is to actively test and give input so far.
On 2020-01-07 6:08 a.m., Colin Walters wrote:
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.
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.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
