Hi everybody, In the past few weeks, it has come up regularly that future "module-only" packages are orphaned (and hence will soon be retired), and nobody stepped up to fix this issue - especially for non-leaf packages. I don't think fedora as a project has a solution for this yet. I propose to create a "Stewardship" Group / SIG that will take care of such packages - either until a new main maintainer steps up, or until modularity matures enough so it won't be necessary anymore. (Or, until it dies a quiet death, which is always a possibility.) However, I think this is necessary until the situation stabilizes. Comments and future contributors are very welcome. Fabio _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)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 Tue, Feb 12, 2019 at 12:09 PM Adam Samalik <asamalik(a)redhat.com&gt; wrote: > > The Modularity Team works on enabling default modules to be present in the traditional buildroot. The work is tracked here: https://tree.taiga.io/project/modularity-wg/epic/12 > > We would love to contributions towards that. I'm willing to mentor anyone interested regarding Modularity. However, we might be quite close now. And I believe this example raises the priority quite a bit, right? (cc Stephen & Petr) The difference being: I'm suggesting something that can definitely be done now (maybe even today), and not about "maybe soon"s. I don't want to sound disrespectful, and I see that a lot of work is being poured into the Modularity effort. However, I don't want to see fedora broken as a result of unfinished solutions, where there's not even a visible agreement on the way forward.

Fabio > On Tue, Feb 12, 2019 at 11:56 AM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote: >> >> Hi everybody, >> >> In the past few weeks, it has come up regularly that future >> "module-only" packages are orphaned (and hence will soon be retired), >> and nobody stepped up to fix this issue - especially for non-leaf >> packages. I don't think fedora as a project has a solution for this >> yet. >> >> I propose to create a "Stewardship" Group / SIG that will take care of >> such packages - either until a new main maintainer steps up, or until >> modularity matures enough so it won't be necessary anymore. (Or, until >> it dies a quiet death, which is always a possibility.) However, I >> think this is necessary until the situation stabilizes. >> >> Comments and future contributors are very welcome. >> >> Fabio >> _______________________________________________ >> devel mailing list -- devel(a)lists.fedoraproject.org >> To unsubscribe send an email to devel-leave(a)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 > > > > -- > > Adam Šamalík > --------------------------- > Software Engineer > Red Hat > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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 _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)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

Fabio Valentini wrote: >In the past few weeks, it has come up regularly that future >"module-only" packages are orphaned (and hence will soon be retired), >and nobody stepped up to fix this issue - especially for non-leaf >packages. I don't think fedora as a project has a solution for this >yet. What is a "module-only" package?

What causes a package to move? I guess it doesn't just happen spontaneously, so presumably it's a choice the maintainer makes.

If so, why would they do that? Why would they *not* want their package to be available as a regular package? It seems counterproductive for them to downgrade their package to this second-class status.

Why would a maintainer drop support for the regular package after they've copied it into a module (or modules)? If, as Neal says, "module-only" packages can't be used as build dependencies for regular packages their package is now useless to any developer who isn't using modules. I'm not expecting an answer from Emmanuel. It would, though, be interesting to hear from the maintainers of the orphaned packages. Why? Why did you do that?

On 13/02/2019 08:05, Neal Gompa wrote: > On Wed, Feb 13, 2019 at 2:58 AM Ron Yorston <rmy(a)frippery.org&gt; wrote: > >> What is a "module-only" package? > > These are packages that move from the main Fedora distribution into > the addon "fedora-modular" repo that is enabled by default on Fedora > systems. > > There are a couple of consequences of this: > > * They are no longer available for regular packages to use as build dependencies > * Only DNF (the CLI tool) can manage them. PackageKit and dnfdragora > can't do anything with them yet. I don't think that second consequence is entirely true. As I understand the the default module stream remains available in the main repo and hence would be installable with things that don't understand modules. There would be no ability to switch to an alternate stream with other tools though.

