On Tue, Jan 7, 2020 at 8:34 AM Martin Kolman <mkol...@redhat.com> wrote: > > 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 <mkol...@redhat.com> 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. >
Travis CI software itself is open source[1]. However, I don't think the setup of Travis is very easy. The architecture looks like it involves a mixtures of OpenStack and Kubernetes... I wonder if an enterprising developer could contribute Fedora templates into Travis CI... It looks like it's a spaghetti of Ruby, Packer, and maybe some Terraform HCL to define build environments? [1]: https://github.com/travis-ci -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
