missing modules in content

[alexxa]

hardware-support, host, maven, ninja, and platform modules are not in f27-content-tracking. Also only one of nodejs streams is mentioned there.

/cc @whitel @asamalik @KarstenHopp

[igor-raits]

@alexxa note that I don't plan to track any of my modules (libtom, ninja, meson) on this github organizations. I maintain them in Fedora and don't really care what you are doing here.

No offence, just saying how things are working.

[alexxa]

@ignatenkobrain This issue is not about tracking those modules, so no offense taken. I just need a plain list of all modules at one place, so I know which modules to test the image against. Also I was requested to prepare a report "something like "76% of Committed modules install, 47 % of Targeted modules install, 29 % of Proposed modules install". And I can't make it if not all modules are listed here respectively. RVokal wants up-to-date list of expected modules too. And as he said we had several places which list the modules, all of them were different, and no idea which was up-to-date.

[igor-raits]

@alexxa take list from PDC, this is only one reliable place. Or from pungi-fedora which lists all modules which are getting into compose. I think that's what you are looking for.

https://pagure.io/pungi-fedora/blob/f27/f/variants-modular.xml

[alexxa]

@ignatenkobrain I know about PDC, but that XML doesn't sort modules in Commited/Targeted/Proposed whatever groups and what if those are changed? And what about streams and profiles? At the moment there are several issues opened in some modules git repos, saying some modules are missing profiles. I don't want to check every repo to see if there is such issue and what if some are not known/reported yet?

[mattdm]

@ignatenkobrain Pointing a human to an XML file seems like a sign something has gone wrong somewhere. :)

And, overall, this doesn't seem like what we need for planning / scheduling / project-tracking purposes. The presence of a module on that list only shows that that module is getting into the compose somehow, not why or what for, and it doesn't show the status of modules that are missing.

[igor-raits]

@alexxa what is Committed/Targeted/Proposed? Every module, stream which is not in there is not available for users.

@mattdm totally agree with you. Although "what for" and "why" doesn't seem to be useful to me from this repository. It is same as for RPM packaging, you want to get XXX into repo, you need to get all the dependencies. You can have some list of things which needs to be packaged, but it is optional. In our case, we need freeipa IIUC, so let the people responsible for creating this particular module to take care of rest.

[alexxa]

@ignatenkobrain Commited, Targeted, Proposed.

[igor-raits]

@alexxa nonono, I'm now talking as a module packager who is not involved much with the modularity team. Those links contain some information about modules which are in fedora or some other people want to have there. But it contains outdated information and it you should not assume that module maintainers will update pages themselves.. Or I misunderstood what you are asking in the ticket.

[alexxa]

@ignatenkobrain my ticket reports that several modules are not listed in this README

[alexxa]

@ignatenkobrain btw, I don't see maven module in XML. Is it correct?

[igor-raits]

@alexxa it's in Bikeshed, but not in F27... @whitel might want to add it there..

[contyk]

I suppose the README could be simplified to only list the required modules for this release; the compose may contain many, many more as people independently package their own content and have it made available. So I would propose dropping the, eh, Proposed section entirely, as it's only confusing.

@alexxa, focusing your testing on the commited & targetted modules would be a good idea. The rest (whatever else is included in variants-modular.xml) can be safely ignored.

If having platform, host and hardware-support on that list would help you, we can certainly add them. hardware-support even has a repo under fedora-modules.

[KarstenHopp]

I agree with ignatenkobrain that pungi-fedora is the only authorative source that shows what gets into a compose and can/should be tested. You can use f27-content-tracking as a guide for the importance of those modules, though. I also agree with contyk that we need to focus on commited & targeted modules atm.

The main purpose of f27-content-tracking was to have a status page that could be used by @langdon to create pull requests for modules/streams to be included in pungi-fedora.

[langdon]

+1 to adding the "base" modules to the committed list (platform, host, etc)
+1 to removing proposed altogether

I think we need to investigate how we want to do compose testing more formally and actually look at the variants file as the source of modules and mark failures with release blocking modules separately from non-release blocking. We need to coordinate this with fedora-qa as we are getting close to wanting "proper Fedora testing" rather than the ad hoc work we needed to setup for ourselves.

@Irina let's setup some time with adamw to work this through.

[KarstenHopp]

I've added platform, host, hardware-support and shim