Learn more about these different git repos.
Other Git URLs
With #146, default-streamed packages would have to be in the public API for all packages to use (both in BUILDROOT and at package install time).
I'd like to propose migrating all packages in a default stream's API to following the naming guidelines individually (and not follow that of the module).
Some easy examples:
maven
javapackages
ant
If we migrate these component packages (e.g., apache-commons-*, .etc...) to follow the naming guidelines, different module maintainers (or even ursine package maintainers post-BUILDROOT enablement) could better reuse the same stream and collaborate in the maintenance work. It'd be clearer to both the end user and maintainer what version of the package they'll be getting.
apache-commons-*
An alternative might be to consider a policy where, if multiple modules wish to use a package (and at least one ships a package in a default stream), we either move said package back to an ursine package for everyone to use and contribute to or remove the default stream (if nobody wishes to maintain the ursine package).
Thoughts?
+1 to the overall proposal.
I would like to add another example with little more details, stating how your proposal #1 could help put out the fire. Consider the package apache-commons-lang. It has 3 stream branches:
When a CVE is fixed in a stream (say, stream-javapackages-tools-201901), the other stream (eclipse) is left behind. Different module maintainters need to add the same patch to their own version of stream branches.
stream-javapackages-tools-201901
eclipse
REUSABILITY, the primary motto of modules (correct me if I'm wrong), is now beaten.
Instead, as @cipherboy pointed out, if proper naming guidelines are to be followed it would probably help put out the fire; eclipse can reuse the stream-javapackages-tools-201901 and need not worry about extra maintainence + javapackages-tools can continue doing what they do now (or vice versa)
Just my 2c :)
Right, and reusing apache-commons-lang example, if e.g., eclipse wanted to use it (which I don't see shipped as a module in Rawhide, so perhaps we're arguing of semantics that won't ever exist or my VM is really out of date):
apache-commons-lang
So I'd suggest deprecating those branches and standardizing on a branch called 2.6. We all seem to roughly agree on what goes into 2.6.
2.6
With Koji in the buildroot, if either eclipse or whatever else ships apache-commons-lang in a module decide to keep it, in their module, in the default stream, we should agree to standardize on a branch unless other extraordinary circumstances apply. Like, someone wants to ship a 2.6 with lots of custom patches to do something special. Or forks the project. Or.... But I doubt that will happen in this case.
And, since:
master
We could once again orphan the master branch version (assuming default module stream somewhere, etc.), but this time, nobody will notice and nothing will be affected.
NB: I'm not sure either eclipse is shipped or that apache-commons-lang is in a default module stream. The above is an example only for the purposes of this proposal.
Edit (Sep 17th 2019): I now see eclipse shipped on rawhide. There is no default stream, so apache-commons-lang gets pulled from ursine packages first, and only when Eclipse is enabled, will it get pulled from modular packages.
Metadata Update from @sgallagh: - Issue tagged with: Meeting
Metadata Update from @asamalik: - Issue untagged with: Meeting
In my opinion, package of modules are controlled by the non-modular packaging guidelines. So there is no need to repeat them in modular guidelines.
Stream names are already handled in https://docs.fedoraproject.org/en-US/modularity/policies/naming-guidelines/. "master" or "f35" streams are not used anymore.
I think this ticket can be closed.
Metadata Update from @ppisar: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.