On 07. 01. 20 13:17, Neal Gompa wrote:
On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman <mkolman@xxxxxxxxxx> wrote:
On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote:
Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a):
Le 2020-01-06 19:05, Nicolas Mailhot a écrit :
Handling those checks is where the packaging toil is (that is, as long
as Fedora is a deployment project). It is not something the packaging
format makes harder.
However, because our packaging format streamlines those checks, and
forces to apply them, it is blamed by devs for the impedance mismatch
between dev and deployment requirements.
But, this mismatch is not caused by our packaging format. It is caused
by devs taking shortcuts because their language packaging format lets
them.
Well said Nicolas.
Embracing the "language-native packaging" and "git repos" is giving up
on what Fedora maintainers have always did and that is kicking forward
all the upstreams, because we force them to keep updating the
dependencies (or to maintain compatibility with old versions of
dependencies). Once we embrace "git repos" etc, we will lose our soul
IMO. There won't be any collaboration between upstream projects, which
was cultivated by distribution maintainers. Upstreams will sit in their
silos and bundle everything.
Just recently I've read a discussion (IIRC on Hacker News) about an article
about yet another mess due to NPM (I think this was for a change some licensing mess,
not another malware) where someone suggested a radical new idea: "Lets have a
crowd sourced set of packages that are known to have sane licenses, don't contain
malware/CVEs and can work together!". Yeah, like, say a Linux distro such as Fedora ?
Basically, it seems to me that the language specific package management systems
are already creaking under load & display critical issues almost on a daily basis.
Issues people with distro packaging background pointed out long ago, only to be ignored.
So I think it really makes much more sense to continue with all the nice nice improvements
we have been doing in RPM packaging, rather than throwing it all away and switching to
a fundamentally inferior technology.
Also, just today I had discussion if Ruby packages should be more Fedora
tailored or more upstream like and there is no right way which could
reasonably satisfy both worlds.
E.g. if upstream package has Windows specific dependencies, it is kind
of natural to strip this dependency on Fedora. OTOH, it possibly breaks
a dependency resolving on other platforms, if the project was created
using Fedora packages. This is unfortunately the reason for devs to take
some shortcut, probably to go with upstream way, because if nothing
else, it is typically better documented.
There's some interesting cognitive dissonance here. In HN threads
where I've seen this, people seem to be naturally discovering that
what they want is a curation point for these modules, but when someone
points out that the Linux distribution essentially functions in that
role, there's some recoil. They say that they don't want that.
I think the underlying problem here is that we don't sell ourselves
well in the value proposition to these people. Most people sadly
reference Debian as their idea of a Linux distribution. While they
certainly provide certainty and curation, they are often too slow to
be usable by developers to leverage new features and capabilities for
their software. This is something we need to figure out how to market
better for Fedora desktop, server, and cloud variants. We provide much
of the same benefits that Debian does, except we also provide fresher
stacks and new features more quickly for people to leverage.
"Friends. Features. Freedom. First. Fedora"
For me, an ultimate success would be if upstream projects would actually use
Fedora-family distros in their CI testing. And I don't mean that they would use
Copr or packit to package RPM packages, or that they deploy their own Jenkins on
CentOS, I mean that they would use something as easy as Travis CI, but instead
of ancient Ubuntu, they could choose from a variety of Fedora systems.
For example: Today, an upstream maintainer expressed dissatisfaction about
Python 3.9 missing on Travis CI:
https://github.com/benjaminp/six/issues/317#issuecomment-571408737
It would be so cool to be able to say: Put "distro: fedora" to your CI config to
get Python 3.9, because in Fedora, we already have that for a month+.
As much as you might never expected me to say this: It would be even better with
modularity, in case we actually offer alternate versions for most of our
developer facing things. Instead of compiling my own stuff or downloading
precomiled suspicious tarballs on Ubuntu/Travis, I could use Fedora and in the
CI config, lists the streams of my database, webservers etc. and use it to
expand my testing matrix.
Having a strong presence on upstream CIs would help us get visibility. Later,
people might choose Fedora as their base container platform to match their CI
environment or even consider it for their workstations.
Unfortunately I don't see this happening without RH partnering up with a major
CI provider or without significant investment in providing our own public CI
(sans RPM) - however we are now discontinuing services, not adding new.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
