What's the State of the Java SIG?

[Fabio Valentini]

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:
https://discussion.fedoraproject.org/t/whats-the-state-of-the-java-sig/11714
)

Thanks,
Fabio (decathorpe)

[0]: https://fedoraproject.org/wiki/SIGs/Java
[1]: https://fedoraproject.org/wiki/Java

[Mikolaj Izdebski]

Hi,

On Mon, Nov 18, 2019 at 10:30 AM Fabio Valentini <decathorpe(a)gmail.com&gt; 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

[Alex Scheel]

----- Original Message -----
>  From: "Mikolaj Izdebski" <mizdebsk(a)redhat.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Cc: "java-devel" <java-devel(a)lists.fedoraproject.org&gt;
>  Sent: Monday, November 18, 2019 5:42:20 AM
>  Subject: Re: What's the State of the Java SIG? 
~snip~

>  Maintenance of obsolete packages is non-goal for Java SIG. 
A number of packages -- which the Java SIG has dropped -- are still
under active development. The Apache Commons collection, JBoss packages,
glassfish/jakarata/... packages, plexus, &c. Sure, we have a few dead
packages. We've tried our best to drop many of these. And admittedly we're
still on the JavaEE packages pre-Eclipse donation (and rename to Jakarata).
But calling these large package collections maintained by three large,
active maintainer bases (Apache Foundation, Red Hat JBoss, and the Eclipse
Foundation) unmaintained seems... wrong?

~snip~

>  > 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. 
I'm sorry Mikolaj, but I'm really confused reading this part of your mail.

A number of these packages exist as ursine packages precisely because
you've made them BUILDROOT-only! We, the Dogtag team, asked you to
reconsider that choice because we needed these as runtime dependencies,
not build-time only. You declined and said our choices were to maintain
our own modular forks or maintain the ursine variety. So, here we are.
And now, you're telling us to switch to modules? But that doesn't help
us access those BUILDROOT-only packages at runtime!


Could you help me understand how we're supposed to move forward?

- Alex