On 13/02/2019 09:11, Neal Gompa wrote: > On Wed, Feb 13, 2019 at 4:09 AM Tom Hughes <tom(a)compton.nu&gt; wrote: > >> I don't think that second consequence is entirely true. >> >> As I understand the the default module stream remains available >> in the main repo and hence would be installable with things that >> don't understand modules. There would be no ability to switch to >> an alternate stream with other tools though. > > That's not true. If the modulemd isn't processed, all the RPMs are > evaluated and the repo looks like a completely conflicting pile of > nonsense. This is what makes PackageKit and dnfdragora scream. Though > they don't crash on it anymore, which is a good thing. :) Not sure I follow... I don't see anything called modulemd in the repodata and, for example, pkcon seems to be happy to install ant on my rawhide vm. As I understand it modulemd is something which goes in a distgit repo to control how modules are built?

On 13/02/2019 09:48, Neal Gompa wrote: > On Wed, Feb 13, 2019 at 4:34 AM Tom Hughes <tom(a)compton.nu&gt; wrote: >> >> On 13/02/2019 09:11, Neal Gompa wrote: >>> On Wed, Feb 13, 2019 at 4:09 AM Tom Hughes <tom(a)compton.nu&gt; wrote: >>> >>>> I don't think that second consequence is entirely true. >>>> >>>> As I understand the the default module stream remains available >>>> in the main repo and hence would be installable with things that >>>> don't understand modules. There would be no ability to switch to >>>> an alternate stream with other tools though. >>> >>> That's not true. If the modulemd isn't processed, all the RPMs are >>> evaluated and the repo looks like a completely conflicting pile of >>> nonsense. This is what makes PackageKit and dnfdragora scream. Though >>> they don't crash on it anymore, which is a good thing. :) >> >> Not sure I follow... I don't see anything called modulemd in >> the repodata and, for example, pkcon seems to be happy to install >> ant on my rawhide vm. >> >> As I understand it modulemd is something which goes in a distgit >> repo to control how modules are built? > > The fedora-modular repo has a modules.yaml.gz appended to it that is > used for shipping module information for package managers to process > for filtering rules. Ahh I have the modular repo disabled, so that's all fine then ;-)

On Wed, Feb 13, 2019 at 10:51 AM Tom Hughes <tom(a)compton.nu&gt; wrote: > > On 13/02/2019 09:48, Neal Gompa wrote: >> On Wed, Feb 13, 2019 at 4:34 AM Tom Hughes <tom(a)compton.nu&gt; wrote: >>> >>> On 13/02/2019 09:11, Neal Gompa wrote: >>>> On Wed, Feb 13, 2019 at 4:09 AM Tom Hughes <tom(a)compton.nu&gt; wrote: >>>> >>>>> I don't think that second consequence is entirely true. >>>>> >>>>> As I understand the the default module stream remains available >>>>> in the main repo and hence would be installable with things that >>>>> don't understand modules. There would be no ability to switch to >>>>> an alternate stream with other tools though. >>>> >>>> That's not true. If the modulemd isn't processed, all the RPMs are >>>> evaluated and the repo looks like a completely conflicting pile of >>>> nonsense. This is what makes PackageKit and dnfdragora scream. Though >>>> they don't crash on it anymore, which is a good thing. :) >>> >>> Not sure I follow... I don't see anything called modulemd in >>> the repodata and, for example, pkcon seems to be happy to install >>> ant on my rawhide vm. >>> >>> As I understand it modulemd is something which goes in a distgit >>> repo to control how modules are built? >> >> The fedora-modular repo has a modules.yaml.gz appended to it that is >> used for shipping module information for package managers to process >> for filtering rules. > > Ahh I have the modular repo disabled, so that's all fine then ;-) That's exactly my point. It's fine for now, since the ant hasn't been retired from the master branch - yet. Once that happens, it will not be available from the regular repos, but only from the modular repos.

In the past few weeks, it has come up regularly that future "module-only" packages are orphaned (and hence will soon be retired), and nobody stepped up to fix this issue - especially for non-leaf packages. I don't think fedora as a project has a solution for this yet. I propose to create a "Stewardship" Group / SIG that will take care of such packages - either until a new main maintainer steps up, or until modularity matures enough so it won't be necessary anymore. (Or, until it dies a quiet death, which is always a possibility.) However, I think this is necessary until the situation stabilizes.

