On Tue, Nov 19, 2019 at 5:12 PM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: > > Hi, Fabio, > > On Mon, Nov 18, 2019 at 10:30 AM Fabio Valentini <decathorpe@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
