On Tue, Nov 19, 2019 at 5:12 PM Aleksandra Fedorova <al...@bookwar.info> wrote: > > Hi, Fabio, > > On Mon, Nov 18, 2019 at 10:30 AM Fabio Valentini <decatho...@gmail.com> wrote: >> >> 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. >
Hi Aleksandra! > I'd like to make it clear first that the work of Stewardship SIG is highly > appreciated. Thank you for doing it. Thank you. That's good to hear. >> >> 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. > > > I agree with your point that Stewardship SIG supposed to be only a temporary > owner of certain packages. The goal of the SIG is to step in if there is a > critical unresolved issue in the current state, and then route the issue to > the right owner. > > > 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 :) > > But I'd like to reset the conversation here. > > The point of Java SIG and I think the nature of your request to it is not to > take the responsibility of packages Stewardship SIG inherited. > > Rather we have a generic problem: how one can package and maintain Java stack > and Java application in Fedora. Java SIG supposed to be the owner of this > topic. It needs to provide the common place for Java developers (app > maintainers as well as toolchain maintainers) to communicate to each other > and come up with solutions to the common issues. > > The way how exactly the issue should be resolved (with or without modules, > with or without buildroot packages and so on) is for the Java SIG members to > figure out. > > Thus, I would suggest to frame the request differently. Instead of asking who > can maintain certain non-modular Java packages, let's ask who can describe > the path forward for Java-related packages in Fedora, and who is willing to > work on it. > > I see that Mikolaj has a vision how it supposed to work. And I think he spent > quite some time designing the workflow which would fit this vision, thus it > is worth to listen to it with an open mind. > > @Mikolaj, can you document the setup for java toolchain somewhere other than > a mailing list? Buildroot modules, defaults streams, what Java packager > should and shouldn't use... Probably one of those outdated wiki pages can be > updated for that. (snip) > This will create a starting point for this conversation and set the context, > so that app maintainers can work constructively with it rather than fall into > yet another generic modularity conversation. I agree, this seems like a productive way forward. It's also the reason why I didn't want to prominently mention Modularity in the original message, and instead tried to focus on the issue at hand - the future of Java packaging in fedora. There also seems to be conflicting information floating around concerning the Java modules (maven, ant, javapackages-tools, ... what else is there?) - what are they for, are they available at "runtime" or only as a "build-only" dependency, and so on. The current situation leads to a lot of duplicated effort (both in non-modular and modular branches), instead of making packaging easier and more approachable. Alex's comment that they'd have to bundle a lot of Java dependencies in a theoretical dogtag-pki module, since they're only available at build-time, not at run-time, doesn't make it seem like the current situation is designed to eliminate duplication of work either - rather the opposite. Fabio >> 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. > > > -- > Aleksandra Fedorova > bookwar > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org