On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer <fweimer(a)redhat.com&gt; wrote: > > * Fabio Valentini: > >> In the past few weeks, it has come up regularly that future >> "module-only" packages are orphaned (and hence will soon be retired), >> and nobody stepped up to fix this issue - especially for non-leaf >> packages. I don't think fedora as a project has a solution for this >> yet. >> >> I propose to create a "Stewardship" Group / SIG that will take care of >> such packages - either until a new main maintainer steps up, or until >> modularity matures enough so it won't be necessary anymore. (Or, until >> it dies a quiet death, which is always a possibility.) However, I >> think this is necessary until the situation stabilizes. > > The name sounds very confusing to me, considering that this seems to be > specific to modular content. That's why I'm asking for comments. I failed to come up with a better name, though. This Group / SIG would provide "classic" maintainership for otherwise semi-abandoned packages that only live on as franken-packages ("modules"), until the remaining shortcomings of modules are overcome, or until they are abandoned. But neither "Nostalgia SIG", "Classic Packaging SIG", "Stewardship SIG", nor "Package Foster Care SIG" names describe this situation well, either. At this point, my English / foreign language skills fail me. Better suggestions are welcome :)

On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer <fweimer(a)redhat.com&gt; wrote: > > * Fabio Valentini: > > > In the past few weeks, it has come up regularly that future > > "module-only" packages are orphaned (and hence will soon be retired), > > and nobody stepped up to fix this issue - especially for non-leaf > > packages. I don't think fedora as a project has a solution for this > > yet. > > > > I propose to create a "Stewardship" Group / SIG that will take care of > > such packages - either until a new main maintainer steps up, or until > > modularity matures enough so it won't be necessary anymore. (Or, until > > it dies a quiet death, which is always a possibility.) However, I > > think this is necessary until the situation stabilizes. > > The name sounds very confusing to me, considering that this seems to be > specific to modular content. That's why I'm asking for comments. I failed to come up with a better name, though. This Group / SIG would provide "classic" maintainership for otherwise semi-abandoned packages that only live on as franken-packages ("modules"), until the remaining shortcomings of modules are overcome, or until they are abandoned. But neither "Nostalgia SIG", "Classic Packaging SIG", "Stewardship SIG", nor "Package Foster Care SIG" names describe this situation well, either. At this point, my English / foreign language skills fail me. Better suggestions are welcome :)

On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer <fweimer(a)redhat.com&gt; wrote: > > * Fabio Valentini: > > > In the past few weeks, it has come up regularly that future > > "module-only" packages are orphaned (and hence will soon be retired), > > and nobody stepped up to fix this issue - especially for non-leaf > > packages. I don't think fedora as a project has a solution for this > > yet. > > > > I propose to create a "Stewardship" Group / SIG that will take care of > > such packages - either until a new main maintainer steps up, or until > > modularity matures enough so it won't be necessary anymore. (Or, until > > it dies a quiet death, which is always a possibility.) However, I > > think this is necessary until the situation stabilizes. > > The name sounds very confusing to me, considering that this seems to be > specific to modular content. That's why I'm asking for comments. I failed to come up with a better name, though. This Group / SIG would provide "classic" maintainership for otherwise semi-abandoned packages that only live on as franken-packages ("modules"), until the remaining shortcomings of modules are overcome, or until they are abandoned.

