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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer