> Where this fails is where there's duplication of efforts. Take slf4j as an > example. mizdebsk maintains it in one of his various modules (it looks like > the javapackages module). We maintain it in the SIG as an ursine package so > things like Dogtag and a lot of other things don't break. When you go to > install Dogtag though, you never get the SIG version though: you always > get slf4j from the module (which we can't use in the BUILDROOT because its > not exposed through the API). This is a "feature" in DNF: default module > stream branches beat any ursine package, even with a higher NVR. To me, > and probably to mizdebsk as well, that's unfair.
Per request for clarification, in this email, "the SIG" should generally refer to the Stewardship SIG which I am a part (hence, "we"). mizdebsk is already a part of the Java SIG, which is a separate SIG with different (and sometimes overlapping) goals. I, and many of the Stewardship SIG members, are not a part of the Java SIG. Roughly (as I see the unofficial divide), the Stewardship SIG tends to pick up packages for a lot of Java libraries and only keeps ursine versions around. Other people (outside of the Stewardship SIG) generally maintain the modular varieties. The Java SIG cares more about modules and big-ticket items like the JDK, Eclipse, and others (build systems, etc), and enabling that stack in modules. You can read more about the packages the Stewardship SIG maintains here: - https://decathorpe.fedorapeople.org/stewardship-sig.html - https://pagure.io/stewardship-sig - https://fedoraproject.org/wiki/SIGs/Stewardship The Java SIG is here: - https://fedoraproject.org/wiki/SIGs/Java - Alex _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
