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
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)
On Tue, Feb 12, 2019 at 11:56 AM Fabio Valentini decathorpe@gmail.com 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@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 Tue, Feb 12, 2019 at 12:09 PM Adam Samalik asamalik@redhat.com 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@gmail.com 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@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
--
Adam Šamalík
Software Engineer Red Hat _______________________________________________ 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 Tue, Feb 12, 2019 at 12:15 PM Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Feb 12, 2019 at 12:09 PM Adam Samalik asamalik@redhat.com 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.
Ah, I haven't taken that as a disrespectful or anything! :-)
Actually, thanks for stepping up and offering help. Definitely agree that this might be a much faster temporary workaround before the proper fix comes. I just wanted to make sure that people understand that it's something we're working on.
Fabio
On Tue, Feb 12, 2019 at 11:56 AM Fabio Valentini decathorpe@gmail.com
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@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
--
Adam Šamalík
Software Engineer Red Hat _______________________________________________ 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 _______________________________________________ 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
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?
Ron
On Wed, Feb 13, 2019 at 2:58 AM Ron Yorston rmy@frippery.org wrote:
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?
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.
-- 真実はいつも一つ!/ Always, there's only one truth!
Neal Gompa wrote:
Ron Yorston 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.
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.
Ron
* Ron Yorston [13/02/2019 08:45] :
What causes a package to move? I guess it doesn't just happen spontaneously, so presumably it's a choice the maintainer makes.
It isn't really a move per se. A regular package can be copied into a module. If the package is then orphaned/retired, it ceases to be a regular package but stays part of a module.
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.
The goal, IIUC (and I'm not at sure that I do), is to for each module to be able to have its own lifecycle, seperate from the lifecycle of the distribution.
Emmanuel
Emmanuel Seyman wrote:
- Ron Yorston [13/02/2019 08:45] :
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.
The goal, IIUC (and I'm not at sure that I do), is to for each module to be able to have its own lifecycle, seperate from the lifecycle of the distribution.
Sure, that's my (possibly faulty) understanding too. But it doesn't answer my question.
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?
Ron
On Wednesday, 13 February 2019 at 15:59, Ron Yorston wrote: [...]
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?
This was explained already: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Regards, Dominik
On 13/02/2019 08:05, Neal Gompa wrote:
On Wed, Feb 13, 2019 at 2:58 AM Ron Yorston rmy@frippery.org 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.
Tom
On Wed, Feb 13, 2019 at 4:09 AM Tom Hughes tom@compton.nu wrote:
On 13/02/2019 08:05, Neal Gompa wrote:
On Wed, Feb 13, 2019 at 2:58 AM Ron Yorston rmy@frippery.org 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.
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. :)
On 13/02/2019 09:11, Neal Gompa wrote:
On Wed, Feb 13, 2019 at 4:09 AM Tom Hughes tom@compton.nu 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?
Tom
On Wed, Feb 13, 2019 at 4:34 AM Tom Hughes tom@compton.nu wrote:
On 13/02/2019 09:11, Neal Gompa wrote:
On Wed, Feb 13, 2019 at 4:09 AM Tom Hughes tom@compton.nu 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.
On 13/02/2019 09:48, Neal Gompa wrote:
On Wed, Feb 13, 2019 at 4:34 AM Tom Hughes tom@compton.nu wrote:
On 13/02/2019 09:11, Neal Gompa wrote:
On Wed, Feb 13, 2019 at 4:09 AM Tom Hughes tom@compton.nu 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 ;-)
Tom
On Wed, Feb 13, 2019 at 10:51 AM Tom Hughes tom@compton.nu wrote:
On 13/02/2019 09:48, Neal Gompa wrote:
On Wed, Feb 13, 2019 at 4:34 AM Tom Hughes tom@compton.nu wrote:
On 13/02/2019 09:11, Neal Gompa wrote:
On Wed, Feb 13, 2019 at 4:09 AM Tom Hughes tom@compton.nu 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.
Fabio
Tom
-- Tom Hughes (tom@compton.nu) http://compton.nu/ _______________________________________________ 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
* Fabio Valentini [13/02/2019 13:58] :
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.
The issue here is that, if we have someone who can maintain ant, I see no incentive for him/her to doing this under the Stewardship SIG you're proposing rather than the Java SIG which already exists.
Emmanuel
On 13/02/2019 12:58, Fabio Valentini wrote:
On Wed, Feb 13, 2019 at 10:51 AM Tom Hughes tom@compton.nu wrote:
On 13/02/2019 09:48, Neal Gompa wrote:
On Wed, Feb 13, 2019 at 4:34 AM Tom Hughes tom@compton.nu wrote:
On 13/02/2019 09:11, Neal Gompa wrote:
On Wed, Feb 13, 2019 at 4:09 AM Tom Hughes tom@compton.nu 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.
My understanding (though it may be wrong...) was that the default stream would continue to be available from the non-module Everything repo.
Tom
On Thu, Feb 14, 2019 at 5:32 AM Tom Hughes tom@compton.nu wrote:
On 13/02/2019 12:58, Fabio Valentini wrote:
On Wed, Feb 13, 2019 at 10:51 AM Tom Hughes tom@compton.nu wrote:
On 13/02/2019 09:48, Neal Gompa wrote:
On Wed, Feb 13, 2019 at 4:34 AM Tom Hughes tom@compton.nu wrote:
On 13/02/2019 09:11, Neal Gompa wrote:
On Wed, Feb 13, 2019 at 4:09 AM Tom Hughes tom@compton.nu 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.
My understanding (though it may be wrong...) was that the default stream would continue to be available from the non-module Everything repo.
Nope. We currently lack the tooling to be able to do that.
* 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.
Thanks, Florian
On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer fweimer@redhat.com 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 :)
Fabio
Thanks, Florian
On 13. 02. 19 15:32, Fabio Valentini wrote:
On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer fweimer@redhat.com 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 :)
Clusterfuck Prevention SIG?
On Fri, Feb 15, 2019 at 10:43 AM Miro Hrončok mhroncok@redhat.com wrote:
On 13. 02. 19 15:32, Fabio Valentini wrote:
On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer fweimer@redhat.com 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 :)
Clusterfuck Prevention SIG?
Sanity Preservation SIG. :D
On Wed, Feb 13, 2019 at 03:32:55PM +0100, Fabio Valentini wrote:
On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer fweimer@redhat.com 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 :)
Fedora Legacy?
Fedora Legacy?
Please don't call the current way of doing things legacy until modularity shows some maturity. For now it smells like time-to-market-driven protoduction [1] that is still missing crucial core functionality to work end-to-end.
Dridi
[1] prototype deployed to production
* Fabio Valentini:
On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer fweimer@redhat.com 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?
Thanks, Florian
On Fri, Feb 15, 2019 at 7:46 AM Florian Weimer fweimer@redhat.com wrote:
- Fabio Valentini:
On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer fweimer@redhat.com 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.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Fri, Feb 15, 2019 at 2:14 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Feb 15, 2019 at 7:46 AM Florian Weimer fweimer@redhat.com wrote:
- Fabio Valentini:
On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer fweimer@redhat.com 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.
Exactly. This clarification is definitely more succinct than I anything I could have said.
Fabio, I'm willing to help where I can with this, too.
Thank you!
-- 真実はいつも一つ!/ Always, there's only one truth!
On 2/15/19 5:16 AM, Fabio Valentini wrote:
On Fri, Feb 15, 2019 at 2:14 PM Neal Gompa ngompa13@gmail.com 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
On Wed, Mar 27, 2019 at 8:13 PM Kevin Fenzi kevin@scrye.com wrote:
On 2/15/19 5:16 AM, Fabio Valentini wrote:
On Fri, Feb 15, 2019 at 2:14 PM Neal Gompa ngompa13@gmail.com 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.
Probably both. The primary reason for starting this group now was the issues around modularizing packages before the infrastructure had caught up.
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.
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
Thank you Kevin, I've added you to the group and the list.
Fabio
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
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 Thu, Mar 28, 2019 at 11:46 AM Aleksandra Fedorova alpha@bookwar.info wrote:
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?
I agree 100% here.
Since my intention was to improve the situation around orphaned packages, this is exactly what I was thinking about:
- provide (temporary) maintenance of important, orphaned packages - monitor orphaned packages, spot issues early, actively look for new maintainers - probably report the current status regularly - discuss and refine the current orphaning / retirement process
Fabio
-- Aleksandra Fedorova bookwar
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 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 Thu, Mar 28, 2019 at 11:57 AM Miro Hrončok mhroncok@redhat.com wrote:
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?
I realize that these packages won't be tracked by the weekly "Orphaned packages" report anymore, but I don't think that accumulating more and more packages is sustainable, either.
So I was thinking about regularly (monthly or so?) posting the list of packages that's currently maintained by the SIG, and actively ask for new maintainers, similar to the "orphaned packages" report.
Fabio
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ 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
"MH" == Miro Hrončok mhroncok@redhat.com writes:
MH> You realize that once it is maintained by the group, nobody else is MH> going to take it?
When the stewardship SIG maintains a package, it should be for the sole purpose of keeping it around just long enough to avoid serious disruption that would be caused by that package being removed from the distribution. The SIG shouldn't be maintaining things indefinitely and should always give the expectation that the packages _will_ be retired (not just orphaned again) unless someone picks them up.
- J<
On 15. 02. 19 14:14, Neal Gompa wrote:
On Fri, Feb 15, 2019 at 7:46 AM Florian Weimer fweimer@redhat.com wrote:
- Fabio Valentini:
On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer fweimer@redhat.com 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.
How can I help solve this(*) on FESCo level?
I think this is tearing Fedora apart. However we cannot forbid packagers to orphan their packages.
(*) that module developers don't care about these users