I'm orphaning js-jquery, since I do not have time to maintain it.
It's getting harder to contribute to Fedora with all the mass orphaning of dependencies, and I don't have time to figure it all out. This is one that needs frequent attention, as jQuery is subject to lots of vulnerabilities, and deserves much more attention than I've been giving it.
-- Christopher
On Wed, Apr 24, 2019 at 3:33 PM Christopher ctubbsii@fedoraproject.org wrote:
I'm orphaning js-jquery, since I do not have time to maintain it.
It's getting harder to contribute to Fedora with all the mass orphaning of dependencies, and I don't have time to figure it all out. This is one that needs frequent attention, as jQuery is subject to lots of vulnerabilities, and deserves much more attention than I've been giving it.
The orphaning of dependencies shouldn't be happening, but I (and others) are working hard to get a solution in place that will un**** the situation. I would have preferred not needing to do so under emergency conditions, but what is, is.
FWIW, things should *not* be getting harder. Some folks just jumped the gun and made changes they weren't supposed to (yet) and now the Modularity team has a lot of fires to put out and very few resources with which to do it.
On Wed, Apr 24, 2019 at 4:15 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Apr 24, 2019 at 3:33 PM Christopher ctubbsii@fedoraproject.org wrote:
I'm orphaning js-jquery, since I do not have time to maintain it.
It's getting harder to contribute to Fedora with all the mass orphaning of dependencies, and I don't have time to figure it all out. This is one that needs frequent attention, as jQuery is subject to lots of vulnerabilities, and deserves much more attention than I've been giving it.
The orphaning of dependencies shouldn't be happening, but I (and others) are working hard to get a solution in place that will un**** the situation. I would have preferred not needing to do so under emergency conditions, but what is, is.
FWIW, things should *not* be getting harder. Some folks just jumped the gun and made changes they weren't supposed to (yet) and now the Modularity team has a lot of fires to put out and very few resources with which to do it.
When I first started contributing to Fedora, after having been a long-time user, it felt like it was easy for a "user" like me to contribute back to the OS that runs on their own computers. Now, things seem to be changing so much within Fedora that it's hard for someone like me to contribute to my preferred "Desktop Linux distro".
A lot of these recent fast-paced changes seem to be very specialized... affecting all contributors to help slightly improve things for specific, small groups of people (such as those who work on composes (dist-git) or who need a mixed duration SLAs to support their enterprise customers (modularity), and those who operate in containers/cloud (Atomic)). I wish the focus would shift back to the "regular" users, so that Fedora would feel like a community-centric "Desktop Linux" OS again.... where anybody in the community can go from being a user to a contributor relatively easily.
Until Fedora stops focusing tooling improvements on advanced users and specialized needs, at the cost of regular users, and focuses a proportional amount of effort on tooling that lowers the bar so that regular users can transition to contributor more easily, Fedora is probably going to continue to see a mass exodus of packages, including important dependencies, from the distro, as advanced users are lost to attrition, and their replacements will have a harder time becoming contributors. As an existing contributor, I feel the bar is raising... I can't imagine how somebody new would feel.
I would like Fedora to do a few things to address this problem:
1. Focus on mentoring to onboard new people 2. Focus on tooling for contributing 3. Slow big changes to contributor processes down a bit... let tooling catch up 4. Slow things down with the release cadence; a breather, even if temporary, could allow community healing from previous big changes, and would give time to focus on items 1-3.
I wish I saw more focus in Fedora on community-building, and onboarding new people, lowering the bar to contribute by improving contributor workflows for the average contributor... so it feels like a community distro again. Instead, I see a lot of stuff changing that feels like it (primarily) favors the few. And, when younger or less-experienced people do try to get involved... they just get bombarded with toxic conversations about why they should be ashamed of themselves for top-posting. It's not good. Not healthy.
I'm optimistic things will improve... eventually... but in the meantime, I might have to orphan more of my packages (not that I have very many) until things get easier.
Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit :
FWIW, things should *not* be getting harder. Some folks just jumped the gun and made changes they weren't supposed to (yet) and now the Modularity team has a lot of fires to put out and very few resources with which to do it.
That’s not overly nice to the people that “jumped the gun”. They’re using modularity exactly as it was designed. Tragedy of the commons is an entirely predictible outcome, of something without a built-in sharing strategy.
I may be living under a rock, but the modularity narative still seems to be centered around not-sharing things, with no clear idea about how to share work, let alone *promote* sharing. Selling people walled gardens is easy. Making them contribute to commons is hard.
However, promoting sharing is a Fedora survival requirement. And promoting is not the same thing as “it may be technically possible, if you work hard at it”.
On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit :
FWIW, things should *not* be getting harder. Some folks just jumped the gun and made changes they weren't supposed to (yet) and now the Modularity team has a lot of fires to put out and very few resources with which to do it.
That’s not overly nice to the people that “jumped the gun”. They’re using modularity exactly as it was designed. Tragedy of the commons is an entirely predictible outcome, of something without a built-in sharing strategy.
That is my view of the matter also. There are a lot of packagers with way too many packages... and we have too many dependencies... so any tool which allows for that to be 'easier' is going to start an avalanche of packages getting moved out of the 'ursine commons'. As someone said yesterday to me, it is like showing that you can make a better living as a farmer using industrial farming techniques and then complaining that the small old-fashioned farmer no longer exists... or that a lot of people quit being farmers because those who used the industrial methods took over the market.
On 25/04/2019 19:29, Stephen John Smoogen wrote:
On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot <nicolas.mailhot@laposte.net mailto:nicolas.mailhot@laposte.net> wrote:
Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit : > > FWIW, things should *not* be getting harder. Some folks just jumped > the gun and made changes they weren't supposed to (yet) and now the > Modularity team has a lot of fires to put out and very few resources > with which to do it. That’s not overly nice to the people that “jumped the gun”. They’re using modularity exactly as it was designed. Tragedy of the commons is an entirely predictible outcome, of something without a built-in sharing strategy.That is my view of the matter also. There are a lot of packagers with way too many packages... and we have too many dependencies... so any tool which allows for that to be 'easier' is going to start an avalanche of packages getting moved out of the 'ursine commons'. As someone said yesterday to me, it is like showing that you can make a better living as a farmer using industrial farming techniques and then complaining that the small old-fashioned farmer no longer exists... or that a lot of people quit being farmers because those who used the industrial methods took over the market.
How does modularity make it easier though?
It seems to me that it does the exact opposite - instead of having one version of each package to maintain I now have multiple versions to worry about! I mean obviously I could convert to a module and only maintain one version but what would be the point? There would still be extra metadata relating to the module to maintain anyway.
Tom
On Thu, Apr 25, 2019 at 2:39 PM Tom Hughes tom@compton.nu wrote:
On 25/04/2019 19:29, Stephen John Smoogen wrote:
On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot <nicolas.mailhot@laposte.net mailto:nicolas.mailhot@laposte.net> wrote:
Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit : > > FWIW, things should *not* be getting harder. Some folks just jumped > the gun and made changes they weren't supposed to (yet) and now the > Modularity team has a lot of fires to put out and very few resources > with which to do it. That’s not overly nice to the people that “jumped the gun”. They’re using modularity exactly as it was designed. Tragedy of the commons is an entirely predictible outcome, of something without a built-in sharing strategy.That is my view of the matter also. There are a lot of packagers with way too many packages... and we have too many dependencies... so any tool which allows for that to be 'easier' is going to start an avalanche of packages getting moved out of the 'ursine commons'. As someone said yesterday to me, it is like showing that you can make a better living as a farmer using industrial farming techniques and then complaining that the small old-fashioned farmer no longer exists... or that a lot of people quit being farmers because those who used the industrial methods took over the market.
How does modularity make it easier though?
It seems to me that it does the exact opposite - instead of having one version of each package to maintain I now have multiple versions to worry about! I mean obviously I could convert to a module and only maintain one version but what would be the point? There would still be extra metadata relating to the module to maintain anyway.
I probably agree with you, based on my own experience alone. However, I think arguing against modularity is a distraction from the problem at hand. Can't we just concede that modularity benefits some, but not all, packagers? Fighting with the "Modularity team", whoever they are (a SIG? a mailing list?, a team at RedHat? ... I don't really know who they are) is only going to divide us and distract from the real issue. This isn't their fault. The packaging process is the responsibility of FESCo. It is their responsibility to ensure that the packaging processes in place are adequate to enable packagers to contribute, regardless of what's going on with any specific subset of packagers. But, it's clear that the current processes are breaking, getting more burdensome, and require more education, tooling, documentation, and general fine-tuning. As a result, many packagers are getting "left behind".
Perhaps I'm looking in the wrong places, but I haven't seen much in terms of what FESCo is specifically doing to address this "left behind" issue within the packaging process. Is there a place where they regularly document what they are doing from a process engineering and oversight perspective, and receive community feedback on what they are doing? I think that could be helpful, but I don't know where to look (if it exists).
On Thu, 25 Apr 2019 at 20:01, Christopher ctubbsii@fedoraproject.org wrote:
On Thu, Apr 25, 2019 at 2:39 PM Tom Hughes tom@compton.nu wrote:
On 25/04/2019 19:29, Stephen John Smoogen wrote:
On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot <nicolas.mailhot@laposte.net mailto:nicolas.mailhot@laposte.net>
wrote:
Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit:
> > FWIW, things should *not* be getting harder. Some folks justjumped
> the gun and made changes they weren't supposed to (yet) and nowthe
> Modularity team has a lot of fires to put out and very fewresources
> with which to do it. That’s not overly nice to the people that “jumped the gun”. They’re using modularity exactly as it was designed. Tragedy of thecommons is
an entirely predictible outcome, of something without a built-in sharing strategy.That is my view of the matter also. There are a lot of packagers with way too many packages... and we have too many dependencies... so any tool which allows for that to be 'easier' is going to start an
avalanche
of packages getting moved out of the 'ursine commons'. As someone said yesterday to me, it is like showing that you can make a better living
as
a farmer using industrial farming techniques and then complaining that the small old-fashioned farmer no longer exists... or that a lot of people quit being farmers because those who used the industrial methods took over the market.
How does modularity make it easier though?
It seems to me that it does the exact opposite - instead of having one version of each package to maintain I now have multiple versions to worry about! I mean obviously I could convert to a module and only maintain one version but what would be the point? There would still be extra metadata relating to the module to maintain anyway.
I probably agree with you, based on my own experience alone. However, I think arguing against modularity is a distraction from the problem at hand. Can't we just concede that modularity benefits some, but not all, packagers? Fighting with the "Modularity team", whoever they are (a SIG? a mailing list?, a team at RedHat? ... I don't really know who they are) is only going to divide us and distract from the real issue. This isn't their fault. The packaging process is the responsibility of
Sorry I didn't mean to come across as fighting with the modularity team. My main problem is that something like this looked like it was going to happen no matter the solution added to Fedora. If we had come up with some other tool which transformed how things are done.. this would have still happened. The issue is that everyone involved got sucked up into other problems and let the spinning china plates hit the floor. [And since I am on this list, and I do follow things.. I am one of those people who let the plates fall.]
FESCo. It is their responsibility to ensure that the packaging processes in place are adequate to enable packagers to contribute, regardless of what's going on with any specific subset of packagers. But, it's clear that the current processes are breaking, getting more burdensome, and require more education, tooling, documentation, and general fine-tuning. As a result, many packagers are getting "left behind".
Perhaps I'm looking in the wrong places, but I haven't seen much in terms of what FESCo is specifically doing to address this "left behind" issue within the packaging process. Is there a place where they regularly document what they are doing from a process engineering and oversight perspective, and receive community feedback on what they are doing? I think that could be helpful, but I don't know where to look (if it exists).
On 26. 04. 19 2:00, Christopher wrote:
On Thu, Apr 25, 2019 at 2:39 PM Tom Hughes tom@compton.nu wrote:
On 25/04/2019 19:29, Stephen John Smoogen wrote:
On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot <nicolas.mailhot@laposte.net mailto:nicolas.mailhot@laposte.net> wrote:
Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit : > > FWIW, things should *not* be getting harder. Some folks just jumped > the gun and made changes they weren't supposed to (yet) and now the > Modularity team has a lot of fires to put out and very few resources > with which to do it. That’s not overly nice to the people that “jumped the gun”. They’re using modularity exactly as it was designed. Tragedy of the commons is an entirely predictible outcome, of something without a built-in sharing strategy.That is my view of the matter also. There are a lot of packagers with way too many packages... and we have too many dependencies... so any tool which allows for that to be 'easier' is going to start an avalanche of packages getting moved out of the 'ursine commons'. As someone said yesterday to me, it is like showing that you can make a better living as a farmer using industrial farming techniques and then complaining that the small old-fashioned farmer no longer exists... or that a lot of people quit being farmers because those who used the industrial methods took over the market.
How does modularity make it easier though?
It seems to me that it does the exact opposite - instead of having one version of each package to maintain I now have multiple versions to worry about! I mean obviously I could convert to a module and only maintain one version but what would be the point? There would still be extra metadata relating to the module to maintain anyway.
I probably agree with you, based on my own experience alone. However, I think arguing against modularity is a distraction from the problem at hand. Can't we just concede that modularity benefits some, but not all, packagers? Fighting with the "Modularity team", whoever they are (a SIG? a mailing list?, a team at RedHat? ... I don't really know who they are) is only going to divide us and distract from the real issue. This isn't their fault. The packaging process is the responsibility of FESCo. It is their responsibility to ensure that the packaging processes in place are adequate to enable packagers to contribute, regardless of what's going on with any specific subset of packagers. But, it's clear that the current processes are breaking, getting more burdensome, and require more education, tooling, documentation, and general fine-tuning. As a result, many packagers are getting "left behind".
Perhaps I'm looking in the wrong places, but I haven't seen much in terms of what FESCo is specifically doing to address this "left behind" issue within the packaging process. Is there a place where they regularly document what they are doing from a process engineering and oversight perspective, and receive community feedback on what they are doing? I think that could be helpful, but I don't know where to look (if it exists).
I am afraid there is no such dedicated place.
Recently, we've talked about the "contributing to Fedora is harder" at one of the FESCo meetings [1] and this is what we came up with Randy (bowlofeggs) after as 2 major issues:
https://pagure.io/fesco/issue/2114 https://pagure.io/fesco/issue/2115
However there might be more. I'd be very happy if you help me to identify major pain points that need to be addressed.
The problem at FESCo is that we cannot make people implement stuff or fix things. We can possibly only stop new stings from happening too fast.
I believe that several unfortunate choices were made in the past, but I realize it is to late to say: "scratch this, let's go back X releases". Instead we should try to "unbreak things" however nobody really knows how to do that :(
There was the packager UX initiative draft [2] proposed in December 2018, however it seems nobody really is eager to go and start doing this. It seems that this is a bit too much for volunteers and Red Hat paid Fedora contributors are already folly occupied by their primary responsibilities.
I'm glad you've opened this topic.
[1] https://meetbot.fedoraproject.org/fedora-meeting-1/2019-03-25/fesco.2019-03-... [2] https://fedoraproject.org/wiki/Objectives/Packager_Experience
On Thu, Apr 25, 2019 at 8:25 PM Miro Hrončok mhroncok@redhat.com wrote:
There was the packager UX initiative draft [2] proposed in December 2018, however it seems nobody really is eager to go and start doing this. It seems that this is a bit too much for volunteers and Red Hat paid Fedora contributors are already folly occupied by their primary responsibilities.
[2] https://fedoraproject.org/wiki/Objectives/Packager_Experience
I was the author of that proposal. I started working on it because I completely agree with the complaints that have been raised in this thread thus far. In fact, I *made* similar complaints back in December and was encouraged to file the objective proposal in question.
Unfortunately, I've realized over the last few months that I did not have the time or energy to be the sole person pushing this forward. I'm sorry that I've let it languish.
I'd still like to see the objective be realized. Though, perhaps, rather than have the objective proposal suggest creating a SIG or WG to organize packager experience efforts, we need to do this the other way around: we should create a SIG or packager experience and then *that SIG as a group* should prepare and submit an objective proposal describing what they want to work on.
Ben Rosser
Le jeudi 25 avril 2019 à 20:00 -0400, Christopher a écrit :
Fighting with the "Modularity team", whoever they are (a SIG? a mailing list?, a team at RedHat? ... I don't really know who they are)
Just to be clear: this is not about fighting the Modularity team (or any other team, for that matter). Modularity, Silverblue, RHEL, etc, all assume something to build upon. And this something may be Fedora as we know it today, or something else entirely, I don’t care (much).
Yet there is no public advocate of this something. All the energy is poured in “value-added” endeavours which delegate hard problems to a backbone starved of investments and resources.
This is not healthy or sustainable.
On Fri, Apr 26, 2019 at 3:23 PM Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le jeudi 25 avril 2019 à 20:00 -0400, Christopher a écrit :
Fighting with the "Modularity team", whoever they are (a SIG? a mailing list?, a team at RedHat? ... I don't really know who they are)
Just to be clear: this is not about fighting the Modularity team (or any other team, for that matter). Modularity, Silverblue, RHEL, etc, all assume something to build upon. And this something may be Fedora as we know it today, or something else entirely, I don’t care (much).
Yet there is no public advocate of this something. All the energy is poured in “value-added” endeavours which delegate hard problems to a backbone starved of investments and resources.
This is not healthy or sustainable.
I completely agree.
While I understand that it's more exciting to work on the "new shiny project" (Modularity), the basis we all want to build upon (traditional RPM packages in the "normal" repos, in this case) cannot be allowed to rot, or we all stand on shaky ground.
For example, the Stewardship SIG recently took ownership of around 200 orphaned, now mostly module-only packages - some of which have a dependency tree larger than 2000 (!) binary packages.
TL;DR: I don't think pulling the rug out under a significant portion of the fedora package set (and maintainers) is a good idea, until we're sure that there's solid ground under our feet.
Fabio
-- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Dne 25. 04. 19 v 20:37 Tom Hughes napsal(a):
On 25/04/2019 19:29, Stephen John Smoogen wrote:
On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot <nicolas.mailhot@laposte.net mailto:nicolas.mailhot@laposte.net> wrote:
Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit : > > FWIW, things should *not* be getting harder. Some folks just jumped > the gun and made changes they weren't supposed to (yet) and now the > Modularity team has a lot of fires to put out and very few resources > with which to do it.
That’s not overly nice to the people that “jumped the gun”. They’re using modularity exactly as it was designed. Tragedy of the commons is an entirely predictible outcome, of something without a built-in sharing strategy.
That is my view of the matter also. There are a lot of packagers with way too many packages... and we have too many dependencies... so any tool which allows for that to be 'easier' is going to start an avalanche of packages getting moved out of the 'ursine commons'. As someone said yesterday to me, it is like showing that you can make a better living as a farmer using industrial farming techniques and then complaining that the small old-fashioned farmer no longer exists... or that a lot of people quit being farmers because those who used the industrial methods took over the market.
How does modularity make it easier though?
It seems to me that it does the exact opposite - instead of having one version of each package to maintain I now have multiple versions to worry about! I mean obviously I could convert to a module and only maintain one version but what would be the point?
Converting to module does not mean maintaining one version. It means that you have to maintain the one version on multiple versions of Fedora, where previously this was not needed.
E.g. if there is new OpenSSL in Rawhide and Ruby needs to be modified somehow, then the modification has to be compatible with older Fedoras, whereas previously you would do that change just for Rawhide.
TBH, keeping modules alive is much harder then it was without modules. Not even mentioning the possibility of having multiple versions ...
Vít
There would still be extra metadata relating to the module to maintain anyway.
Tom
On 26. 04. 19 10:55, Vít Ondruch wrote:>> How does modularity make it easier though?
It seems to me that it does the exact opposite - instead of having one version of each package to maintain I now have multiple versions to worry about! I mean obviously I could convert to a module and only maintain one version but what would be the point?
Converting to module does not mean maintaining one version. It means that you have to maintain the one version on multiple versions of Fedora, where previously this was not needed.
E.g. if there is new OpenSSL in Rawhide and Ruby needs to be modified somehow, then the modification has to be compatible with older Fedoras, whereas previously you would do that change just for Rawhide.
TBH, keeping modules alive is much harder then it was without modules. Not even mentioning the possibility of having multiple versions ...
And yet somehow, somebody considers that easier. I still try to understand that and I always fail.
Dne 26. 04. 19 v 11:15 Miro Hrončok napsal(a):
On 26. 04. 19 10:55, Vít Ondruch wrote:>> How does modularity make it easier though?
It seems to me that it does the exact opposite - instead of having one version of each package to maintain I now have multiple versions to worry about! I mean obviously I could convert to a module and only maintain one version but what would be the point?
Converting to module does not mean maintaining one version. It means that you have to maintain the one version on multiple versions of Fedora, where previously this was not needed.
E.g. if there is new OpenSSL in Rawhide and Ruby needs to be modified somehow, then the modification has to be compatible with older Fedoras, whereas previously you would do that change just for Rawhide.
TBH, keeping modules alive is much harder then it was without modules. Not even mentioning the possibility of having multiple versions ...
And yet somehow, somebody considers that easier.
Of course. If Java in RHEL is in module, then Fedora maintainer probably does not have desire to maintain it in Fedora differently.
Also, just FTR, there used to be 3 people working on Java packages in Red Hat and now it is not more than 1,5 if I am not mistaken. That must be visible somewhere.
TBH, the disconnect between RHEL and Fedora is IMHO much bigger then it used to be and this is also plays its role.
Vít
I still try to understand that and I always fail.
On 2019-04-26, Miro Hrončok mhroncok@redhat.com wrote:
On 26. 04. 19 10:55, Vít Ondruch wrote:
How does modularity make it easier though?
It seems to me that it does the exact opposite - instead of having one version of each package to maintain I now have multiple versions to worry about! I mean obviously I could convert to a module and only maintain one version but what would be the point?
Converting to module does not mean maintaining one version. It means that you have to maintain the one version on multiple versions of Fedora, where previously this was not needed.
E.g. if there is new OpenSSL in Rawhide and Ruby needs to be modified somehow, then the modification has to be compatible with older Fedoras, whereas previously you would do that change just for Rawhide.
TBH, keeping modules alive is much harder then it was without modules. Not even mentioning the possibility of having multiple versions ...
And yet somehow, somebody considers that easier. I still try to understand that and I always fail.
Modularity was designed to have a module life cycle independent from the underlying distribution. I.e. having one stream built from one sources for multiple Fedoras. This is a benefit for users. (If we assume that users care what version of software they use. We could maybe consider users as developers in this matter.)
Having the same sources on multiple Fedoras of course implies a packager has to maintain compatibility across multiple Fedoras. In the end it's exactly what an upstream struggles for. If you are an upstream then you want to enable your users to build the same code for multiple distributions. It makes packagers to produce more upstreamable patches. Is it more labour for packagers? Yes, it is. But it frees the packager from worrying Did I apply the fix for all supported Fedoras? Do I have to resolve merge conflicts when backporting patches? I believe this is what Mikołaj found attractive and why decided for modules. This is especially true for closed ecosystems like Java packages that have almost no dependencies on non-Java stuff. In this perspective modularity can be beneficial for packagers too.
Controversial property of modules are private build-time dependencies. Modularity allows packagers to hide them and to not to support them (to the extend that they work in my module). However, this privatisation has costs. It means duplication of work unless two packager realize they can refer to the same package from their modules. But the common package is whose responsibility now? And looking back at users, poor users won't get that package for free. Yes, I agree that that this aspect of modularity hinders an integration role of packaging. Integrating thousounds of pieces of software, all of them as first-class citizens and offering them to users makes distributions very attractive for developers or anyone who wants to fork or spin of flavour or extend the distribution.
One can dispute that now nobody, especially developers, needs distributions with a wide selection of software because everybody uses containers and installs software from upstream bypassing distributor's packages. Well, that may be true for closed ecosystems (like Java maven artifacts, Ruby gems etc.), however, look at any CI configuration files (those foo.yml poluting roots for git repositories). They start with "dnf install openssl-devel"-like incantation. Distributions are not dead. They are still needed. And will be needed untill those fancy upstream ecosystems (CPAN, PyPI etc.) gets to know how integrate with foreign pieces (e.g. with C libraries).
In my humble opinion modularity would be more beneficial if every RPM package gets it's own that-package-contained module by default. This plethora of modules would of course demand appropriate tooling. Tooling as we have around RPM (repositories, composes, package managers). Or vice versa instead of reinventig weel enable Koji to expand-build one SRPM for multiple Fedoras. And enable composes to contain multiple version of packages. And having the build-only packages/modules in a separate "unsupported" repository or just flagged in metadata as unsupported.
The issue with modules in Fedora is that they look like aliens (metadata and tooling), behave like aliens (dnf system-upgrade) and are born like aliens (MBS above Koji).
-- Petr
On Fri, 26 Apr 2019 11:07:54 -0000 (UTC) Petr Pisar ppisar@redhat.com wrote:
I am a fedora user with no dog in this fight.
Controversial property of modules are private build-time dependencies. Modularity allows packagers to hide them and to not to support them (to the extend that they work in my module). However, this privatisation has costs. It means duplication of work unless two ...
Isn't this contrary to the Fedora rules? If I'm understanding this correctly, it means that modules in Fedora can contain dependencies on code that isn't available, so that Fedora (and users) can't build that module from source. And that the module could contain basically anything because no one can examine the contents that built the module. Could someone privately pull in something like the proprietary nvidia binary blob and use it to build their module without anyone knowing?
Because I'm not knowledgeable about this, it might be that private dependencies have to be packages built from source code available in the Fedora ecosystem, and so this is not possible. I just want to clarify my understanding.
On Fri, Apr 26, 2019 at 11:53 AM stan upaitag@zoho.com wrote:
On Fri, 26 Apr 2019 11:07:54 -0000 (UTC) Petr Pisar ppisar@redhat.com wrote:
I am a fedora user with no dog in this fight.
Controversial property of modules are private build-time dependencies. Modularity allows packagers to hide them and to not to support them (to the extend that they work in my module). However, this privatisation has costs. It means duplication of work unless two ...
Isn't this contrary to the Fedora rules? If I'm understanding this correctly, it means that modules in Fedora can contain dependencies on code that isn't available, so that Fedora (and users) can't build that module from source. And that the module could contain basically anything because no one can examine the contents that built the module. Could someone privately pull in something like the proprietary nvidia binary blob and use it to build their module without anyone knowing?
Because I'm not knowledgeable about this, it might be that private dependencies have to be packages built from source code available in the Fedora ecosystem, and so this is not possible. I just want to clarify my understanding.
The restrictions by Fedora Koji prevent that, but yes, MBS and Modularity do allow for something like this. It can't happen in Fedora because our Koji is not set up to consume external repositories (except for EPEL, which consumes RHEL content this way).
But I don't know if this restriction will stick around in the future...
That said, today, modules can and do rely on unpublished RPMs that have packaging in Dist Git. It is currently impossible with some modules to be able to privately rebuild them outside of Fedora infrastructure. I've made my displeasure about this known in the past, and hopefully this will be rectified soon.
On Sat, Apr 27, 2019 at 11:20 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Apr 26, 2019 at 11:53 AM stan upaitag@zoho.com wrote:
On Fri, 26 Apr 2019 11:07:54 -0000 (UTC) Petr Pisar ppisar@redhat.com wrote:
I am a fedora user with no dog in this fight.
Controversial property of modules are private build-time dependencies. Modularity allows packagers to hide them and to not to support them (to the extend that they work in my module). However, this privatisation has costs. It means duplication of work unless two ...
Isn't this contrary to the Fedora rules? If I'm understanding this correctly, it means that modules in Fedora can contain dependencies on code that isn't available, so that Fedora (and users) can't build that module from source. And that the module could contain basically anything because no one can examine the contents that built the module. Could someone privately pull in something like the proprietary nvidia binary blob and use it to build their module without anyone knowing?
Because I'm not knowledgeable about this, it might be that private dependencies have to be packages built from source code available in the Fedora ecosystem, and so this is not possible. I just want to clarify my understanding.
The restrictions by Fedora Koji prevent that, but yes, MBS and Modularity do allow for something like this. It can't happen in Fedora because our Koji is not set up to consume external repositories (except for EPEL, which consumes RHEL content this way).
But I don't know if this restriction will stick around in the future...
That said, today, modules can and do rely on unpublished RPMs that have packaging in Dist Git. It is currently impossible with some modules to be able to privately rebuild them outside of Fedora infrastructure. I've made my displeasure about this known in the past, and hopefully this will be rectified soon.
Please, yes. The provenance of RPMs and their build environments is one of Fedora's most redeeming features.
On Sat, 27 Apr 2019 11:19:06 -0400 Neal Gompa ngompa13@gmail.com wrote:
The restrictions by Fedora Koji prevent that, but yes, MBS and Modularity do allow for something like this. It can't happen in Fedora because our Koji is not set up to consume external repositories (except for EPEL, which consumes RHEL content this way).
But I don't know if this restriction will stick around in the future...
That said, today, modules can and do rely on unpublished RPMs that have packaging in Dist Git. It is currently impossible with some modules to be able to privately rebuild them outside of Fedora infrastructure. I've made my displeasure about this known in the past, and hopefully this will be rectified soon.
Thanks.
On 4/26/19 8:53 AM, stan wrote:
On Fri, 26 Apr 2019 11:07:54 -0000 (UTC) Petr Pisar ppisar@redhat.com wrote:
I am a fedora user with no dog in this fight.
Controversial property of modules are private build-time dependencies. Modularity allows packagers to hide them and to not to support them (to the extend that they work in my module). However, this privatisation has costs. It means duplication of work unless two ...
Isn't this contrary to the Fedora rules? If I'm understanding this correctly, it means that modules in Fedora can contain dependencies on code that isn't available, so that Fedora (and users) can't build that module from source.
No. The code is available at src.fedoraproject.org for everything. The binary packages may not be available outside the module build system, depending on how things are setup.
And that the module could contain basically anything because no one can examine the contents that built the module. Could someone privately pull in something like the proprietary nvidia binary blob and use it to build their module without anyone knowing?
No more so than any packager could just add the nvidia binary blob to their package. ie, sure, but we trust our maintainers not to do that, and if we detected it likely the maintainer wouldn't be a maintainer anymore.
Because I'm not knowledgeable about this, it might be that private dependencies have to be packages built from source code available in the Fedora ecosystem, and so this is not possible. I just want to clarify my understanding.
Yes, they are all still built from source.
kevin
On Sat, 27 Apr 2019 11:12:48 -0700 Kevin Fenzi kevin@scrye.com wrote:
On 4/26/19 8:53 AM, stan wrote:
On Fri, 26 Apr 2019 11:07:54 -0000 (UTC) Petr Pisar ppisar@redhat.com wrote:
I am a fedora user with no dog in this fight.
Controversial property of modules are private build-time dependencies. Modularity allows packagers to hide them and to not to support them (to the extend that they work in my module). However, this privatisation has costs. It means duplication of work unless two ...
Isn't this contrary to the Fedora rules? If I'm understanding this correctly, it means that modules in Fedora can contain dependencies on code that isn't available, so that Fedora (and users) can't build that module from source.
No. The code is available at src.fedoraproject.org for everything. The binary packages may not be available outside the module build system, depending on how things are setup.
And that the module could contain basically anything because no one can examine the contents that built the module. Could someone privately pull in something like the proprietary nvidia binary blob and use it to build their module without anyone knowing?
No more so than any packager could just add the nvidia binary blob to their package. ie, sure, but we trust our maintainers not to do that, and if we detected it likely the maintainer wouldn't be a maintainer anymore.
Because I'm not knowledgeable about this, it might be that private dependencies have to be packages built from source code available in the Fedora ecosystem, and so this is not possible. I just want to clarify my understanding.
Yes, they are all still built from source.
Thanks.
Dne 24. 04. 19 v 21:31 Christopher napsal(a):
I'm orphaning js-jquery, since I do not have time to maintain it.
I requested unorpahing js-jquery:
https://pagure.io/releng/issue/8308
The reasons are the same as why I keep alive the other versions. I'm not really going to maintain it unless I am totally bored. Also, there are other dependencies which are going to be orphaned soon, so I might change my mind ...
Vít
It's getting harder to contribute to Fedora with all the mass orphaning of dependencies, and I don't have time to figure it all out. This is one that needs frequent attention, as jQuery is subject to lots of vulnerabilities, and deserves much more attention than I've been giving it.
-- Christopher _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 25. 04. 19 12:13, Vít Ondruch wrote:
The reasons are the same as why I keep alive the other versions. I'm not really going to maintain it unless I am totally bored. Also, there are other dependencies which are going to be orphaned soon, so I might change my mind ...
I have claimed the dependencies (all I could find): https://pagure.io/releng/issue/8309
The maintenance will be on best-effort basis, since I do not have any working knowledge of JavaScript.
-
Ben Rosser -
Christopher -
Fabio Valentini -
Jan Staněk -
Kevin Fenzi -
Miro Hrončok -
Neal Gompa -
Nico Kadel-Garcia -
Nicolas Mailhot -
Petr Pisar -
stan -
Stephen Gallagher -
Stephen John Smoogen -
Tom Hughes -
Vít Ondruch