On Tue, 2020-01-07 at 13:50 +0100, Miro Hrončok wrote: > 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 In this case it seems it's mainly lack of resources on the Travis side - they have been lagging with updates even for their single Ubuntu based environment for years. > > 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+. This is actually possibly if a bit hacky, as you can launch containers in the Travis environment. So you can checkout a Fedora container and then run the tests inside it: https://github.com/weldr/lorax/blob/master/.travis.yml#L10 https://github.com/weldr/lorax/blob/master/Makefile#L130 Unfortunately you loose many of the Travis provided simple configuration options, but at least yo don't have to suffer the quirks of the default outdated Ubuntu. > > 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. Indeed, an easy upstream usable Fedora/CentOS based upstream CI environment is sorely needed. BTW, with CentOS streams, it should now be possibly to even test in environment reasonably similar to the next upcoming release or RHEL, which was something that was missing before. We just need an environment that can be used easily - just as Travis, but Fedora/CentOS based and up to date. > > -- > 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 _______________________________________________ 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