On Fri, Feb 15, 2019 at 7:46 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote: > > * Fabio Valentini: > > > On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer <fweimer(a)redhat.com&gt; wrote: > >> > >> * Fabio Valentini: > >> > >> > In the past few weeks, it has come up regularly that future > >> > "module-only" packages are orphaned (and hence will soon be retired), > >> > and nobody stepped up to fix this issue - especially for non-leaf > >> > packages. I don't think fedora as a project has a solution for this > >> > yet. > >> > > >> > I propose to create a "Stewardship" Group / SIG that will take care of > >> > such packages - either until a new main maintainer steps up, or until > >> > modularity matures enough so it won't be necessary anymore. (Or, until > >> > it dies a quiet death, which is always a possibility.) However, I > >> > think this is necessary until the situation stabilizes. > >> > >> The name sounds very confusing to me, considering that this seems to be > >> specific to modular content. > > > > That's why I'm asking for comments. I failed to come up with a better > > name, though. > > > > This Group / SIG would provide "classic" maintainership for otherwise > > semi-abandoned packages that only live on as franken-packages > > ("modules"), until the remaining shortcomings of modules are overcome, > > or until they are abandoned. > > It's still not clear to me what this group is supposed to do. > > Does the group produce modular or non-modular content? What would > qualify a package for maintenance by this group? > > Why don't we need this in a non-module context? Why do modules require > such a group? > This group would be for maintaining packages that are modularized in a non-module context so that it's actually usable by the broader ecosystem. Modules are not usable for non-module packages, and third parties building on top of Fedora can't use modules at all either. Since module developers don't care about these users, this SIG will.

Fabio, I'm willing to help where I can with this, too.

On 2/15/19 5:16 AM, Fabio Valentini wrote: > On Fri, Feb 15, 2019 at 2:14 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote: >> >> This group would be for maintaining packages that are modularized in a >> non-module context so that it's actually usable by the broader >> ecosystem. Modules are not usable for non-module packages, and third >> parties building on top of Fedora can't use modules at all either. That is indeed sadly true right now, but that should change. >> Since module developers don't care about these users, this SIG will. I don't think that's true. > Exactly. This clarification is definitely more succinct than I > anything I could have said. Well, does that mean the stewardship sig will stop existing once we can build non modular content against modules? I was seeing it as more long term.

>> Fabio, I'm willing to help where I can with this, too. > > Thank you! I don't have much spare time these days, but feel free to add me to the group/list and I can help as time permits. kevin

I propose to change the scope of the SIG a bit. Maintaining packages could be one of the activities of the SIG, but its primary purpose should be to deal with this topic in general. Watch for orphans, develop orphaning and retirement workflows, develop a strategy how to manage those cases, how to prevent them, suggest guidelines on how to decide whether or not one should move package to the module - topics like that. It extends the scope, but it also opens some possibilities for us to work on the root cause. What do you think?

On 27. 03. 19 20:53, Fabio Valentini wrote:> On the other side, I don't think that the problem of orphaned > "important" packages will go away, and this group can offer > maintenance until a "proper" new maintainer for those packages is > found. You realize that once it is maintained by the group, nobody else is going to take it?

On Fri, Feb 15, 2019 at 7:46 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote: > > * Fabio Valentini: > >> On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer <fweimer(a)redhat.com&gt; wrote: >>> >>> * Fabio Valentini: >>> >>>> In the past few weeks, it has come up regularly that future >>>> "module-only" packages are orphaned (and hence will soon be retired), >>>> and nobody stepped up to fix this issue - especially for non-leaf >>>> packages. I don't think fedora as a project has a solution for this >>>> yet. >>>> >>>> I propose to create a "Stewardship" Group / SIG that will take care of >>>> such packages - either until a new main maintainer steps up, or until >>>> modularity matures enough so it won't be necessary anymore. (Or, until >>>> it dies a quiet death, which is always a possibility.) However, I >>>> think this is necessary until the situation stabilizes. >>> >>> The name sounds very confusing to me, considering that this seems to be >>> specific to modular content. >> >> That's why I'm asking for comments. I failed to come up with a better >> name, though. >> >> This Group / SIG would provide "classic" maintainership for otherwise >> semi-abandoned packages that only live on as franken-packages >> ("modules"), until the remaining shortcomings of modules are overcome, >> or until they are abandoned. > > It's still not clear to me what this group is supposed to do. > > Does the group produce modular or non-modular content? What would > qualify a package for maintenance by this group? > > Why don't we need this in a non-module context? Why do modules require > such a group? > This group would be for maintaining packages that are modularized in a non-module context so that it's actually usable by the broader ecosystem. Modules are not usable for non-module packages, and third parties building on top of Fedora can't use modules at all either. Since module developers don't care about these users, this SIG will.