First thank you Neil and Petr for your feedback on this. I really appreciate it.
On Tue, Oct 27, 2020 at 2:02 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
At the end of the day for Fedora, packagers are maintaining the modules, so they should be able to mark a module as EOL when they feel like they don't want it in the distribution anymore. As for module obsoletes, this is necessary for supporting transitions and upgrades, which broke two Fedora release upgrades because there was no way to handle this.Additionally, with my third-party packager hat on, I need these to be declarable in the module metadata so that it's easy to convey in a machine-enforceable way when something is maintained/supported or not. I don't know which third-parties you've been talking to, but as an actual third-party packager who does work for an ISV that supports Fedora and RHEL/CentOS for a product, I don't know where else I would put it.
Yes i agree, it seems i did not explain myself correctly. The initial proposal is to include the EOL and obsoletes inside the existing metadata files (modulemd) so i meant that. So if you wanted to handle the EOL and obsoletes metadata differently, let say it would be supervised by an engineering team (don't mean FESCO but in general), it could cause problems. But it seems the proposal by dmach in https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL already already solves that problem with a separated metadata file. So the point is probably mute at this point as you can distribute/store the new metadata file as you see fit.
On Tue, Oct 27, 2020 at 3:53 PM Petr Pisar <ppisar@xxxxxxxxxx> wrote:
On Tue, Oct 27, 2020 at 01:52:00PM +0100, Martin Curlej wrote:
> From my point of view right now it seems that this information should not
> be a part of the module (disgit, repository metadata). It is prone to human
> error when we leave this in the hands of a packager. So this would need a
> review of Engineering to be reliable.
>
Did you mean a Release Engineering, or a general engineering like FESCo?
Actually any team really. I try to look at Modularity as not environment specific (i. e. company/organization/community in which it is used.). But it seems this is Policy specific issue not a technology issue.
Why module obsoletes are dangerous for mere packagers, while package obsoletes
are safe? Can you elaborate?
It depends how you will handle the obsoletes and again how you set policies. For example, you could obsolete a module stream which packages a major version of a software with another major version. Or by human error, where you obsolete a module stream with an older module stream.
What are the other means which the 3rd parties use?
Your imagination is the limit. ;) Just joking. Now seriously. For example, Redhat and Fedora. The information about EOL and Obsoletes will be used and distributed differently. Also it depends to whom you serve your content. If you build modules just for your company and distribute it on your intranet it's different from a community driven opensource linux distribution.
I am not against EOL or Obsoletes, I know they are necessary just to get some other point of view, so we have all the requirements.
Actually when I read through my email and the points you made guys, it seems most of my concerns are policy based. So it seems we need to set some rules and policies in place so we don't repeat similar problems which occurred with the introduction of default streams or modularization of Java. Basically Modularity does not want to break Fedora again. :)
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
