Re: Let's talk about Fedora in the '20s!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 7 Jan 2020 at 13:28, Neal Gompa <ngompa13@xxxxxxxxx> 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.

Language-specific packaging formats share a common thing: they are
designed to be installed in the users' home, or equivalently, in a
virtual environment without root permissions. I'm guessing here, but
the recoil you reference probably comes from the fact that distro-wide
packaging systems require admin privileges.

If that's true, then I think we should further promote Fedora toolbox.

Iñaki

> 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"
>
>
>
> --
> 真実はいつも一つ!/ Always, there's only one truth!
> _______________________________________________
> 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



-- 
Iñaki Úcar

On Tue, 7 Jan 2020 at 13:28, Neal Gompa <ngompa13@xxxxxxxxx> 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"
>
>
>
> --
> 真実はいつも一つ!/ Always, there's only one truth!
> _______________________________________________
> 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



-- 
Iñaki Úcar
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux