Hi,

On Mon, Nov 18, 2019 at 10:30 AM Fabio Valentini decathorpe@gmail.com wrote:

You're probably aware that the Stewardship SIG has been picking up some (±230) Java packages to keep them from getting removed from fedora, and to try to keep them maintained. Since the fraction of out-of-date packages has fallen from 70% to 30% (with 0 FTBFS issues left), I think we've done a pretty good job so far.

But, you might ask, wouldn't the Java SIG be well suited to that task?

I would answer "no". Java SIG should put effort towards maintaining important packages that are useful to our users and retiring obsolete packages. Maintenance of obsolete packages is non-goal for Java SIG.

Note that there is no "group maintenance" in Java SIG - unlike several other SIGs, Java SIG does not have a corresponding FAS group with commit access to a wide range of packages. The SIG is formed of individuals who own their packages. These individuals decide what they are interested in maintaining. If there is no volunteer to maintain particular software package then the package should be retired.

I'm asking myself the same thing, but I feel like I've been shouting into the void for months - according to the Wiki page for the SIG [0], the Java SIG has 26 listed members, of which I only recognise 4-5 as packagers who are still actively contributing to fedora. For a few others, I've already gone through the Non-responsive Maintainer process.

I confirm that many of Java maintainers listed on the wiki, or assigned as owners of individual packages, are not active any longer. I've never started non-responsive maintainer process for them because until recently during the process I would be required to take maintenance of their packages, for which I did not have capacity.

Both the page for the Java SIG [0] and Java in fedora [1] look like they haven't been updated in years - they even list some things as "wishlisted" or "in progress" which were packaged for fedora a while ago, but have since been retired again, either due to getting orphaned, or due to FTBFS issues — most of which were being caused by a lack of maintenance since circa 2017, which is when most Java packagers seem to have fallen into a black hole, as far as I can tell (getting information by deciphering Hawking Radiation is hard, you know).

Indeed, the wiki pages are very outdated.

So, I'm wondering - what's *actually* the state of the Java SIG? The IRC channel is silent, the Mailing list is dead except 0-2 posts *PER MONTH* (mostly from non-SIG members), and the Wiki pages are wildly out of date.

One of reasons IRC channel #fedora-java on freenode is mostly silent is that channel operators decided to limit this channel only to registered users, without even asking Java SIG for opinion. This is the reason I am myself generally not available in this channel - I'm using other IRC channels and/or servers.

Most of Java-related email conversations have been moved to devel mailing list. Partially because various policies require us to send emails to devel and cross-posting to java-devel makes little sense.

We didn't have an IRC meeting in years because there is no volunteer to organize one.

Can we at least get the two Wiki pages get updated to the current state?

I'm for that. But that requires a volunteer to do the work.

Does the Java ecosystem on fedora need more involvement from the community?

More help is always needed.

Or is it time for a "tabula rasa" and restart the SIG?

I really hope we can get something off the ground, soon - because I and other members of the Stewardship SIG have been spending a lot of hours each week on keeping this stuff working, but my patience and energy are reaching their limits. I'd really like to slowly start handing over Java packages to someone who's actually using them, and is interested in keeping them maintained.

IMHO effort spent on maintenance of most of these ursine Java packages is mostly wasted effort. As I said before, many times, these packages should be retired and replaced by modular packages, which are maintained by Java SIG members like me. maven and ant modules are already default streams, so users should get them instead of ursine packages. The last remaining step is enabling javapackages-tools in ursine buildroot so that ursine packages can be built with modular maven. Once that happens, there will be no reason to maintain ursine. Therefore, instead of putting time on updating ursine Maven et al. I recommend to put effort towards enabling modules in ursine buildroots.

PS, side note about Modularity: If I understand the current state of things correctly, the plan is to make the "maven:3.5" and "ant:1.10" modular packages be installable alongside non-modular Java packages. They're currently shadowing non-modular packages (since they have default streams), but I understand this is getting fixed. This means

Shadowing of ursine packages by modular packages is not a defect. That is a feature of modularity. Therefore there is nothing to fix there.

that the non-modular Java packages (especially maven, ant, xmvn, their dependencies, and other packages which are used for building Java RPM packages in fedora) will need to be maintained as non-modular packages indefinitely.

That is not true. It is entirely possible and feasible to build a distribution without ursine Maven/XMvn etc. For example look at RHEL 8 - it includes Maven and Ant only as modules. Modules are used to build ursine Java packages. The same solution should be implemented in Fedora.

-- Mikolaj Izdebski