DevHeads.net

What's the State of the Java SIG?

Hi everybody,

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'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.

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).

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.

Can we at least get the two Wiki pages get updated to the current state?
Does the Java ecosystem on fedora need more involvement from the community?
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.

So, if you're an active member of the Java SIG, or a (proven)packager
interested in Java packaging on fedora, please speak up - maybe we can
get this ball rolling :)

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
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.

(
also posted on discussion.fedoraproject.org:
<a href="https://discussion.fedoraproject.org/t/whats-the-state-of-the-java-sig/11714" title="https://discussion.fedoraproject.org/t/whats-the-state-of-the-java-sig/11714">https://discussion.fedoraproject.org/t/whats-the-state-of-the-java-sig/1...</a>
)

Thanks,
Fabio (decathorpe)

[0]: <a href="https://fedoraproject.org/wiki/SIGs/Java" title="https://fedoraproject.org/wiki/SIGs/Java">https://fedoraproject.org/wiki/SIGs/Java</a>
[1]: <a href="https://fedoraproject.org/wiki/Java" title="https://fedoraproject.org/wiki/Java">https://fedoraproject.org/wiki/Java</a>

Comments

Re: What's the State of the Java SIG?

By Mikolaj Izdebski at 11/18/2019 - 05:42

Hi,

On Mon, Nov 18, 2019 at 10:30 AM Fabio Valentini < ... at gmail dot com> wrote:
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 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.

Indeed, the wiki pages are very outdated.

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.

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

More help is always needed.

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.

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 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.