As discussed on the fedora-devel list, a whole bunch of java packages have been marked as orphaned because the intention going forward is to only have these available in modules.
The plan right now is to blindly move forward with this, breaking BuildRequires and regular Requires (AFAIK "core" packages should not depend on modules) across the board including e.g. breaking the libreoffice build.
There are various ideas for and discussions about solving this, but there is no solution yet and it certainly will not be in place in time to avoid totally breaking rawhide.
To me this is doing things in the wrong order. First we need a solution for the (Build)Requires problem and only then can the java packages be orphaned.
There is talk about doing gating tests for new packages in rawhide to make rawhide more stable, the current java orphaning process seems to go in exactly the opposite direction totally breaking rawhide.
I think we should add a gating test for the actual package-removing step of the orphaning process too, but that is another discussion.
Proposal to vote on: "Delay removal of orphaned java-packages moved to module until a solution for the (Build)Requires has been found"
Who will maintain those packages for this time period?
"Who will maintain those packages for this time period?"
Well they are orphaned, so no-one. I'm sure some provenpackager (e.g. me) will step up if there is serious breakage.
Lets call this option 1:
The other alternatives are:
IMHO option 1. is the best intermediate solution, then once we have a proper fix the orphaned packages can be removed; another downside of 3. is also that it will likely cause these packages to stay around in the base repo longer then necessary, since once this is fixed they will not all of a sudden magically get orphaned again.
I assume everyone agrees that option 2. is not really an option.
I think we have a responsibility to our users not to carry software that we know is not maintained. If these packages are important to the Fedora community, someone needs to step up and do the work to maintain them.
Option 2 will at least have someone get notified when there are serious bugs, such as security issues.
Well we also have a responsibility to not pull the rug out from under our packagers, which this mass orphaning of all java packages without a solution in place is doing.
I've changed the title to say retiring, because that's what is going to happen if there is no delay. I haven't yet read the rest.
Anyway. Given the state of things, I think we are OK having this maintained by "general public" until we solve this properly. I don't think delaying this permanently is OK, so here's a proposal:
Delay removal of orphaned java-packages moved to modules by 4 additional weeks. Instead of retiring them 6 weeks after orphaning, do it after 10 weeks.
Here is an unconfirmed list. We need to check if everything is available in a module.
ant-contrib antlr3 aopalliance apache-commons-beanutils apache-commons-collections apache-commons-collections4 apache-commons-compress apache-commons-configuration apache-commons-csv apache-commons-discovery apache-commons-el apache-commons-fileupload apache-commons-jexl apache-commons-jxpath apache-commons-net apache-ivy apache-mime4j apache-parent apache-rat apache-resource-bundles apiguardian aqute-bnd args4j atinject avalon-framework avalon-logkit batik bcel bea-stax beust-jcommander bsf bsh c3p0 checkstyle codemodel easymock eclipse-m2e-core eclipse-m2e-workspace exec-maven-plugin felix-bundlerepository geronimo-jms geronimo-jta geronimo-parent-poms glassfish-dtd-parser glassfish-fastinfoset glassfish-jaxb glassfish-jsp glassfish-jsp-api google-guice gradle groovy guava20 hawtjni hsqldb httpcomponents-project httpunit icu4j istack-commons jackson jakarta-commons-httpclient jansi java-service-wrapper javacc-maven-plugin jaxen jdepend jettison jetty jetty-alpn-api jetty8 jna json_simple jsoup jsr-311 junit5 jvnet-parent kohsuke-pom kxml log4j maven maven-antrun-plugin maven-archiver maven-assembly-plugin maven-clean-plugin maven-compiler-plugin maven-dependency-plugin maven-enforcer maven-file-management maven-gpg-plugin maven-invoker maven-jar-plugin maven-javadoc-plugin maven-osgi maven-parent maven-plugin-build-helper maven-plugin-bundle maven-plugin-tools maven-reporting-api maven-reporting-impl maven-resolver maven-shared-utils maven-source-plugin maven-stapler-plugin maven-surefire maven-wagon nekohtml netty objectweb-asm3 opentest4j osgi-core pl plexus-archiver plexus-compiler plexus-components-pom plexus-containers plexus-interactivity plexus-interpolation plexus-utils qdox regexp sisu snakeyaml sonatype-oss-parent stax2-api stringtemplate4 tagsoup txw2 velocity woodstox-core xalan-j2 xbean xmlrpc xmvn xstream xz-java
On Thu, 2019-03-14 at 00:41 +0000, Miro Hron=C4=8Dok wrote:
+1, I think that's a reasonable compromise.
What do we expect and/or hope will happen in 4 additional weeks?
I hope for https://pagure.io/fesco/issue/2003
I don't think #2003 is realistic in a few weeks. If we decide to postpone the retirement of java packages, it'd have to be a much longer extension to be meaningful. E.g. until before F31 branching.
If #2003 is not realistic in a month and a half from now, I don't know when it is. @mizdebsk repeats on the devel list that's it is fesco who is blocking this. I wanted to avoid a disaster by giving the modularity team a bit more time. I don't want to lift the "urgent" flag by giving it another half a year. If we are orphaning ursine packages and at the same time are unable to buildrequire modular packages, we are effectively breaking Fedora.
Metadata Update from @churchyard: - Issue tagged with: meeting
That mass retiring also affects Dogtag, and therefore FreeIPA. Delaying retiring until modular packages can be buildrequired to build ursine packages ( https://pagure.io/fesco/issue/2003 or similar ) seems like the only possible way without breaking accepted Fedora features.
There is another way: affected maintainers can take the responsibility and volunteer to maintain their own dependencies. I realize that not everybody wants to maintain Java things, but delaying this is not the only possible way.
"Who will maintain those packages for this time period?" Well they are orphaned, so no-one. I'm sure some provenpackager (e.g. me) will step up if there is serious breakage.
Me too, I'm always wading in with my big provenpackager boots to upgrade and fix packages for absent Java SIG maintainers. It makes no difference whether packages are orphaned or not, it's business as usual from my PoV...
I have Eclipse to keep going -- FWIW I am working on modularisation of Eclipse and a extension of the time before retirement would help relieve the pressure a bit for me.
This was suggested many times in the past. Even if some of the affected maintainers have taken over some of the orphans there are just far too many.
Discussion of this is postponed a week while more information is gathered for a long term solution. Leaving the meeting tag on.
@fcami these are many for provenpackagers too. And proven packages do not have any specific knowledge about them.
If you depend on these packages, don't you want at least to be explicitly informed on their CVE's and issues? Even if just to check if your package is affected by it?
You don't have to really port new features and major changes there, it is more about assessing the risk you and your component get from it and maintaining it from that perspective.
@fcami these are many for provenpackagers too. And proven packages do not have any specific knowledge about them. If you depend on these packages, don't you want at least to be explicitly informed on their CVE's and issues? Even if just to check if your package is affected by it?
@bookwar this is reasonable, but as their modular counterparts will be maintained I would rather be able to BR these once https://pagure.io/fesco/issue/2003 is resolved. All that is asked here is that packages do not get retired before a proper solution is built.
The clock is ticking down and while some of us ( https://pagure.io/releng/issue/8178 + https://pagure.io/releng/issue/8171 and probably countless others) have taken as many as we can there is still a chance of the deadline arriving without a solution. Also, I do not think it wise for people unfamiliar with these packages to chown them, because owning a package is in itself a big responsibility.
This was discussed during today's FESCo meeting: AGREED: FESCo asks the Stewardship SIG and other maintainers to take as many packages as possible. Packages which haven't found new owners will be retired according to schedule, but not earlier than April 1st. (+7, 0, 0)
ACTION: bookwar to write an e-mail to the Stewardship SIG and other maintainers (zbyszek, 15:45:35)
Metadata Update from @zbyszek: - Issue untagged with: meeting - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @churchyard: - Issue status updated to: Open (was: Closed)
Metadata Update from @churchyard: - Issue close_status updated to: Rejected - Issue status updated to: Closed (was: Open)
Note: The ticket was about delaying, that didn't really happen (whether the packages should have been delayed today or on april the 1st is a technicality). So I've reclosed this is rejected.
Login to comment on this ticket.