Re: pdfbox and batik (was: Re: [fedora-java] What's the State of the Java SIG?)
On Mon, Nov 25, 2019 at 12:31 PM Kevin Kofler wrote: > As an example of the sorry state of the Java SIG, pdfbox and batik were > orphaned 2 weeks ago, but those are dependencies of fop, which is a > dependency of publican, which is used by appstream to build documentation, > and half of the distribution (including the entire KF5 stack, through > extra- > cmake-modules) depends on appstream. > > Java is not an isolated island (despite its name ;-) ). Most Java stuff > can > be done without (and upstream JARs used instead), but the dependencies of > non-Java packages MUST be taken care of by somebody. > The world is still waiting for the next Java hero to appear :( . > > Kevin Kofler > ___ > 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 > -- Alexander Kurtakov Red Hat Eclipse Team ___ 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
pdfbox and batik (was: Re: [fedora-java] What's the State of the Java SIG?)
As an example of the sorry state of the Java SIG, pdfbox and batik were orphaned 2 weeks ago, but those are dependencies of fop, which is a dependency of publican, which is used by appstream to build documentation, and half of the distribution (including the entire KF5 stack, through extra- cmake-modules) depends on appstream. Java is not an isolated island (despite its name ;-) ). Most Java stuff can be done without (and upstream JARs used instead), but the dependencies of non-Java packages MUST be taken care of by somebody. Kevin Kofler ___ 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
Re: What's the State of the Java SIG?
On Wed, 20 Nov 2019 at 10:25, Kevin Kofler wrote: > > Stephen John Smoogen wrote: > > Your comments on what you expect OTHER people to do for YOU come across as > > we are all your slaves or serfs. I really expect that isn't your > > intention, but this mode of communication undermines everything you say. > > Now this is a fun inversion, trying to make it look like I am the one > imposing diktats on other people. I have never taken a package private, nor > have I ever tried to impose onto other people what they are allowed to do > with my packages and what not. (E.g., I have deliberately NOT followed the > recently introduced "package deprecation" process for qt3 and kdelibs3, > because I believe that, as long as those compatibility packages are > available, everyone should be allowed to use them without restrictions.) So > I do not think it is unfair for me to complain about such an attitude. > You are correct and I am in the wrong here. It is clear I am not helping any of these conversations and I am not being excellent to others. I take responsibility for my comments and apologize to you and others on the list. -- Stephen J Smoogen. ___ 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
Re: What's the State of the Java SIG?
Stephen John Smoogen wrote: > On Tue, 19 Nov 2019 at 22:07, Kevin Kofler wrote: >> Buildroot-only modules? Stuff Java packagers shouldn't use? Why should we >> let one individual packager hold the entire Java ecosystem on Fedora >> hostage with such antisocial diktats? > > Because the alternative is it all gets removed[*]. Or it may get picked up by somebody who does not impose such diktats. The whole point of this thread is an attempt to find people willing to maintain those packages in a more cooperative way. It runs completely counter to the concept of a community distribution to allow a maintainer to take a package private, hide it from end users, and dictate what other packages can or cannot use that package. It also conflicts with the technical goal of producing a self-hosting distribution. > There is no one else taking this over unless you are volunteering your > time to do so. That is yet to be determined. And if truly nobody picks up those packages, then maybe the better solution is really to drop them entirely (pointing people to upstream JARs instead) or move them to a Copr. (One can build modules in Copr, too.) > Your comments on what you expect OTHER people to do for YOU come across as > we are all your slaves or serfs. I really expect that isn't your > intention, but this mode of communication undermines everything you say. Now this is a fun inversion, trying to make it look like I am the one imposing diktats on other people. I have never taken a package private, nor have I ever tried to impose onto other people what they are allowed to do with my packages and what not. (E.g., I have deliberately NOT followed the recently introduced "package deprecation" process for qt3 and kdelibs3, because I believe that, as long as those compatibility packages are available, everyone should be allowed to use them without restrictions.) So I do not think it is unfair for me to complain about such an attitude. Kevin Kofler ___ 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
Re: What's the State of the Java SIG?
On Tue, 19 Nov 2019 at 22:07, Kevin Kofler wrote: > > Aleksandra Fedorova wrote: > > 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. > > Buildroot-only modules? Stuff Java packagers shouldn't use? Why should we > let one individual packager hold the entire Java ecosystem on Fedora hostage > with such antisocial diktats? > Because the alternative is it all gets removed[*]. There is no one else taking this over unless you are volunteering your time to do so. Your comments on what you expect OTHER people to do for YOU come across as we are all your slaves or serfs. I really expect that isn't your intention, but this mode of communication undermines everything you say. * Rolling back to older versions premodularity would bring a lot of packages which did not already build from source, which were outdated and broken in other places. Packages which are not 'integrated' as an operating system with the rest of the system. They would sit there and rot because it is clear that everyone wants to tell the cook how to make the dinner, but no one wants to help until it is served. And rolling back would again require someone to volunteer to do that work. > I stand by my position that buildroot-only content of any kind (buildroot- > only packages, buildroot-only modules, packages filtered from modules, etc.) > should just not be allowed in Fedora, ever. (And where it has already > slipped through, it needs to be made user-installable (and available for all > other packages) as soon as possible.) This is not even directly related to > Modularity, Modularity just happens to be the way this anti-feature was > implemented. > > Kevin Kofler > ___ > 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 -- Stephen J Smoogen. ___ 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
Re: What's the State of the Java SIG?
Aleksandra Fedorova wrote: > 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. Buildroot-only modules? Stuff Java packagers shouldn't use? Why should we let one individual packager hold the entire Java ecosystem on Fedora hostage with such antisocial diktats? I stand by my position that buildroot-only content of any kind (buildroot- only packages, buildroot-only modules, packages filtered from modules, etc.) should just not be allowed in Fedora, ever. (And where it has already slipped through, it needs to be made user-installable (and available for all other packages) as soon as possible.) This is not even directly related to Modularity, Modularity just happens to be the way this anti-feature was implemented. Kevin Kofler ___ 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
Re: What's the State of the Java SIG?
On Mon, 18 Nov 2019 at 11:17, John M. Harris Jr wrote: > I must disagree. That it "works" in RHEL doesn't mean that it should be done > in Fedora. The current situation in Fedora, where maven and ant have been > "moved" to modules has screwed over the Eclipse packagers, for example, and > more are to follow. > I'm flattered that you think there is more than one Eclipse packager these days, but it is not my perception that choices made by the maven and ant maintainer has screwed over Eclipse. >From my PoV the problem is that Ursa Prime née Major has been coming Real Soon Now™ for years to obviate the build issues but it just never materialised. This is why the Eclipse stack has gotten into a bit of a pickle -- I waited far too long with far too much naive optimism before modularising and I'm sad to say that not modularising Eclipse sooner has done a great disservice to users. TBH as a desktop application, I see a brighter future in Flatpak for Eclipse and maybe when our Flatpak distribution is mature enough, we can eventually stop shipping RPMs altogether ___ 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
Re: What's the State of the Java SIG?
On Tue, Nov 19, 2019 at 5:12 PM Aleksandra Fedorova wrote: > > Hi, Fabio, > > On Mon, Nov 18, 2019 at 10:30 AM Fabio Valentini 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,
Re: What's the State of the Java SIG?
Hi, Fabio, On Mon, Nov 18, 2019 at 10:30 AM Fabio Valentini 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. > I'd like to make it clear first that the work of Stewardship SIG is highly appreciated. Thank you for doing it. > 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. 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. 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
Re: [fedora-java] What's the State of the Java SIG?
On Tue, Nov 19, 2019 at 4:54 PM Stephen John Smoogen wrote: > On Tue, 19 Nov 2019 at 09:17, Gerald Henriksen wrote: > > > > On Mon, 18 Nov 2019 21:08:02 -0800, you wrote: > > > > >On 11/18/19 7:29 PM, Neal Gompa wrote: > > >> I can't speak for everyone, but at least my experience was that it was > > >> functionally impossible to discover how to package Java stuff. In a > > >> lifetime (and a job) ago, I was much more engaged in the Java > > >> ecosystem. Back then, I tried to learn how to package and ship Java > > >> stuff in Fedora. But the documentation was (and still is) incredibly > > >> poor. I only managed to package one library, and it was not easy for > > >> me to figure out how to do it. The amount of effort I expended to do > > >> it put me off to doing more in the Java ecosystem. > > > > > >Maybe I misunderstood the earlier comment. I understand that Java can > > >be difficult to package, but I thought Gerald was saying that using > > >modules somehow made it easier. > > > > I have no idea whether modules make it easier or not. > > > > My point was that the Java SIG collapsed long before the modules > > became an issue, so "rebooting" the Java SIG isn't going to change > > anything unless those calling for the reboot come up with packagers > > for the Java ecosystem. > > > > Let us be clear here.. Java and Fedora have never done well. The > original 'Everything must be broken into separate parts and > integrated' vs 'the ecosystem bundles everything' was with Java and > made anyone working with Java in Fedora grind teeth on either being > way behind on some software or not having it all in Fedora. The > problem is that work was unmaintainable especially when the entire > ecosystem is built around having bundles of software where you only > needed 1-2 classes from a specific zip. Then there is a bunch of stuff > in these languages where you need to rebuild things in a specific > order or multiple times or a dozen other things using tools you need > but no one is maintaining. The original SIG was a bunch of hero > maintainers who said 'ok I am going to make this happen' and put in a > hell of an effort to get a lot of stuff unbundled and integrated. [At > the time in I think Fedora 8-10 timeframe, there was a large push by > certain people to get rid of all Java from the OS because it could not > be properly integrated. ] > > Over time these hero's burnt out just like the hero's who have > maintained perl, php, TeX, Nodejs, and many other stacks have. > Modules are basically a last gasp for them to trying to keep this > maintainable for the last hero maintainers. They allow for you to spec > out a lot of grunt work of building X before Y so you can rebuild Y > with X. They allow you to say I needed this thing but I am not > maintaining it so I am not shipping it... if someone will take it over > I can remove that hidden part but I don't have time to keep this up. > > It isn't just a matter of trying to build a team to maintain these... > it is a lot of work dealing with things volunteer packagers* don't > have time for: > o) Documenting each package > o) Documenting how to break apart X into usable rpm packages > o) Writing scripts to try and automate that in the rpmbuild parts > o) Deal with the fact that every upstream software is slightly > different (aka perl Makefile.pl output is never the same) > o) Keep up with the fact that every other upstream release has > decided to add N dependencies which are either not in Fedora or not > the version in Fedora. > > Doing this with a team means a lot of time coordinating with each > other. That means spending a lot of time in meetings with each other > or ending getting burnt too many times with Packager B updating Y > which breaks your Z. [Modular streams are supposed to help you on > this.. but it just makes it a combinatoric headache you have to deal > with even more meetings to keep from happening.] Most volunteers don't > like meetings, and they usually don't have time for them.. so we end > up with a very fractured space. Most of the problems we are seeing > with modules are from fractures already there but only shown when > FTBFS happened in the past. > > * I am going to be very clear here. Even if Red Hat pays someone a > salary, most of our work on Fedora is volunteer time. Our main job is > probably only related to the packages we put in by the fact we need it > to complete said job. We usually don't have time to much more than > people who have weekends on something. > Couldn't have expressed better what I think !!! > > > > -- > Stephen J Smoogen. > ___ > 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: >
Re: [fedora-java] What's the State of the Java SIG?
On Tue, 19 Nov 2019 at 09:17, Gerald Henriksen wrote: > > On Mon, 18 Nov 2019 21:08:02 -0800, you wrote: > > >On 11/18/19 7:29 PM, Neal Gompa wrote: > >> I can't speak for everyone, but at least my experience was that it was > >> functionally impossible to discover how to package Java stuff. In a > >> lifetime (and a job) ago, I was much more engaged in the Java > >> ecosystem. Back then, I tried to learn how to package and ship Java > >> stuff in Fedora. But the documentation was (and still is) incredibly > >> poor. I only managed to package one library, and it was not easy for > >> me to figure out how to do it. The amount of effort I expended to do > >> it put me off to doing more in the Java ecosystem. > > > >Maybe I misunderstood the earlier comment. I understand that Java can > >be difficult to package, but I thought Gerald was saying that using > >modules somehow made it easier. > > I have no idea whether modules make it easier or not. > > My point was that the Java SIG collapsed long before the modules > became an issue, so "rebooting" the Java SIG isn't going to change > anything unless those calling for the reboot come up with packagers > for the Java ecosystem. > Let us be clear here.. Java and Fedora have never done well. The original 'Everything must be broken into separate parts and integrated' vs 'the ecosystem bundles everything' was with Java and made anyone working with Java in Fedora grind teeth on either being way behind on some software or not having it all in Fedora. The problem is that work was unmaintainable especially when the entire ecosystem is built around having bundles of software where you only needed 1-2 classes from a specific zip. Then there is a bunch of stuff in these languages where you need to rebuild things in a specific order or multiple times or a dozen other things using tools you need but no one is maintaining. The original SIG was a bunch of hero maintainers who said 'ok I am going to make this happen' and put in a hell of an effort to get a lot of stuff unbundled and integrated. [At the time in I think Fedora 8-10 timeframe, there was a large push by certain people to get rid of all Java from the OS because it could not be properly integrated. ] Over time these hero's burnt out just like the hero's who have maintained perl, php, TeX, Nodejs, and many other stacks have. Modules are basically a last gasp for them to trying to keep this maintainable for the last hero maintainers. They allow for you to spec out a lot of grunt work of building X before Y so you can rebuild Y with X. They allow you to say I needed this thing but I am not maintaining it so I am not shipping it... if someone will take it over I can remove that hidden part but I don't have time to keep this up. It isn't just a matter of trying to build a team to maintain these... it is a lot of work dealing with things volunteer packagers* don't have time for: o) Documenting each package o) Documenting how to break apart X into usable rpm packages o) Writing scripts to try and automate that in the rpmbuild parts o) Deal with the fact that every upstream software is slightly different (aka perl Makefile.pl output is never the same) o) Keep up with the fact that every other upstream release has decided to add N dependencies which are either not in Fedora or not the version in Fedora. Doing this with a team means a lot of time coordinating with each other. That means spending a lot of time in meetings with each other or ending getting burnt too many times with Packager B updating Y which breaks your Z. [Modular streams are supposed to help you on this.. but it just makes it a combinatoric headache you have to deal with even more meetings to keep from happening.] Most volunteers don't like meetings, and they usually don't have time for them.. so we end up with a very fractured space. Most of the problems we are seeing with modules are from fractures already there but only shown when FTBFS happened in the past. * I am going to be very clear here. Even if Red Hat pays someone a salary, most of our work on Fedora is volunteer time. Our main job is probably only related to the packages we put in by the fact we need it to complete said job. We usually don't have time to much more than people who have weekends on something. -- Stephen J Smoogen. ___ 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
Re: [fedora-java] What's the State of the Java SIG?
On Mon, 18 Nov 2019 21:08:02 -0800, you wrote: >On 11/18/19 7:29 PM, Neal Gompa wrote: >> I can't speak for everyone, but at least my experience was that it was >> functionally impossible to discover how to package Java stuff. In a >> lifetime (and a job) ago, I was much more engaged in the Java >> ecosystem. Back then, I tried to learn how to package and ship Java >> stuff in Fedora. But the documentation was (and still is) incredibly >> poor. I only managed to package one library, and it was not easy for >> me to figure out how to do it. The amount of effort I expended to do >> it put me off to doing more in the Java ecosystem. > >Maybe I misunderstood the earlier comment. I understand that Java can >be difficult to package, but I thought Gerald was saying that using >modules somehow made it easier. I have no idea whether modules make it easier or not. My point was that the Java SIG collapsed long before the modules became an issue, so "rebooting" the Java SIG isn't going to change anything unless those calling for the reboot come up with packagers for the Java ecosystem. And one of the reasons few want to package Java stuff is that because for most of the Java stuff the users prefer to simply install the provided jdk/jre and then download the jar files from upstream, because by using official upstream provided jar files they can get help from upstream with any problems. ___ 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
Re: [fedora-java] What's the State of the Java SIG?
On 11/18/19 7:29 PM, Neal Gompa wrote: On Mon, Nov 18, 2019 at 9:34 PM Samuel Sieb wrote: On 11/18/19 3:40 PM, Gerald Henriksen wrote: On Mon, 18 Nov 2019 13:37:39 +0100, you wrote: Fabio Valentini wrote: Or is it time for a "tabula rasa" and restart the SIG? IMHO, yes. Kick out the 1 or 2 Modularity fundamentalists that form the current remains of the Java SIG and create a new Java SIG from scratch that actually cares about packaging Java properly in and for (non-modular) Fedora. Great, you eliminate the remaining members of the Java SIG (those who didn't go running away because forcing Java stuff into RPMs was too painful). I've seen statements like this multiple times and I don't understand it. As far as I understand modularity, you're still creating rpms, so what's the difference? I'm just hoping for a simple answer here, not wanting to create another long thread like the other ones. I can't speak for everyone, but at least my experience was that it was functionally impossible to discover how to package Java stuff. In a lifetime (and a job) ago, I was much more engaged in the Java ecosystem. Back then, I tried to learn how to package and ship Java stuff in Fedora. But the documentation was (and still is) incredibly poor. I only managed to package one library, and it was not easy for me to figure out how to do it. The amount of effort I expended to do it put me off to doing more in the Java ecosystem. Maybe I misunderstood the earlier comment. I understand that Java can be difficult to package, but I thought Gerald was saying that using modules somehow made it easier. ___ 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
Re: [fedora-java] What's the State of the Java SIG?
On Mon, Nov 18, 2019 at 9:34 PM Samuel Sieb wrote: > > On 11/18/19 3:40 PM, Gerald Henriksen wrote: > > On Mon, 18 Nov 2019 13:37:39 +0100, you wrote: > > > >> Fabio Valentini wrote: > >>> Or is it time for a "tabula rasa" and restart the SIG? > >> > >> IMHO, yes. Kick out the 1 or 2 Modularity fundamentalists that form the > >> current remains of the Java SIG and create a new Java SIG from scratch that > >> actually cares about packaging Java properly in and for (non-modular) > >> Fedora. > > > > Great, you eliminate the remaining members of the Java SIG (those who > > didn't go running away because forcing Java stuff into RPMs was too > > painful). > > I've seen statements like this multiple times and I don't understand it. > As far as I understand modularity, you're still creating rpms, so > what's the difference? I'm just hoping for a simple answer here, not > wanting to create another long thread like the other ones. I can't speak for everyone, but at least my experience was that it was functionally impossible to discover how to package Java stuff. In a lifetime (and a job) ago, I was much more engaged in the Java ecosystem. Back then, I tried to learn how to package and ship Java stuff in Fedora. But the documentation was (and still is) incredibly poor. I only managed to package one library, and it was not easy for me to figure out how to do it. The amount of effort I expended to do it put me off to doing more in the Java ecosystem. Nowadays, I'm mostly in the Python ecosystem, which has a much stronger packaging story. Heck, I think right now, the two major language ecosystems with bad packaging stories are Java and Go, for different reasons. Java's is because the whole packaging process and documentation is in major disrepair. Go's is because the language tooling sucks, and the lack of a solid foundation makes it difficult to make good packaging tooling for that ecosystem. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
Re: [fedora-java] What's the State of the Java SIG?
On 11/18/19 3:40 PM, Gerald Henriksen wrote: On Mon, 18 Nov 2019 13:37:39 +0100, you wrote: Fabio Valentini wrote: Or is it time for a "tabula rasa" and restart the SIG? IMHO, yes. Kick out the 1 or 2 Modularity fundamentalists that form the current remains of the Java SIG and create a new Java SIG from scratch that actually cares about packaging Java properly in and for (non-modular) Fedora. Great, you eliminate the remaining members of the Java SIG (those who didn't go running away because forcing Java stuff into RPMs was too painful). I've seen statements like this multiple times and I don't understand it. As far as I understand modularity, you're still creating rpms, so what's the difference? I'm just hoping for a simple answer here, not wanting to create another long thread like the other ones. ___ 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
Re: [fedora-java] What's the State of the Java SIG?
On Mon, 2019-11-18 at 18:40 -0500, Gerald Henriksen wrote: > On Mon, 18 Nov 2019 13:37:39 +0100, you wrote: > > > Fabio Valentini wrote: > > > Or is it time for a "tabula rasa" and restart the SIG? > > > > IMHO, yes. Kick out the 1 or 2 Modularity fundamentalists that form > > the > > current remains of the Java SIG and create a new Java SIG from > > scratch that > > actually cares about packaging Java properly in and for (non- > > modular) > > Fedora. > > Great, you eliminate the remaining members of the Java SIG (those who > didn't go running away because forcing Java stuff into RPMs was too > painful). As far as I understand those members want force users (java users) to use modules -- Sérgio M. B. ___ 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
Re: [fedora-java] What's the State of the Java SIG?
- Original Message - > From: "Gerald Henriksen" > To: "Development discussions related to Fedora" > > Sent: Monday, November 18, 2019 6:40:54 PM > Subject: Re: [fedora-java] What's the State of the Java SIG? > > On Mon, 18 Nov 2019 13:37:39 +0100, you wrote: > > >Fabio Valentini wrote: > >> Or is it time for a "tabula rasa" and restart the SIG? > > > >IMHO, yes. Kick out the 1 or 2 Modularity fundamentalists that form the > >current remains of the Java SIG and create a new Java SIG from scratch that > >actually cares about packaging Java properly in and for (non-modular) > >Fedora. > > Great, you eliminate the remaining members of the Java SIG (those who > didn't go running away because forcing Java stuff into RPMs was too > painful). > > Now where are you going to get new members to create this new Java > SIG? > > I mean, the Java SIG isn't forcing Java packagers to use Modularity, > so that isn't why the Java SIG is dying. For historical context... Without Ursa Prime/Major/whatever we're calling it now, that's where we've been for the last... n > 6 months. If you depended on Ant, Maven, or any of the minor libraries they've modularized and put in their default module stream, the Java SIG's (un)official(?) policy was to have you modularize. Because that was the only way to use these packages! And if your runtime dependencies are in javapackages-tools? Good luck! You have to rebuild them inside your own module! It has entirely been the efforts of the Stewardship SIG to enable ursine users. We've done that by continuing to packaging many of the libraries that the Java SIG has either dropped entirely or made modular-only. For the last n > 6 months, packages such as LibreOffice and Dogtag have continued building only because we keep maintaining these packages as ursine. We did this in part to keep our own packages building and in part because we don't believe modular packages are a real answer to maintainership problems. Purely speculation on my part, but part of what likely caused the Java SIG to effectively dissolve was because each maintainer was an island, a hero. They maintained all their packages on their own; there is no "Java SIG" FAS packaging group. As Mikolaj has said, the meetings stopped, the mails stopped. People probably just quit working together. Part of what we've tried to do differently in the Stewardship SIG is encourage community and peer support. We're a FAS group and all our packages are owned by the collective group. We maintain public lists of what's in need of review [0], what we maintain [1], what we're looking for updates on [2], and what we're in the process of doing [3]. Anyone is free to contribute to the Stewardship SIG too! Fabio does a lot of work, and we're deeply thankful for that! But a few of us double check his work, help out on minimizing package dependencies as we get time, catch CVE updates, and perform rebases too. We're always looking for more members, and if you're interested in joining, just shoot a mail! Now, I do want to point out there are two faces to the Java SIG. There's the set of maintainers who maintain the soft underbelly of Java libraries. That's mostly Mikolaj now. People like gil and others, while at one point large Java package maintainers, have since moved on and their packages have been orphaned through the unresponsive maintainer process. I think the Eclipse team is part of that too. But it did seem rather uncoordinated, from the outside, the whole ant+maven causing Eclipse to modularize dance. But there's also the quiet maintainers of the JVM itself, who we're all grateful for their quiet work. They've not tried to modularize as far as I can tell. For all their hard work, we're thankful! We, the Stewardship SIG, have said before that if you need packages maintained that we're about to orphan, tell us! We'd keep them around and do our best to update them. We try not to orphan everything we have, we announce on the list and cc dependent package maintainers, and generally try to be good stewards of the community. We had offered in the past, on the list, to help Eclipse maintain whatever packages they needed to stay ursine, but that offer went unanswered. And if your application is major or critical to Fedora, like LibreOffice, Dogtag, or even Eclipse are, we'd be consider taking on new packages and maintaining them too, if they benefit the community. However, without new members and more time on our hands, I'm not sure how longer we'll be able to continue. Being brutally honest, Fabio does a LOT of work. We need a long term solution that doesn't leave all our ursine packages broken. Regardless of whether they're part of Fedora, existing only hidden, private networks of universities and corporations, or lurking in someone's COPR. - Alex [0]: https://decathorpe.fedorapeople.or
Re: [fedora-java] What's the State of the Java SIG?
On Mon, 18 Nov 2019 13:37:39 +0100, you wrote: >Fabio Valentini wrote: >> Or is it time for a "tabula rasa" and restart the SIG? > >IMHO, yes. Kick out the 1 or 2 Modularity fundamentalists that form the >current remains of the Java SIG and create a new Java SIG from scratch that >actually cares about packaging Java properly in and for (non-modular) >Fedora. Great, you eliminate the remaining members of the Java SIG (those who didn't go running away because forcing Java stuff into RPMs was too painful). Now where are you going to get new members to create this new Java SIG? I mean, the Java SIG isn't forcing Java packagers to use Modularity, so that isn't why the Java SIG is dying. The only reason modularity is an issue is because no one else wants to maintain Java packages in the first place. ___ 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
Re: [fedora-java] Re: What's the State of the Java SIG?
Alex Scheel wrote: > 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! This is exactly why I think buildroot-only packages need to be forbidden in Fedora. Kevin Kofler ___ 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
Re: [fedora-java] What's the State of the Java SIG?
On Mon, 2019-11-18 at 13:37 +0100, Kevin Kofler wrote: > Fabio Valentini wrote: > > Or is it time for a "tabula rasa" and restart the SIG? > > IMHO, yes. Kick out the 1 or 2 Modularity fundamentalists that form > the > current remains of the Java SIG and create a new Java SIG from > scratch that > actually cares about packaging Java properly in and for (non- > modular) > Fedora. +1 is very strange that java want modularity since we can have various versions of java installed at same time I hope, never use modules for a very long time. > The current modules are missing a lot of Java software that users > care about > (e.g. NetBeans, etc. – some, such as NetBeans, had already been > retired > before Modularity became a thing, because the Java SIG had already > been > disintegrating back then, some was lost in the move to modules), have > put > Eclipse into a broken state, have simply replaced the adapted > JPackage > version of Maven (with RPM integration) with a vanilla upstream Maven > that > does not have this feature (I cannot see what advantage that change > brings), > etc. > > And I do not see at all what advantage end users would get from > those > packages being in modules. Both Maven and Ant are tools where you > normally > always want the latest version, there is not much value in being able > to > pick a specific version stream. > > Kevin Kofler > ___ > 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 -- Sérgio M. B. ___ 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
Re: What's the State of the Java SIG?
- Original Message - > From: "Mikolaj Izdebski" > To: "Development discussions related to Fedora" > > Cc: "java-devel" > 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, 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 ___ 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
Re: What's the State of the Java SIG?
On Mon, Nov 18, 2019 at 1:33 PM Mikolaj Izdebski wrote: > > On Mon, Nov 18, 2019 at 12:17 PM John M. Harris Jr > wrote: > > > > On Monday, November 18, 2019 3:42:20 AM MST Mikolaj Izdebski wrote: > > > 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. > > > > Why in the world do you want to move even more to modules? > > Not move more to modules, but to reduce duplication by putting module > into buildroot and retiring corresponding ursine packages. > > > > 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. > > > > I must disagree. That it "works" in RHEL doesn't mean that it should be done > > in Fedora. The current situation in Fedora, where maven and ant have been > > "moved" to modules has screwed over the Eclipse packagers, for example, and > > more are to follow. > > That was not what I said. I made a point that it is not necessary to > indefinitely maintain ursine Maven because modular Maven can be used > to build ursine packages. I used RHEL as a proof that this is doable. We didn't claim that this *cannot* work in fedora, just that it *doesn't*. Because that's exactly what you yourself stated three weeks ago: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TSPB4YZOAQFOUBSECMMMJAXW6PFZQBPQ/ Fabio > -- > Mikolaj Izdebski > ___ > 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
Re: [fedora-java] What's the State of the Java SIG?
Fabio Valentini wrote: > Or is it time for a "tabula rasa" and restart the SIG? IMHO, yes. Kick out the 1 or 2 Modularity fundamentalists that form the current remains of the Java SIG and create a new Java SIG from scratch that actually cares about packaging Java properly in and for (non-modular) Fedora. The current modules are missing a lot of Java software that users care about (e.g. NetBeans, etc. – some, such as NetBeans, had already been retired before Modularity became a thing, because the Java SIG had already been disintegrating back then, some was lost in the move to modules), have put Eclipse into a broken state, have simply replaced the adapted JPackage version of Maven (with RPM integration) with a vanilla upstream Maven that does not have this feature (I cannot see what advantage that change brings), etc. And I do not see at all what advantage end users would get from those packages being in modules. Both Maven and Ant are tools where you normally always want the latest version, there is not much value in being able to pick a specific version stream. Kevin Kofler ___ 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
Re: What's the State of the Java SIG?
On Mon, Nov 18, 2019 at 12:17 PM John M. Harris Jr wrote: > > On Monday, November 18, 2019 3:42:20 AM MST Mikolaj Izdebski wrote: > > 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. > > Why in the world do you want to move even more to modules? Not move more to modules, but to reduce duplication by putting module into buildroot and retiring corresponding ursine packages. > > 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. > > I must disagree. That it "works" in RHEL doesn't mean that it should be done > in Fedora. The current situation in Fedora, where maven and ant have been > "moved" to modules has screwed over the Eclipse packagers, for example, and > more are to follow. That was not what I said. I made a point that it is not necessary to indefinitely maintain ursine Maven because modular Maven can be used to build ursine packages. I used RHEL as a proof that this is doable. -- Mikolaj Izdebski ___ 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
Re: What's the State of the Java SIG?
On Monday, November 18, 2019 3:42:20 AM MST Mikolaj Izdebski wrote: > 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. Why in the world do you want to move even more to modules? > 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 a defect of Modularity, as has been covered extensively on this mailing list in the past few days. > 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. I must disagree. That it "works" in RHEL doesn't mean that it should be done in Fedora. The current situation in Fedora, where maven and ant have been "moved" to modules has screwed over the Eclipse packagers, for example, and more are to follow. -- John M. Harris, Jr. Splentity ___ 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
Re: What's the State of the Java SIG?
Hi, On Mon, Nov 18, 2019 at 10:30 AM Fabio Valentini 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
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: 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 ___ 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
