Fedora 💔 Java: The Death of Two SIGs

[Fabio Valentini]

Good evening everybody,

Not sure why it's me who's writing this message, but somebody needs to do it.

Community maintenance of Java packages in Fedora is, for all intents
and purposes, dead. Mikolaj keeps a bare minimum of packages working
for the maven toolchain, but that's it. Fedora 35 will ship without
packages for the Eclipse IDE, and none of the Java applications I know
of are still in working order. While I had hoped that setting up a
"new" SIG and gathering members to shore up community maintenance of
the "extended core" Java stack, this effort fizzled out after mere
weeks.

"He's dead, Jim."

Now to the reason why I feel the need to beat a dead horse: I wonder
if the @java-maint-sig group should actually continue to exist (or
rather, be maintainer or bugzilla assignee for packages, because I
don't even know if FAS groups can be deleted). It seems that none of
the current members (I am no longer one of them) are active. Bugs,
including security issues with assigned CVE numbers, are collecting
dust. Packages get orphaned and retired one by one because they fail
to build or install.

At this point, I'm still the only person with the password for the
SIG's bugzilla account and the only administrator of the private
mailing list - just because I wouldn't even know who to hand those
things over to (fedora-infra?). There's nobody left, nobody is reading
the mailing lists. Only tumbleweeds are here.

Should the @java-maint-sig group be removed from any packages it is
still associated with? Should it be dissolved, and members be removed?
Should the remaining ruins that used to be packages be orphaned?
Retired? Buried? Forgotten?

I don't know.

Fabio

[Christopher]

I think part of the problem is that Java is too big. There are too
many libraries to fit into a single community. I think there's
probably willing volunteers to maintain some libraries and application
packages, but these are not necessarily the same people willing to do
all the work of maintaining OpenJDK packages or the whole Eclipse
stack.

When modularity took out the whole Java stack, it did a lot of lasting
damage that is going to be hard to recover from. In order for the vast
majority of Java packagers to return, there needs to be a reliable
base. I'm thinking OpenJDK (which I think is reliably maintained right
now) and XMvn. Java packagers who might be willing to support a lot of
the rest of the libraries (guava, commons-*, etc.) need to be able to
rely on those core components being stable first. Then, when that
trust is restored, I'm sure end-user applications will trickle in.

Right now, I'm not sure there's adequate expertise to reestablish
trust in the Java core tools for Java packagers to start coming back.

One problem is that instead of thinking about the state of Java
packaging as 3 separate layers, core-libraries-applications, and
having only a single massive Java maintenance SIG, probably leaves a
lot of end-user/application packagers like myself just lurking.
There's little I can do to help with the vast majority of Java
packages. And, there's little interest for me doing so, because I'm
still waiting to see if the Java core and some of the libraries can
make a comeback and be stable enough to rely on to start packaging my
applications again. Right now, the whole stack seems unreliable, and
it's a bit overwhelming for the casual volunteer, like me. Maybe this
applies to other packagers as well?

On Sun, Sep 26, 2021 at 3:20 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>
> Good evening everybody,
>
> Not sure why it's me who's writing this message, but somebody needs to do
it.
>
> Community maintenance of Java packages in Fedora is, for all intents
> and purposes, dead. Mikolaj keeps a bare minimum of packages working
> for the maven toolchain, but that's it. Fedora 35 will ship without
> packages for the Eclipse IDE, and none of the Java applications I know
> of are still in working order. While I had hoped that setting up a
> "new" SIG and gathering members to shore up community maintenance of
> the "extended core" Java stack, this effort fizzled out after mere
> weeks.
>
> "He's dead, Jim."
>
> Now to the reason why I feel the need to beat a dead horse: I wonder
> if the @java-maint-sig group should actually continue to exist (or
> rather, be maintainer or bugzilla assignee for packages, because I
> don't even know if FAS groups can be deleted). It seems that none of
> the current members (I am no longer one of them) are active. Bugs,
> including security issues with assigned CVE numbers, are collecting
> dust. Packages get orphaned and retired one by one because they fail
> to build or install.
>
> At this point, I'm still the only person with the password for the
> SIG's bugzilla account and the only administrator of the private
> mailing list - just because I wouldn't even know who to hand those
> things over to (fedora-infra?). There's nobody left, nobody is reading
> the mailing lists. Only tumbleweeds are here.
>
> Should the @java-maint-sig group be removed from any packages it is
> still associated with? Should it be dissolved, and members be removed?
> Should the remaining ruins that used to be packages be orphaned?
> Retired? Buried? Forgotten?
>
> I don't know.
>
> Fabio
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Ankur Sinha]

On Sun, Sep 26, 2021 21:20:07 +0200, Fabio Valentini wrote:
>  Good evening everybody,
>  
>  Not sure why it's me who's writing this message, but somebody needs to do it.
>  
>  Community maintenance of Java packages in Fedora is, for all intents
>  and purposes, dead. Mikolaj keeps a bare minimum of packages working
>  for the maven toolchain, but that's it. Fedora 35 will ship without
>  packages for the Eclipse IDE, and none of the Java applications I know
>  of are still in working order. While I had hoped that setting up a
>  "new" SIG and gathering members to shore up community maintenance of
>  the "extended core" Java stack, this effort fizzled out after mere
>  weeks.
>  
>  "He's dead, Jim."
>  
>  Now to the reason why I feel the need to beat a dead horse: I wonder
>  if the @java-maint-sig group should actually continue to exist (or
>  rather, be maintainer or bugzilla assignee for packages, because I
>  don't even know if FAS groups can be deleted). It seems that none of
>  the current members (I am no longer one of them) are active. Bugs,
>  including security issues with assigned CVE numbers, are collecting
>  dust. Packages get orphaned and retired one by one because they fail
>  to build or install.
>  
>  At this point, I'm still the only person with the password for the
>  SIG's bugzilla account and the only administrator of the private
>  mailing list - just because I wouldn't even know who to hand those
>  things over to (fedora-infra?). There's nobody left, nobody is reading
>  the mailing lists. Only tumbleweeds are here.
>  
>  Should the @java-maint-sig group be removed from any packages it is
>  still associated with? Should it be dissolved, and members be removed?
>  Should the remaining ruins that used to be packages be orphaned?
>  Retired? Buried? Forgotten?
>  
>  I don't know. 

Unfortunately, I think removing the java-maint-sig is the only thing to
do.

I was hoping to help out since some of our neuro-sig packages are Java,
but keeping the dependency chain in place to be able to make these leaf
packages available is just far too much work. The Gradle issue etc. do
not help either. I don't think we managed to find a practical solution
for that one. At the neuro-sig we've been orphaning our Java packages
and letting them be retired. We'll just point to upstream builds in our
documentation and let users fetch and use those.

I think, as folks have discussed before, the Java ecosystem is not quite
packaging friendly enough for us, and for us to spend resources on
trying to tame it isn't the best use of our rather limited resources in
my book. (I mean I won't forbid any one from doing it, but I'd rather
focus on the non-Java packages in our 200 item packaging queue instead
of using up all that time on the few Java ones)

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London

[Peter Boy]

>  Am 27.09.2021 um 10:47 schrieb Ankur Sinha
> <sanjay.ankur(a)gmail.com&gt;:
>  
>  On Sun, Sep 26, 2021 21:20:07 +0200, Fabio Valentini wrote:
> > Should the @java-maint-sig group be removed from any packages it is
> > still associated with? Should it be dissolved, and members be removed?
> > Should the remaining ruins that used to be packages be orphaned?
> > Retired? Buried? Forgotten?
> > 
> > I don't know.
>  
>  
>  Unfortunately, I think removing the java-maint-sig is the only thing to
>  do. 
What do you want to gain from it? What is the goal to be? 


Peter

[Pierre-Yves Chibon]

On Mon, Sep 27, 2021 at 10:57:12AM +0200, Peter Boy wrote:
>  
>  
>  > Am 27.09.2021 um 10:47 schrieb Ankur Sinha <sanjay.ankur(a)gmail.com&gt;:
>  > 
>  > On Sun, Sep 26, 2021 21:20:07 +0200, Fabio Valentini wrote:
>  >> Should the @java-maint-sig group be removed from any packages it is
>  >> still associated with? Should it be dissolved, and members be removed?
>  >> Should the remaining ruins that used to be packages be orphaned?
>  >> Retired? Buried? Forgotten?
>  >> 
>  >> I don't know.
>  > 
>  > 
>  > Unfortunately, I think removing the java-maint-sig is the only thing to
>  > do. 
As heart-breaking as it is, I agree with Ankur. Letting things as they are is
not correct.
The group itself will not disappear, so if some people wanted to revive it some
time in the future, they could still do, but it would not give the impression
that someone/some team is looking after packages while they are not.

>  What do you want to gain from it? What is the goal to be?  
I believe the original email from Fabio answers both of these questions.


Pierre

[Peter Boy]

>  Am 27.09.2021 um 11:13 schrieb Pierre-Yves Chibon
> <pingou(a)pingoured.fr&gt;:
>  
>  On Mon, Sep 27, 2021 at 10:57:12AM +0200, Peter Boy wrote:
> > 
>  
> > What do you want to gain from it? What is the goal to be? 
>  
>  I believe the original email from Fabio answers both of these questions. 
I don’t find a plan or a goal. Please, provide me with a hint.


Peter

[Fabio Valentini]

On Mon, Sep 27, 2021 at 12:19 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  > Am 27.09.2021 um 11:13 schrieb Pierre-Yves Chibon <pingou(a)pingoured.fr&gt;:
>  >
>  > On Mon, Sep 27, 2021 at 10:57:12AM +0200, Peter Boy wrote:
>  >>
>  >
>  >> What do you want to gain from it? What is the goal to be?
>  >
>  > I believe the original email from Fabio answers both of these questions.
>
>  I don’t find a plan or a goal. Please, provide me with a hint. 
All I wanted to say is that the current state is disingenuous at best,
and misleading at first.

By having @java-maint-sig as one of the admins of a package (and for
most of them, also the default bugzilla assignee), while that group
doesn't really function any longer, a false expectation of "there's a
whole group of people maintaining this package", while the reality is
closer to "zero or maybe one person might be looking at this package
once a year".

I'd rather have the group start from zero now, and start *adding*
packages again that are actually really needed, wanted, and
maintained.

This should also be a less daunting prospect for potential packagers
who are now just lurking on the sidelines, because they can't commit
to helping maintain 100+ packages (I actually know that there's a few
of those - thank you for contacting me off-list. you know who you are
:) )

Fabio

[Richard W.M. Jones]

A question about this which is semi-related to your email.

For some C library packages we have Java bindings, eg:
https://github.com/libguestfs/libguestfs/tree/master/java

These have been disabled in Fedora for ~2 years, but when they were
around they had these BuildRequires:

  BuildRequires: java-1.8.0-openjdk
  BuildRequires: java-1.8.0-openjdk-devel
  BuildRequires: jpackage-utils

I believe the only requirements are javac, javah, javadoc (optional)
and a JVM to run the tests on.

Is it possible to keep this going, or would that require a lot of
work?  I notice that javah no longer seems to exist.

(Note I know almost nothing about how the modern JDK works)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Fabio Valentini]

On Mon, Sep 27, 2021 at 1:07 PM Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  A question about this which is semi-related to your email.
>
>  For some C library packages we have Java bindings, eg:
>  https://github.com/libguestfs/libguestfs/tree/master/java
>
>  These have been disabled in Fedora for ~2 years, but when they were
>  around they had these BuildRequires:
>
>    BuildRequires: java-1.8.0-openjdk
>    BuildRequires: java-1.8.0-openjdk-devel
>    BuildRequires: jpackage-utils
>
>  I believe the only requirements are javac, javah, javadoc (optional)
>  and a JVM to run the tests on.
>
>  Is it possible to keep this going, or would that require a lot of
>  work?  I notice that javah no longer seems to exist.
>
>  (Note I know almost nothing about how the modern JDK works) 
I think you'd probably want to do

1) switch to java-11-openjdk (it's the default on all currently
supported Fedora branches)
2) replace jpackage-utils with javapackages-tools (depending on what
exactly you need from that package)
3) replace javah usage (removed with Java 11) with "java -h", or
similar (for an example how I handled this for another package, look
at https://src.fedoraproject.org/rpms/jblas/pull-request/2 )

And since those bindings do not look like they require any third-party
Java libraries, you should be fine.

Fabio

[Mat Booth]

On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  A question about this which is semi-related to your email.
>
>  For some C library packages we have Java bindings, eg:
>  https://github.com/libguestfs/libguestfs/tree/master/java
>
>  These have been disabled in Fedora for ~2 years, but when they were
>  around they had these BuildRequires:
>
>    BuildRequires: java-1.8.0-openjdk
>    BuildRequires: java-1.8.0-openjdk-devel
>    BuildRequires: jpackage-utils
>
>  I believe the only requirements are javac, javah, javadoc (optional)
>  and a JVM to run the tests on.
>
>  Is it possible to keep this going, or would that require a lot of
>  work?  I notice that javah no longer seems to exist.
>
>  (Note I know almost nothing about how the modern JDK works)
>
>  Rich. 
Hi, the functionality provided by javah has been folded into javac in
recent JDKs.

These days you can make one call to "javac -h" instead of having to
call both "javac" and "javah"

I ported quite a few packages this way when Fedora made the switch to
Java 11 by default. If you like I can probably take a look libguestfs
and send you a PR?


>  --
>  Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>  Read my programming and virtualization blog: http://rwmj.wordpress.com
>  virt-p2v converts physical machines to virtual machines.  Boot with a
>  live CD or over the network (PXE) and turn machines into KVM guests.
>  http://libguestfs.org/virt-v2v
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


-- 
Mat Booth
http://fedoraproject.org/get-fedora

[Artur Frenszek-Iwicki]

>  I believe the only requirements are javac, javah, javadoc (optional)
>  and a JVM to run the tests on. Is it possible to keep this going,
>  or would that require a lot of work? 
+1 on this. Having just the minimum, core
packages
available in the repo would be good, especially since:
a) It would mean users can still run third-party Java apps.
b) I believe that, similar to Python, many end-users use maven
   (or whatever else) for installing dependencies, instead of the distro's repo,
   so the removal of other packages didn't affect them as much.

>   I notice that javah no longer seems to exist. 
javah is now
part of javac, invoked using the -h option.
If my research is right, the last edition with a separate javah was Java SE 9. 

A.FI.

[Richard W.M. Jones]

On Mon, Sep 27, 2021 at 12:15:32PM +0100, Mat Booth wrote:
>  On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
>  >
>  > A question about this which is semi-related to your email.
>  >
>  > For some C library packages we have Java bindings, eg:
>  > https://github.com/libguestfs/libguestfs/tree/master/java
>  >
>  > These have been disabled in Fedora for ~2 years, but when they were
>  > around they had these BuildRequires:
>  >
>  >   BuildRequires: java-1.8.0-openjdk
>  >   BuildRequires: java-1.8.0-openjdk-devel
>  >   BuildRequires: jpackage-utils
>  >
>  > I believe the only requirements are javac, javah, javadoc (optional)
>  > and a JVM to run the tests on.
>  >
>  > Is it possible to keep this going, or would that require a lot of
>  > work?  I notice that javah no longer seems to exist.
>  >
>  > (Note I know almost nothing about how the modern JDK works)
>  >
>  > Rich.
>  
>  Hi, the functionality provided by javah has been folded into javac in
>  recent JDKs.
>  
>  These days you can make one call to "javac -h" instead of having to
>  call both "javac" and "javah"
>  
>  I ported quite a few packages this way when Fedora made the switch to
>  Java 11 by default. If you like I can probably take a look libguestfs
>  and send you a PR? 
Sure thing, thanks.

However before you start you might also want to know that there are
apparently some serious GC-related problems with how those bindings
work:

https://bugzilla.redhat.com/show_bug.cgi?id=1536762

so it might be more of a saga than just changing a few commands.

Rich.

>  
>  >
>  > --
>  > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>  > Read my programming and virtualization blog: http://rwmj.wordpress.com
>  > virt-p2v converts physical machines to virtual machines.  Boot with a
>  > live CD or over the network (PXE) and turn machines into KVM guests.
>  > http://libguestfs.org/virt-v2v
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>  
>  
>  
>  -- 
>  Mat Booth
>  http://fedoraproject.org/get-fedora
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Peter Boy]

>  Am 27.09.2021 um 12:30 schrieb Fabio Valentini
> <decathorpe(a)gmail.com&gt;:
>  
>  On Mon, Sep 27, 2021 at 12:19 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
> > 
> > 
> > 
> >> Am 27.09.2021 um 11:13 schrieb Pierre-Yves Chibon <pingou(a)pingoured.fr&gt;:
> >> 
> >> On Mon, Sep 27, 2021 at 10:57:12AM +0200, Peter Boy wrote:
> >>> 
> >> 
> >>> What do you want to gain from it? What is the goal to be?
> >> 
> >> I believe the original email from Fabio answers both of these questions.
> > 
> > I don’t find a plan or a goal. Please, provide me with a hint.
>  
>  All I wanted to say is that the current state is disingenuous at best,
>  and misleading at first. 
Unfortunately yes, indeed.

>  By having @java-maint-sig as one of the admins of a package (and for
>  most of them, also the default bugzilla assignee), while that group
>  doesn't really function any longer, a false expectation of "there's a
>  whole group of people maintaining this package", while the reality is
>  closer to "zero or maybe one person might be looking at this package
>  once a year". 
I think you characterize the situation very pessimistically. Obviously the constructions
work to a certain extent. For example, we have 3 different versions of the JDK available
in parallel, which also receive regular updates. We have important applications as tomcat.
So we have something to build on. 

And this kind of situation is in no way special or exclusive to Java sig. We have or had a
similar situation with a number of other Fedora sigs, e.g. Fedora Server Edition which
underwent a "reboot" late last year. And the current situation of Fedora docs is
not much better than that of Java. Sociologically, such alternating phases are typical for
volunteer projects. They need a "refresh" or a "revitalization“ and new
members with new impulses every now and then. All this is normal. 

So there is no reason to give up and expect or bring about the demise of the Fedora Java
stack. The challenge is to organize such a "reboot". It requires a number of
prerequisites, and that is not easy.


>  I'd rather have the group start from zero now, and start
> *adding*
>  packages again that are actually really needed, wanted, and
>  maintained.
>  
>  This should also be a less daunting prospect for potential packagers
>  who are now just lurking on the sidelines, ... (I actually know that there's a few
>  of those 
Yes. One of the challenges is to organize a meeting where all these potential packagers
meet - in one place and at the same time and that along with some of the current
packagers. And that's something we're already struggling with at the moment.


>  - thank you for contacting me off-list. you know who you are
>  :) ) 
I have to thank you. I am still following my ‚project' and would like to contact you
with a few questions later. 


Peter

[Stephen John Smoogen]

On Sun, 26 Sept 2021 at 16:35, Christopher <ctubbsii(a)fedoraproject.org&gt; wrote:
>  I think part of the problem is that Java is too big. There are too
>  many libraries to fit into a single community. I think there's
>  probably willing volunteers to maintain some libraries and application
>  packages, but these are not necessarily the same people willing to do
>  all the work of maintaining OpenJDK packages or the whole Eclipse
>  stack.
>
>  When modularity took out the whole Java stack, it did a lot of lasting
>  damage that is going to be hard to recover from. In order for the vast
>  majority of Java packagers to return, there needs to be a reliable 
I am going to disagree here greatly. The Java stack was in exactly the
same mode it is in now before then. There was 1 person 'maintaining'
hundreds of packages for a long time. There were other 'maintainers'
listed but they were not around or ignoring things from burnout.
People had brought this up year after year and all that would happen
is everyone would say "we can't ever let things down" and pitch in to
fix things (or make the 1 person who was over-committed feel guilty
for asking to lighten the load).

Then when the defacto Java maintainer moved stuff into modules to make
his life easier.. there was a 'well we can find new people to do this
instead' and various initiatives were tried to make it. Those have all
failed because

1. Java and Fedora have a long back history of ugly fighting which
makes it hard for 'older' Java people want to work with Fedora. Like
old feuds, there are landmines which flare up fights no one remembers
exactly but they come up.
2. That ugly fighting is sort of written into the packaging guidelines
because it is a long 'compromise' between how Java wants packages done
and how Fedora wants it done. This makes it hard for 'new' Java people
because they are whiplashed between different world views. And vice
versa, if you aren't a Java person and try to make it fix a Java
package it can be a brain hurt as you try to do things like in other
packages and it all fails.
3. Most Fedora consumers just want the tools to work and pile onto the
smaller pool of developers about 'why is X always broken?' This has
caused continual burnout when new teams came up. It was also what was
burning out the previous people.

Basically Java has been 'broken' for as long as I have been part of
Fedora. The 'good' times are usually just after the last time Java was
going to be pulled out in the next release, and finally everyone drops
the things they really care for and works on it. Then everyone goes
back to their real pleasures and it falls apart again. Later, rinse,
repeat.


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.

[Mario Torre]

On Sun, Sep 26, 2021 at 10:36 PM Christopher <ctubbsii(a)fedoraproject.org&gt; wrote:
>  I think part of the problem is that Java is too big. There are too
>  many libraries to fit into a single community. I think there's
>  probably willing volunteers to maintain some libraries and application
>  packages, but these are not necessarily the same people willing to do
>  all the work of maintaining OpenJDK packages or the whole Eclipse
>  stack.
>
>  When modularity took out the whole Java stack, it did a lot of lasting
>  damage that is going to be hard to recover from. In order for the vast
>  majority of Java packagers to return, there needs to be a reliable
>  base. I'm thinking OpenJDK (which I think is reliably maintained right
>  now) and XMvn. Java packagers who might be willing to support a lot of
>  the rest of the libraries (guava, commons-*, etc.) need to be able to
>  rely on those core components being stable first. Then, when that
>  trust is restored, I'm sure end-user applications will trickle in.
>
>  Right now, I'm not sure there's adequate expertise to reestablish
>  trust in the Java core tools for Java packagers to start coming back. 
Just my 0.2 euro cents here.

The OpenJDK packages are well maintained, in fact, the packaging work
and their updates are done by the very same team that participate to
the upstream OpenJDK development.

Regarding Eclipse, it's really a lot of work and I understand this, so
effort moved toward a flatpack version of it. I'm not sure this saves
anything, and in my experience it actually introduces some problems,
but the Eclipse maintainers have a different opinion and I think we
should trust their judgment. However the majority of people just
usually download Eclipse (or IntelliJ for what matters) from the
upstream website anyway, further suggesting that maintaining Eclipse
is not really a rewarding nor useful task.

For maven, I don't think anyone really relies on installed packages
other than a few  (mostly because of cross/transitive dependency
reasons), so I'm not sure if there is any real benefit in having
packagers spending resources and time to maintain packages that
inevitably go out of sync.

I'm not sure what's the best solution, but I guess the number one
reason to have packages within the Fedora distribution is for a matter
of trust, if this is the case I would argue that a curated list of
maven packages served via a Fedora managed repository would be a
better investment.

For that to work we need a solid distribution of OpenJDK (which we
have) and a solid distribution of maven (which we also have).

Cheers,
Mario
-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

[Stephen John Smoogen]

On Mon, 27 Sept 2021 at 08:45, Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  > Am 27.09.2021 um 12:30 schrieb Fabio Valentini <decathorpe(a)gmail.com&gt;:
>  >
>  > On Mon, Sep 27, 2021 at 12:19 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  >>
>  >>
>  >>
>  >>> Am 27.09.2021 um 11:13 schrieb Pierre-Yves Chibon
> <pingou(a)pingoured.fr&gt;:
>  >>>
>  >>> On Mon, Sep 27, 2021 at 10:57:12AM +0200, Peter Boy wrote:
>  >>>>
>  >>>
>  >>>> What do you want to gain from it? What is the goal to be?
>  >>>
>  >>> I believe the original email from Fabio answers both of these questions.
>  >>
>  >> I don’t find a plan or a goal. Please, provide me with a hint.
>  >
>  > All I wanted to say is that the current state is disingenuous at best,
>  > and misleading at first.
>
>  Unfortunately yes, indeed.
>
>  > By having @java-maint-sig as one of the admins of a package (and for
>  > most of them, also the default bugzilla assignee), while that group
>  > doesn't really function any longer, a false expectation of "there's a
>  > whole group of people maintaining this package", while the reality is
>  > closer to "zero or maybe one person might be looking at this package
>  > once a year".
>
>  I think you characterize the situation very pessimistically. Obviously the constructions
> work to a certain extent. For example, we have 3 different versions of the JDK available
> in parallel, which also receive regular updates. We have important applications as tomcat.
> So we have something to build on.
>  
Personally I think I found the characterization as being optimistic to
almost realistic.

There have been 3 to 5 reboots since 2008 each time with smaller
groups of people. The issue is that Java is not a 'hot-new-thing'
language that gets all the programmers running to the field. It is now
seen as the same as Pascal/COBOL was in the 1990's.. that thing you
learn in Freshman CS and then avoided unless you want to be an
accounting-programmer (aka COBOL).

There is nothing wrong with 'accounting-programmer' languages, and
they are rarely just used for accounting, but it is a simple label
people use on it. Java and languages like it are utility languages
where after spending a week getting some report or other application
to work, volunteering time to fix it for someone else is the last
thing you want to do. [As several Java programmers have put it, you
don't see plumbers volunteering to fix their neighbors pipes on
weekends.]

In the end, we have never been able to keep a pool of people
interested in making Java work. We aren't the only ones as this
problem occurs in Debian also (and it occurs in other languages like
Ruby, JS, Python also). The people who want to volunteer time on the
language are more likely to work in an area where others interested in
the language are already there. Dealing with the vaguries of 40
different slightly different disk layouts, file permissions, and other
tools  from every distribution are grit in the shoe when you already
have a 'working layout' and have people who speak your language and
problems elsewhere.





-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.

[PGNet Dev]

Many valid/interesting points being made.  Most of them sound, reasonably, like
developer-/maintainer-centric issues.

Question: Is a primary goal of Fedora distro (JAVA sig, etc) to 'service' its
(java app) users?

If so, what's the current understanding of a user-driven ProductRequirements
spec'n of JAVA apps 'round here?
Who's included in "users"? Developers? End-users? etc.
Perhaps I've missed it ...

I know as a representative of my end-users I've got plenty of opinions about our JAVA
env.  Also as a representative of my org's JAVA devs.
But as a developer/maintainer OF java/apps @ Fedora, not much at all; the "solid
OpenJDK & Maven" approach is good enuf here.  Mostly.

And, if that^ is not a primary goal, then back to the discussion at hand.

[Robert Marcano]

On 9/26/21 3:20 PM, Fabio Valentini wrote:
>  Good evening everybody,
>  
>  Not sure why it's me who's writing this message, but somebody needs to do it.
>  
>  Community maintenance of Java packages in Fedora is, for all intents
>  and purposes, dead. Mikolaj keeps a bare minimum of packages working
>  for the maven toolchain, but that's it. Fedora 35 will ship without
>  packages for the Eclipse IDE, and none of the Java applications I know
>  of are still in working order. While I had hoped that setting up a
>  "new" SIG and gathering members to shore up community maintenance of
>  the "extended core" Java stack, this effort fizzled out after mere
>  weeks.
>  
>  "He's dead, Jim." 
I will add my view as someone that use to package a tiny few Java 
packages for Fedora (maily Eclipse plugins). My view may be outdated so 
everyone is free to correct me as always.

I think saying the Java ecosystem isn't friendly to traditional 
packaging could be said for any other modern language Fedora has 
accepted without a fuss. Go and Rust applications has made some of the 
traditional rules of dynamic loaded code having a preference being 
challenged by these "newcomers" that don't support it.

Meanwhile Java packages still are difficult because of the need of 
everything to be split on multiple packages and every jar found being 
replaced by symlinks to files in /usr/java/*. In Eclipse plugins this 
remain more difficult, because plugins al already jars with embeeded 
jars where a custom classloader is able to load things withour having 
everything extracted on the filesystem.

I think the only way the Java ecosystem to survive in Fedora outside of 
OpenJDK and some core components is to allow bundling (Even JavaScript 
bundling is already allowed), but how do to it without compromising 
security?

1. I propose that every package should use a modern Java build system 
that resolve dependencies (Maven, Gradle, Ant+Ivy, etc), If the package 
doesn't have that, a patch should be provided and contributed upstream.

2. We have automation to extract the dependencies required by the main 
package and allow the Fedora build system to automate the creation of 
packages for these dependencies from source and generate for example 
subpackages *-mave or something like that, that provides these 
dependencies as maven repositories locally to be use by other packages.

3. Packages embeede thes libraries like they upstream do, without having 
to patch hundred of build script to use links to /usr/java.

4. Automate that dependencies updates should trigger dependent packages 
rebuild

This as dependent Jar files as "source code" like Rust and Go are 
currently packages.

Without a process simplification for the packages like this one, or 
something better. The Java applications ecosystem being packaged on 
Fedora will not be resurrected.

>  
>  Now to the reason why I feel the need to beat a dead horse: I wonder
>  if the @java-maint-sig group should actually continue to exist (or
>  rather, be maintainer or bugzilla assignee for packages, because I
>  don't even know if FAS groups can be deleted). It seems that none of
>  the current members (I am no longer one of them) are active. Bugs,
>  including security issues with assigned CVE numbers, are collecting
>  dust. Packages get orphaned and retired one by one because they fail
>  to build or install.
>  
>  At this point, I'm still the only person with the password for the
>  SIG's bugzilla account and the only administrator of the private
>  mailing list - just because I wouldn't even know who to hand those
>  things over to (fedora-infra?). There's nobody left, nobody is reading
>  the mailing lists. Only tumbleweeds are here.
>  
>  Should the @java-maint-sig group be removed from any packages it is
>  still associated with? Should it be dissolved, and members be removed?
>  Should the remaining ruins that used to be packages be orphaned?
>  Retired? Buried? Forgotten?
>  
>  I don't know.
>  
>  Fabio

[Solomon Peachy]

On Mon, Sep 27, 2021 at 10:24:23AM -0400, Robert Marcano via devel wrote:
>  1. I propose that every package should use a modern Java build system
> that
>  resolve dependencies (Maven, Gradle, Ant+Ivy, etc), If the package doesn't
>  have that, a patch should be provided and contributed upstream. 
Any proposal that requires *more* work from Fedora package maintainers 
is a complete non-starter, given the harsh reality that there already 
isn't enough packager person-hours available to keep the Fedora Java 
ship afloat.

>  Without a process simplification for the packages like this one, or
>  something better. The Java applications ecosystem being packaged on Fedora
>  will not be resurrected. 
Yep; automate (to compensate for upstream culture) or die.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (libra.chat)

[Martin Jackson]

For what it's worth...

I use the OpenJDK on Fedora and I'm very happy with it.  I do not use or 
need eclipse, or as fast as I can tell, any of the other tooling (e.g. 
packaged gradle and other things).  My main uses are playing games that 
depend on Java and are packaged and built outside the Fedora toolchain.  
(One is minecraft, the other is called Megamek, a simulator for the 
tabletop war game Classic BattleTech.  minecraft...doesn't need to be 
built and megamek builds with gradle, which it knows how to download.)  
It hurts a bit to see posts like what were at the top of this thread - 
clearly Fabio and others have invested many hours into making a great 
experience for people, and I hate to see people feel that effort is 
wasted or that they're burning out.

I would like to thank those who have contributed to the Fedora java 
stack.  Maybe my case is unusual?  It meets my needs and I expect it 
will continue to.

Thanks,

Marty

On 9/27/21 09:03, PGNet Dev wrote:
> Many valid/interesting points being made.  Most of them sound, 
> reasonably, like developer-/maintainer-centric issues.
>
> Question: Is a primary goal of Fedora distro (JAVA sig, etc) to 
> 'service' its (java app) users?
>
> If so, what's the current understanding of a user-driven 
> ProductRequirements spec'n of JAVA apps 'round here?
> Who's included in "users"? Developers? End-users? etc.
> Perhaps I've missed it ...
>
> I know as a representative of my end-users I've got plenty of opinions 
> about our JAVA env.  Also as a representative of my org's JAVA devs.
> But as a developer/maintainer OF java/apps @ Fedora, not much at all; 
> the "solid OpenJDK & Maven" approach is good enuf here. Mostly.
>
> And, if that^ is not a primary goal, then back to the discussion at hand.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

[Fabio Valentini]

On Mon, Sep 27, 2021 at 4:56 PM Martin Jackson <mhjacks(a)swbell.net&gt; wrote:
>  For what it's worth...
>
>  I use the OpenJDK on Fedora and I'm very happy with it.  I do not use or
>  need eclipse, or as fast as I can tell, any of the other tooling (e.g.
>  packaged gradle and other things).  My main uses are playing games that
>  depend on Java and are packaged and built outside the Fedora toolchain.
>  (One is minecraft, the other is called Megamek, a simulator for the
>  tabletop war game Classic BattleTech.  minecraft...doesn't need to be
>  built and megamek builds with gradle, which it knows how to download.)
>  It hurts a bit to see posts like what were at the top of this thread -
>  clearly Fabio and others have invested many hours into making a great
>  experience for people, and I hate to see people feel that effort is
>  wasted or that they're burning out.
>
>  I would like to thank those who have contributed to the Fedora java
>  stack.  Maybe my case is unusual?  It meets my needs and I expect it
>  will continue to. 
Not at all, this is not unusual. If you need nothing but the JDK, then
you'll be fine.

I'm not sure about this (the internals of Red Hat are quite opaque),
but as far as I know, are two different, non-overlapping teams
involved here:
One that maintains OpenJDK packages (which are fine), and one that
maintains Java packages (which have been dying in Fedora for years).
(I'm sorry If I am misrepresenting the situation inside Red Hat, but
this the extent of my knowledge.)

So if you only rely in things like OpenJDK (like for running
Minecraft, as I do, too), then you'll be fine.
If you need ant or maven, you should be fine too, since those two (and
their dependencies) will continue to be maintained.
But everything else ... *tumbleweeds*

Fabio

[PGNet Dev]

>  So if you only rely in things like OpenJDK (like for running
>  Minecraft, as I do, too), then you'll be fine.
>  If you need ant or maven, you should be fine too, since those two (and
>  their dependencies) will continue to be maintained.
>  But everything else ... *tumbleweeds* 
Just one user's snapshot; On a not-atypical dev-box here, installed java apps are

	PHPStorm (upstream snap)
	IntelliJ*  (upstream snap)
	Eclipse (upstream tarball)
	DBeaver-CE (upstream rpm)
	android-studio (upstream)

In dev-user cases, any additional 'needed' apps are typically getting installed
from upstreams -- as tarballs, snaps, flatpaks, or rpms.  Seldom, if ever, from Fedora
pkgs.


and pkgs
	rpm -qa | egrep -i "java|jdk|mvn|maven" | sort
		copy-jdk-configs-4.0-1.fc34.noarch
		java-11-openjdk-11.0.12.0.7-4.fc34.x86_64
		java-11-openjdk-devel-11.0.12.0.7-4.fc34.x86_64
		java-11-openjdk-headless-11.0.12.0.7-4.fc34.x86_64
		java-latest-openjdk-17.0.0.0.35-1.rolling.fc34.x86_64
		java-latest-openjdk-devel-17.0.0.0.35-1.rolling.fc34.x86_64
		java-latest-openjdk-headless-17.0.0.0.35-1.rolling.fc34.x86_64
		javapackages-filesystem-5.3.0-15.fc34.noarch
		javapackages-tools-5.3.0-15.fc34.noarch
		maven-3.6.3-8.fc34.noarch
		maven-archiver-3.5.1-1.fc34.noarch
		maven-artifact-2.2.1-67.fc34.noarch
		maven-artifact-transfer-0.11.0-5.fc34.noarch
		maven-common-artifact-filters-3.1.1-1.fc34.noarch
		maven-compiler-plugin-3.8.1-8.fc34.noarch
		maven-dependency-tree-3.0.1-6.fc34.noarch
		maven-doxia-core-1.9.1-4.fc34.noarch
		maven-doxia-logging-api-1.9.1-4.fc34.noarch
		maven-doxia-module-apt-1.9.1-4.fc34.noarch
		maven-doxia-module-fml-1.9.1-4.fc34.noarch
		maven-doxia-module-xdoc-1.9.1-4.fc34.noarch
		maven-doxia-module-xhtml-1.9.1-4.fc34.noarch
		maven-doxia-module-xhtml5-1.9.1-4.fc34.noarch
		maven-doxia-sink-api-1.9.1-4.fc34.noarch
		maven-doxia-sitetools-1.9.2-4.fc34.noarch
		maven-file-management-3.0.0-12.fc34.noarch
		maven-filtering-3.2.0-2.fc34.noarch
		maven-jar-plugin-3.2.0-5.fc34.noarch
		maven-lib-3.6.3-8.fc34.noarch
		maven-model-2.2.1-67.fc34.noarch
		maven-plugin-bundle-4.2.1-4.fc34.noarch
		maven-reporting-api-3.0-21.fc34.noarch
		maven-resolver-api-1.4.2-5.fc34.noarch
		maven-resolver-connector-basic-1.4.2-5.fc34.noarch
		maven-resolver-impl-1.4.2-5.fc34.noarch
		maven-resolver-spi-1.4.2-5.fc34.noarch
		maven-resolver-transport-wagon-1.4.2-5.fc34.noarch
		maven-resolver-util-1.4.2-5.fc34.noarch
		maven-resources-plugin-3.2.0-2.fc34.noarch
		maven-shared-incremental-1.1-21.fc34.noarch
		maven-shared-io-3.0.0-12.fc34.noarch
		maven-shared-utils-3.2.1-0.8.fc34.noarch
		maven-source-plugin-3.2.1-4.fc34.noarch
		maven-surefire-3.0.0~M4-1.fc34.noarch
		maven-surefire-plugin-3.0.0~M4-1.fc34.noarch
		maven-surefire-provider-junit-3.0.0~M4-1.fc34.noarch
		maven-toolchain-2.2.1-67.fc34.noarch
		maven-wagon-file-3.4.2-1.fc34.noarch
		maven-wagon-http-3.4.2-1.fc34.noarch
		maven-wagon-http-shared-3.4.2-1.fc34.noarch
		maven-wagon-provider-api-3.4.2-1.fc34.noarch
		system-switch-java-1.1.8-5.fc34.noarch
		tzdata-java-2021a-1.fc34.noarch
		xz-java-1.8-10.fc34.noarch


everything ELSE gets built locally -- either per-machine, or on our in-house
distro/pgg'ing -- as needed.

similarly, on not-atypical non-dev end-user around here,

	rpm -qa | egrep -i "java|jdk|mvn|maven" | sort
		copy-jdk-configs-4.0-1.fc34.noarch
		java-11-openjdk-11.0.12.0.7-4.fc34.x86_64
		java-11-openjdk-devel-11.0.12.0.7-4.fc34.x86_64
		java-11-openjdk-headless-11.0.12.0.7-4.fc34.x86_64
		java-latest-openjdk-17.0.0.0.35-1.rolling.fc34.x86_64
		java-latest-openjdk-devel-17.0.0.0.35-1.rolling.fc34.x86_64
		java-latest-openjdk-headless-17.0.0.0.35-1.rolling.fc34.x86_64
		javapackages-filesystem-5.3.0-15.fc34.noarch
		javapackages-tools-5.3.0-15.fc34.noarch
		system-switch-java-1.1.8-5.fc34.noarch
		tzdata-java-2021a-1.fc34.noarch

and that's mostly it.

And again, in _some_ end-user cases, any 'needed' end-user apps are getting
installed from upstreams -- as tarballs, snaps, flatpaks, or rpms.  Seldom, if ever, from
Fedora pkgs.

[Mat Booth]

On Mon, 27 Sept 2021 at 13:31, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  On Mon, Sep 27, 2021 at 12:15:32PM +0100, Mat Booth wrote:
>  > On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  > >
>  > > A question about this which is semi-related to your email.
>  > >
>  > > For some C library packages we have Java bindings, eg:
>  > > https://github.com/libguestfs/libguestfs/tree/master/java
>  > >
>  > > These have been disabled in Fedora for ~2 years, but when they were
>  > > around they had these BuildRequires:
>  > >
>  > >   BuildRequires: java-1.8.0-openjdk
>  > >   BuildRequires: java-1.8.0-openjdk-devel
>  > >   BuildRequires: jpackage-utils
>  > >
>  > > I believe the only requirements are javac, javah, javadoc (optional)
>  > > and a JVM to run the tests on.
>  > >
>  > > Is it possible to keep this going, or would that require a lot of
>  > > work?  I notice that javah no longer seems to exist.
>  > >
>  > > (Note I know almost nothing about how the modern JDK works)
>  > >
>  > > Rich.
>  >
>  > Hi, the functionality provided by javah has been folded into javac in
>  > recent JDKs.
>  >
>  > These days you can make one call to "javac -h" instead of having to
>  > call both "javac" and "javah"
>  >
>  > I ported quite a few packages this way when Fedora made the switch to
>  > Java 11 by default. If you like I can probably take a look libguestfs
>  > and send you a PR?
>
>  Sure thing, thanks.
>
>  However before you start you might also want to know that there are
>  apparently some serious GC-related problems with how those bindings
>  work:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1536762
>
>  so it might be more of a saga than just changing a few commands.
>
>  Rich. 
Hi Rich,

TBH it looks like your Java bindings should build fine on Java 11
since this change:

https://github.com/libguestfs/libguestfs/commit/662dc5d0bf65e72dab11aa58d...

>  >
>  > >
>  > > --
>  > > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>  > > Read my programming and virtualization blog: http://rwmj.wordpress.com
>  > > virt-p2v converts physical machines to virtual machines.  Boot with a
>  > > live CD or over the network (PXE) and turn machines into KVM guests.
>  > > http://libguestfs.org/virt-v2v
>  > > _______________________________________________
>  > > devel mailing list -- devel(a)lists.fedoraproject.org
>  > > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  > > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>  >
>  >
>  >
>  > --
>  > Mat Booth
>  > http://fedoraproject.org/get-fedora
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
>  --
>  Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>  Read my programming and virtualization blog: http://rwmj.wordpress.com
>  virt-top is 'top' for virtual machines.  Tiny program with many
>  powerful monitoring features, net stats, disk stats, logging, etc.
>  http://people.redhat.com/~rjones/virt-top
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


-- 
Mat Booth
http://fedoraproject.org/get-fedora

[Mario Torre]

On Mon, Sep 27, 2021 at 5:23 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:

>  I'm not sure about this (the internals of Red Hat are quite
> opaque),
>  but as far as I know, are two different, non-overlapping teams
>  involved here:
>  One that maintains OpenJDK packages (which are fine), and one that
>  maintains Java packages (which have been dying in Fedora for years).
>  (I'm sorry If I am misrepresenting the situation inside Red Hat, but
>  this the extent of my knowledge.) 
I think this is because different teams do different things and
projects and contributions to Fedora are generally driven by
individuals that follow up on their main projects and maintain them
for Fedora, so it's more than "two" but probably a lot less than
"teams" :)

This makes sense, since Fedora is a community effort.

Cheers,
Mario
-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

[Florian Weimer]

* Fabio Valentini:

>  On Mon, Sep 27, 2021 at 1:07 PM Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
> >
> > A question about this which is semi-related to your email.
> >
> > For some C library packages we have Java bindings, eg:
> > https://github.com/libguestfs/libguestfs/tree/master/java
> >
> > These have been disabled in Fedora for ~2 years, but when they were
> > around they had these BuildRequires:
> >
> >   BuildRequires: java-1.8.0-openjdk
> >   BuildRequires: java-1.8.0-openjdk-devel
> >   BuildRequires: jpackage-utils
> >
> > I believe the only requirements are javac, javah, javadoc (optional)
> > and a JVM to run the tests on.
> >
> > Is it possible to keep this going, or would that require a lot of
> > work?  I notice that javah no longer seems to exist.
> >
> > (Note I know almost nothing about how the modern JDK works)
>
>  I think you'd probably want to do
>
>  1) switch to java-11-openjdk (it's the default on all currently
>  supported Fedora branches) 
This means that the built JAR files will be unusable with OpenJDK 8,
though.  Maybe there are still some users left?

Thanks,
Florian

[Richard W.M. Jones]

On Mon, Sep 27, 2021 at 04:39:03PM +0100, Mat Booth wrote:
>  On Mon, 27 Sept 2021 at 13:31, Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
>  > https://bugzilla.redhat.com/show_bug.cgi?id=1536762
>  >
>  > so it might be more of a saga than just changing a few commands.
>  >
>  > Rich.
>  
>  Hi Rich,
>  
>  TBH it looks like your Java bindings should build fine on Java 11
>  since this change:
>  
>  https://github.com/libguestfs/libguestfs/commit/662dc5d0bf65e72dab11aa58d...
You're right - I checked just now using:

java-11-openjdk-headless-11.0.11.0.9-4.fc35.x86_64
javapackages-filesystem-6.0.0-1.fc35.noarch
javapackages-tools-6.0.0-1.fc35.noarch

Tests pass too.

The bug above is a bit worrying though.  I don't think anyone ever
tried to address those issues.  I don't know enough to say if they're
real or nice to haves, but they seem serious.

BTW another project that would be fun for Java bindings (none exist
presently) is nbdkit https://gitlab.com/nbdkit/nbdkit

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Mat Booth]

On Mon, 27 Sept 2021 at 17:31, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  On Mon, Sep 27, 2021 at 04:39:03PM +0100, Mat Booth wrote:
>  > On Mon, 27 Sept 2021 at 13:31, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=1536762
>  > >
>  > > so it might be more of a saga than just changing a few commands.
>  > >
>  > > Rich.
>  >
>  > Hi Rich,
>  >
>  > TBH it looks like your Java bindings should build fine on Java 11
>  > since this change:
>  >
>  >
> https://github.com/libguestfs/libguestfs/commit/662dc5d0bf65e72dab11aa58d...
>
>  You're right - I checked just now using:
>
>  java-11-openjdk-headless-11.0.11.0.9-4.fc35.x86_64
>  javapackages-filesystem-6.0.0-1.fc35.noarch
>  javapackages-tools-6.0.0-1.fc35.noarch
>
>  Tests pass too.
>
>  The bug above is a bit worrying though.  I don't think anyone ever
>  tried to address those issues.  I don't know enough to say if they're
>  real or nice to haves, but they seem serious.
>  
I think the only super serious one is the local reference leaks --
this can be fatal to an application. The other concerns seem "just"
perf-related.

>  BTW another project that would be fun for Java bindings (none exist
>  presently) is nbdkit https://gitlab.com/nbdkit/nbdkit
>
>  Rich. 



-- 
Mat Booth
http://fedoraproject.org/get-fedora

[Christopher]

On Mon, Sep 27, 2021 at 8:52 AM Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  On Sun, 26 Sept 2021 at 16:35, Christopher <ctubbsii(a)fedoraproject.org&gt; wrote:
>  >
>  > I think part of the problem is that Java is too big. There are too
>  > many libraries to fit into a single community. I think there's
>  > probably willing volunteers to maintain some libraries and application
>  > packages, but these are not necessarily the same people willing to do
>  > all the work of maintaining OpenJDK packages or the whole Eclipse
>  > stack.
>  >
>  > When modularity took out the whole Java stack, it did a lot of lasting
>  > damage that is going to be hard to recover from. In order for the vast
>  > majority of Java packagers to return, there needs to be a reliable
>
>  I am going to disagree here greatly. The Java stack was in exactly the
>  same mode it is in now before then. There was 1 person 'maintaining'
>  hundreds of packages for a long time. There were other 'maintainers'
>  listed but they were not around or ignoring things from burnout.
>  People had brought this up year after year and all that would happen
>  is everyone would say "we can't ever let things down" and pitch in to
>  fix things (or make the 1 person who was over-committed feel guilty
>  for asking to lighten the load). 
I didn't mean to imply that there wasn't a problem before. I was
merely using the mass orphaning of the traditional packages in favor
of the modules as a point of reference in the timeline. I don't know
about the prior problems, only that there were problems that were
subsequent to, and worsened by, the mass orphaning event, regardless
of what led to it.

My main point here was that treating the community as a single SIG
makes no more sense than treating all packages whose software is
written in C as a single "C SIG" community. It's too overwhelming for
people to be able to know how to step in and help. It needs to be
pieced back together from the bottom up. OpenJDK packages seem to be
reliable and healthy. Eclipse seems to have some serious problems
(it's unclear to me how important Eclipse is, since upstream binaries
seem sufficient to me). I'm uncertain about XMvn and all the common
dependencies that used to be present, but I suspect this is where the
most damage was done, and the greatest room for volunteers... if it
weren't so overwhelming.

>  Then when the defacto Java maintainer moved stuff into modules to make
>  his life easier.. there was a 'well we can find new people to do this
>  instead' and various initiatives were tried to make it. Those have all
>  failed because
>
>  1. Java and Fedora have a long back history of ugly fighting which
>  makes it hard for 'older' Java people want to work with Fedora. Like
>  old feuds, there are landmines which flare up fights no one remembers
>  exactly but they come up.
>  2. That ugly fighting is sort of written into the packaging guidelines
>  because it is a long 'compromise' between how Java wants packages done
>  and how Fedora wants it done. This makes it hard for 'new' Java people
>  because they are whiplashed between different world views. And vice
>  versa, if you aren't a Java person and try to make it fix a Java
>  package it can be a brain hurt as you try to do things like in other
>  packages and it all fails.
>  3. Most Fedora consumers just want the tools to work and pile onto the
>  smaller pool of developers about 'why is X always broken?' This has
>  caused continual burnout when new teams came up. It was also what was
>  burning out the previous people. 
I came in with none of that history. I saw XMvn, thought it was
awesome, and started packaging with it. Perhaps some of that
history/conflict affected some packagers, but I never saw it play a
big role, based on the timing of when I started contributing. Maybe it
played a big role, maybe it didn't. I think people who have been
around longer and have been more deeply involved might have a
different perspective than people who are newer and more casual
contributors. I worry that the long-timers may not be able to
understand how the new packager experiences contribute to Fedora's
problems (particularly the ability to keep up with attrition), and
only focus on the deep and/or historical problems, even when they have
little to no impact on newer folks who aren't aware of any of that.

>  Basically Java has been 'broken' for as long as I have been part of
>  Fedora. The 'good' times are usually just after the last time Java was
>  going to be pulled out in the next release, and finally everyone drops
>  the things they really care for and works on it. Then everyone goes
>  back to their real pleasures and it falls apart again. Later, rinse,
>  repeat.
>  
My experience differs. I didn't find Java in Fedora broken at all when
I started. I actually found the set of available packages in Fedora to
be quite functional prior to the mass orphaning. It may have had its
community problems, and some out-of-date packages, but the overall
experience from this casual packager maintaining a few Java
application packages was quite sufficient. It wasn't perfect, but it
worked, and I could file tickets and occasionally help when something
didn't work. When the mass orphaning happened, it became impossible to
keep up with the loss of dependencies, and modularity was too
confusing (and didn't seem appropriate for my packages). But, before
that, it definitely wasn't broken for me. In fact, it was amazing,
especially how functional XMvn was to help me package easily.

>
> --
> Stephen J Smoogen.
> I've seen things you people wouldn't believe. Flame wars in
> sci.astro.orion. I have seen SPAM filters overload because of Godwin's
> Law. All those moments will be lost in time... like posts on a BBS...
> time to shutdown -h now.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Raphael Groner]

Hi,

""
I'm not sure what's the best solution, but I guess the number one
reason to have packages within the Fedora distribution is for a matter
of trust, if this is the case I would argue that a curated list of
maven packages served via a Fedora managed repository would be a
better investment.
""
+1

Well, the modularity movement generally disappointed a lot of previously motivated
maintainers but was a good decision imho. for java related stuff.

just my 5ct.

[Florian Weimer]

* Christopher:

>  My main point here was that treating the community as a single SIG
>  makes no more sense than treating all packages whose software is
>  written in C as a single "C SIG" community. It's too overwhelming for
>  people to be able to know how to step in and help. 
I'm not sure this is actually true.  Debian has Python and Perl
packaging teams which are quite successful, and the Java packaging may
also be in better shape there.

I think the difference to C is that these languages come with their own
packaging/build systems, so creating a distribution package needs a
certain number of kludges, but once you've figured those out, you can
maintain a large number of packages.  I thought that Java used to be
like this, too, thanks to ant and later Maven, but maybe this has
changed with Gradle, SBT, and whatnot.

Thanks,
Florian

[Felix Schwarz]

Am 27.09.21 um 15:09 schrieb Mario Torre:
>  However the majority of people just usually download Eclipse (or
> IntelliJ for
>  what matters) from the upstream website anyway, further suggesting that
>  maintaining Eclipse is not really a rewarding nor useful task. 
Just my 2 ¢: Since I switched from upstream Eclipse tarballs to Fedora's Eclipse 
packages my developer experience improved so much. Previously I had to make 
Eclipse cleaning up its temporary files quite often. With Fedora's Eclipse 
mostly just worked fine.

So a big thanks to the previous Java/Eclipse maintainers from me. I really 
appreciate the effort.

Felix

[Kevin Kofler]

Richard W.M. Jones wrote:
>  The bug above is a bit worrying though.  I don't think anyone
> ever
>  tried to address those issues.  I don't know enough to say if they're
>  real or nice to haves, but they seem serious. 
I have never seen any handwritten JNI code doing any of the things the bug 
wants you to do. Maybe some binding generators do, but handwritten JNI code 
practically never bothers.

        Kevin Kofler

[Kevin Kofler]

Robert Marcano via devel wrote:
>  I think the only way the Java ecosystem to survive in Fedora outside
> of
>  OpenJDK and some core components is to allow bundling (Even JavaScript
>  bundling is already allowed), but how do to it without compromising
>  security? 
The problem is that Java projects typically bundle prebuilt binaries, which 
is a complete no go. The big issue is not that the libraries are bundled, it 
is that they are bundled in prebuilt binary form, often even without the 
source code at all.

Fixing this requires work no matter whether the packager works the way you 
propose or whether they simply unbundle the dependencies. So I do not see 
any valid reason to not just go ahead and unbundle. (At least for the 
typical application. Things like Eclipse plugins, using nested JARs, are the 
exception and might indeed need special treatment.)

The Go and Rust case is different because the library packages are shipped 
as source code and the application packages then BuildRequire that source 
code. Doing the same for Java would require modifying the upstream build 
systems even more than just depending on a Fedora-built JAR would (because 
the Go/Rust way is not how Java normally works). So I do not see any 
advantage in doing things that way. (And for the record, I also think that 
Go and Rust should not work that way either! It is possible to build shared 
libraries of Go code, at least one Go toolchain supports it.)

The JavaScript case is also different because everything that is bundled is 
bundled as source code. JavaScript does not have anything like a compiled 
JAR file.

        Kevin Kofler

[Florian Weimer]

* Kevin Kofler via devel:

>  (And for the record, I also think that Go and Rust should not work
>  that way either! It is possible to build shared libraries of Go code,
>  at least one Go toolchain supports it.) 
There is no stable Go ABI.  Even minor updates change ABI because type
sizes and struct offsets change and are inlined across shared object
boundaries.  You have to rebuild all reverse dependencies to avoid ABI
mismatches.  Go's compatibility guarantees only apply at the source
level and do not preclude the addition of new struct fields, for
example.

Just because there is a way to build shared objects does not mean it's
possible to use this capability to short-circuit build processes like we
do for most C and many C++ packages.

Thanks,
Florian

[Kevin Kofler]

Florian Weimer wrote:

>  * Kevin Kofler via devel:
>  
> > (And for the record, I also think that Go and Rust should not work
> > that way either! It is possible to build shared libraries of Go code,
> > at least one Go toolchain supports it.)
>  
>  There is no stable Go ABI.  Even minor updates change ABI because type
>  sizes and struct offsets change and are inlined across shared object
>  boundaries.  You have to rebuild all reverse dependencies to avoid ABI
>  mismatches.  Go's compatibility guarantees only apply at the source
>  level and do not preclude the addition of new struct fields, for
>  example. 
The same goes for OCaml and yet we still manage to ship almost everything in 
OCaml dynamically linked. IMHO, that is the way a binary distribution should 
work, not the way Go and Rust are currently packaged. Source code does not 
belong into binary packages.

        Kevin Kofler

[Florian Weimer]

* Kevin Kofler via devel:

>  Florian Weimer wrote:
>
> > * Kevin Kofler via devel:
> > 
> >> (And for the record, I also think that Go and Rust should not work
> >> that way either! It is possible to build shared libraries of Go code,
> >> at least one Go toolchain supports it.)
> > 
> > There is no stable Go ABI.  Even minor updates change ABI because type
> > sizes and struct offsets change and are inlined across shared object
> > boundaries.  You have to rebuild all reverse dependencies to avoid ABI
> > mismatches.  Go's compatibility guarantees only apply at the source
> > level and do not preclude the addition of new struct fields, for
> > example.
>
>  The same goes for OCaml and yet we still manage to ship almost everything in 
>  OCaml dynamically linked. 
Interesting.  Could you provide an example of such a dynamically linked
binary?

Thanks,
Florian

[Richard W.M. Jones]

On Tue, Sep 28, 2021 at 01:42:44PM +0200, Florian Weimer wrote:
>  * Kevin Kofler via devel:
>  
>  > Florian Weimer wrote:
>  >
>  >> * Kevin Kofler via devel:
>  >> 
>  >>> (And for the record, I also think that Go and Rust should not work
>  >>> that way either! It is possible to build shared libraries of Go code,
>  >>> at least one Go toolchain supports it.)
>  >> 
>  >> There is no stable Go ABI.  Even minor updates change ABI because type
>  >> sizes and struct offsets change and are inlined across shared object
>  >> boundaries.  You have to rebuild all reverse dependencies to avoid ABI
>  >> mismatches.  Go's compatibility guarantees only apply at the source
>  >> level and do not preclude the addition of new struct fields, for
>  >> example.
>  >
>  > The same goes for OCaml and yet we still manage to ship almost
>  > everything in OCaml dynamically linked. 
We rebuild everything on every OCaml release, and ...

>  Interesting.  Could you provide an example of such a dynamically
> linked
>  binary? 
C libraries of OCaml binaries are dynamically linked, eg:
$ ldd /usr/bin/virt-v2v
  linux-vdso.so.1 (0x00007ffce93ab000)
  libvirt.so.0 => /lib64/libvirt.so.0 (0x00007f5a759c7000)
  libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f5a75930000)
  libguestfs.so.0 => /lib64/libguestfs.so.0 (0x00007f5a757cc000)
  libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f5a75643000)
[etc]

OCaml library code can in principle be dynamically linked, eg:

$ rpm -ql ocaml-extlib | grep cmxs
/usr/lib64/ocaml/extlib/extLib.cmxs
$ file /usr/lib64/ocaml/extlib/extLib.cmxs
/usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64, version 1
(SYSV), dynamically linked, BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with
debug_info, not stripped

but upstream doesn't make it possible to ship OCaml binaries this way,
(they would still require rebuilding on every library update) and so
we only ship the DLLs not fully dynamically linked OCaml binaries
(except for the C code).

This is kind of OK because OCaml code doesn't suffer the slings and
arrows of outrageous pointers.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Kevin Kofler]

Florian Weimer wrote:
>  Interesting.  Could you provide an example of such a dynamically
> linked
>  binary? 
OCaml is interesting in that it does not use standard ELF .so files, but its 
own dynamic linking mechanism (those .cma files).

This is a typical OCaml library (the ocaml-facile constraint satisfaction 
problem solver):
https://koji.fedoraproject.org/koji/rpminfo?rpmID=27058403
You see that it has both Provides and Requires, and a -devel package:
https://koji.fedoraproject.org/koji/rpminfo?rpmID=27058407

(I know that library because Kalzium, the KDE periodic table of elements 
application, depends on it. However, Kalzium is in C++ and actually 
statically links ocaml-facile and the OCaml runtime.)

The OCaml compiler itself is also dynamically linked:
https://koji.fedoraproject.org/koji/rpminfo?rpmID=27059751

For details, better ask Richard W.M. Jones.

        Kevin Kofler

[Kevin Kofler]

Richard W.M. Jones wrote:
>  OCaml library code can in principle be dynamically linked, eg:
>  
>  $ rpm -ql ocaml-extlib | grep cmxs
>  /usr/lib64/ocaml/extlib/extLib.cmxs
>  $ file /usr/lib64/ocaml/extlib/extLib.cmxs
>  /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64,
>  version 1 (SYSV), dynamically linked,
>  BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info,
>  not stripped
>  
>  but upstream doesn't make it possible to ship OCaml binaries this way,
>  (they would still require rebuilding on every library update) and so
>  we only ship the DLLs not fully dynamically linked OCaml binaries
>  (except for the C code). 
Ah?

So what sits in the main packages of libraries (e.g., in ocaml-facile as 
opposed to ocaml-facile-devel) then? Don't only shared libraries belong in 
the main package?

So I take back my comment that the OCaml stack is properly packaged. ;-) 
That sounds like almost as much of a mess as Go and Rust then.

        Kevin Kofler

[Richard W.M. Jones]

On Tue, Sep 28, 2021 at 02:06:58PM +0200, Kevin Kofler via devel wrote:
>  Richard W.M. Jones wrote:
>  > OCaml library code can in principle be dynamically linked, eg:
>  > 
>  > $ rpm -ql ocaml-extlib | grep cmxs
>  > /usr/lib64/ocaml/extlib/extLib.cmxs
>  > $ file /usr/lib64/ocaml/extlib/extLib.cmxs
>  > /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64,
>  > version 1 (SYSV), dynamically linked,
>  > BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info,
>  > not stripped
>  > 
>  > but upstream doesn't make it possible to ship OCaml binaries this way,
>  > (they would still require rebuilding on every library update) and so
>  > we only ship the DLLs not fully dynamically linked OCaml binaries
>  > (except for the C code).
>  
>  Ah?
>  
>  So what sits in the main packages of libraries (e.g., in ocaml-facile as 
>  opposed to ocaml-facile-devel) then? Don't only shared libraries belong in 
>  the main package? 
The original split of ocaml-FOO / ocaml-FOO-devel doesn't make a lot
of sense these days.  Ideally we'd put them all in one package.

>  So I take back my comment that the OCaml stack is properly packaged.
> ;-) 
>  That sounds like almost as much of a mess as Go and Rust then. 
I'd hardly say OCaml packging is a mess.  It's much closer to the
spirit of C packaging than those others.  If you have *specific,
actionable* objections I will listen to them.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Richard W.M. Jones]

On Tue, Sep 28, 2021 at 02:00:58PM +0200, Kevin Kofler via devel wrote:
>  Florian Weimer wrote:
>  > Interesting.  Could you provide an example of such a dynamically linked
>  > binary?
>  
>  OCaml is interesting in that it does not use standard ELF .so files, but its 
>  own dynamic linking mechanism (those .cma files). 
.cma files are metadata for bytecode static linking.

.cmxa files are metadata for native code static linking.

.cmxs files are renamed *.so files and can be used for fully dynamic
linking of OCaml native code.

Other issues make it difficult to ship dynamically linked binaries of
pure OCaml code, so in practice *.cmxs are only used for dlopen-style
dynamic loading.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

[Robert Marcano]

On 9/27/21 7:54 PM, Kevin Kofler via devel wrote:
>  Robert Marcano via devel wrote:
> > I think the only way the Java ecosystem to survive in Fedora outside of
> > OpenJDK and some core components is to allow bundling (Even JavaScript
> > bundling is already allowed), but how do to it without compromising
> > security?
>  
>  The problem is that Java projects typically bundle prebuilt binaries, which
>  is a complete no go. The big issue is not that the libraries are bundled, it
>  is that they are bundled in prebuilt binary form, often even without the
>  source code at all. 
Even in the case of SCM repositories committed binaries, allowing 
bundling would help a lot, add some kind of automation that replace 
these jar for the proposed local created maven repository, and link to 
them, and add the metadata to the RPM to know it need to be rebuilt when 
that dependency is updated. This is a lot more easier than fighting old 
build scripts that don't use some kind of dependency manager. It will 
probably be hard for these kind of packages, but any modern application 
using using a modern build system could become easier to package.

>  
>  Fixing this requires work no matter whether the packager works the way you
>  propose or whether they simply unbundle the dependencies. So I do not see
>  any valid reason to not just go ahead and unbundle. (At least for the
>  typical application. Things like Eclipse plugins, using nested JARs, are the
>  exception and might indeed need special treatment.)
>  
>  The Go and Rust case is different because the library packages are shipped
>  as source code and the application packages then BuildRequire that source
>  code. Doing the same for Java would require modifying the upstream build
>  systems even more than just depending on a Fedora-built JAR would (because
>  the Go/Rust way is not how Java normally works). So I do not see any
>  advantage in doing things that way. (And for the record, I also think that
>  Go and Rust should not work that way either! It is possible to build shared
>  libraries of Go code, at least one Go toolchain supports it.)
>  
>  The JavaScript case is also different because everything that is bundled is
>  bundled as source code. JavaScript does not have anything like a compiled
>  JAR file.
>  
>           Kevin Kofler
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Stephen John Smoogen]

On Tue, 28 Sept 2021 at 08:20, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  On Tue, Sep 28, 2021 at 02:06:58PM +0200, Kevin Kofler via devel wrote:
>  > Richard W.M. Jones wrote:
>  > > OCaml library code can in principle be dynamically linked, eg:
>  > >
>  > > $ rpm -ql ocaml-extlib | grep cmxs
>  > > /usr/lib64/ocaml/extlib/extLib.cmxs
>  > > $ file /usr/lib64/ocaml/extlib/extLib.cmxs
>  > > /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64,
>  > > version 1 (SYSV), dynamically linked,
>  > > BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info,
>  > > not stripped
>  > >
>  > > but upstream doesn't make it possible to ship OCaml binaries this way,
>  > > (they would still require rebuilding on every library update) and so
>  > > we only ship the DLLs not fully dynamically linked OCaml binaries
>  > > (except for the C code).
>  >
>  > Ah?
>  >
>  > So what sits in the main packages of libraries (e.g., in ocaml-facile as
>  > opposed to ocaml-facile-devel) then? Don't only shared libraries belong in
>  > the main package?
>
>  The original split of ocaml-FOO / ocaml-FOO-devel doesn't make a lot
>  of sense these days.  Ideally we'd put them all in one package.
>
>  > So I take back my comment that the OCaml stack is properly packaged. ;-)
>  > That sounds like almost as much of a mess as Go and Rust then.
>
>  I'd hardly say OCaml packging is a mess.  It's much closer to the
>  spirit of C packaging than those others.  If you have *specific,
>  actionable* objections I will listen to them.
>
>  
I think Kevin's comment is meant more towards the way the language
packages itself versus the rpm packaging of the language. Going from
Kevin's comments on languages over the years, a 'good' language should
not require such sort of rebuilding.


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.

[Fabio Valentini]

On Tue, Sep 28, 2021 at 2:26 PM Robert Marcano via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 9/27/21 7:54 PM, Kevin Kofler via devel wrote:
>  > Robert Marcano via devel wrote:
>  >> I think the only way the Java ecosystem to survive in Fedora outside of
>  >> OpenJDK and some core components is to allow bundling (Even JavaScript
>  >> bundling is already allowed), but how do to it without compromising
>  >> security?
>  >
>  > The problem is that Java projects typically bundle prebuilt binaries, which
>  > is a complete no go. The big issue is not that the libraries are bundled, it
>  > is that they are bundled in prebuilt binary form, often even without the
>  > source code at all.
>
>  Even in the case of SCM repositories committed binaries, allowing
>  bundling would help a lot, add some kind of automation that replace
>  these jar for the proposed local created maven repository, and link to
>  them, and add the metadata to the RPM to know it need to be rebuilt when
>  that dependency is updated. This is a lot more easier than fighting old
>  build scripts that don't use some kind of dependency manager. It will
>  probably be hard for these kind of packages, but any modern application
>  using using a modern build system could become easier to package. 
This is actually 100% how packaging applications that use ant +
bundled dependencies (i.e. often .jar files in a "/lib/" directory)
has worked for ages already.
So the Java packaging tools we have in Fedora support this use case just fine.

Fabio

[Fabio Valentini]

On Mon, Sep 27, 2021 at 9:09 PM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  * Christopher:
>
>  > My main point here was that treating the community as a single SIG
>  > makes no more sense than treating all packages whose software is
>  > written in C as a single "C SIG" community. It's too overwhelming for
>  > people to be able to know how to step in and help.
>
>  I'm not sure this is actually true.  Debian has Python and Perl
>  packaging teams which are quite successful, and the Java packaging may
>  also be in better shape there.
>
>  I think the difference to C is that these languages come with their own
>  packaging/build systems, so creating a distribution package needs a
>  certain number of kludges, but once you've figured those out, you can
>  maintain a large number of packages.  I thought that Java used to be
>  like this, too, thanks to ant and later Maven, but maybe this has
>  changed with Gradle, SBT, and whatnot. 
Yeah, there's good tooling support for packaging software that uses
ant and maven.
And ant and maven themselves will also continue to be maintained by
Mikolaj, as far as I know.
Projects that use "pure" ant or maven to handle their dependencies and
build are *very easy* to package for Fedora, probably even easier than
some standard C or Python packages. And the resulting binary packages
are also very similar to how Python works (except that Java packages
only ship compiled bytecode and no sources).

But as you guessed, there's no such support for gradle, sbt, bazel, or
whatever new build system Google has been cooking up recently. Nor is
there support for Groovy (no longer available in Fedora, as it
depended on gradle), Kotlin (was never packaged), or Scala (no longer
available) - all of which are now dependencies of gradle. Oh, fun.
While gradle *used* to be available as an option for Fedora Java
packages, recent versions of gradle are a barely-open-source mess that
apparently only upstream itself manages to build from source, and
everybody else is supposed to "just build with internet access and use
our binary JAR, it's fine (TM)".

Another problem is projects that use ant or maven, but do horrendous,
nonstandard things *within* those build systems, either with custom
ant targets, or weird maven plugins.
Maintaining packages that do this sort of thing is very tedious and
error-prone, because you as the package maintainer need to keep all
the weird "undo this unspeakable upstream horror" changes in sync for
new upstream versions.

And if upstream decides to port their project from maven to gradle (as
some have recently done), then good luck with forward-porting the old
maven pom.xml files to new versions.

I'm sorry if I sound overly negative here. But the fact that
1) using maven is actually not terrible for making RPM packages,
2) packaging tools for Java are actually pretty comprehensive, but still
3) upstream projects are increasingly doing non-standard things making
tools in 1) and 2) obsolete and packaging a very frustrating
experience,
makes me sad.

But since most upstream projects stance is to "just download the JAR
we built for you from Maven Central, why are you even looking at our
source code, ewww", that is unlikely to change. But I'm not sure if
that really fits the FOSS definition any longer, either.

Fabio

[Mat Booth]

>  Yeah, there's good tooling support for packaging software that
> uses
>  ant and maven.
>  And ant and maven themselves will also continue to be maintained by
>  Mikolaj, as far as I know.
>  Projects that use "pure" ant or maven to handle their dependencies and
>  build are *very easy* to package for Fedora, probably even easier than
>  some standard C or Python packages. 
You're not wrong. Thanks to great tooling, there's many Java packages
in Fedora whose spec file is simply this:

%build
%mvn_build
%install
%mvn_install

However, I do feel the pain of upstream projects switching to gradle,
not because they are experiencing problems with maven that gradle was
designed to solve, but just because it's trendy. I personally ported
several projects back over to maven build system to keep something
vital in the distro. It's not difficult (maybe, for someone who has
been using maven years and years and years), but quite tedious.

-- 
Mat Booth
http://fedoraproject.org/get-fedora

[Demi Marie Obenour]

On 9/27/21 8:31 AM, Richard W.M. Jones wrote:
>  On Mon, Sep 27, 2021 at 12:15:32PM +0100, Mat Booth wrote:
> > On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
> >>
> >> A question about this which is semi-related to your email.
> >>
> >> For some C library packages we have Java bindings, eg:
> >> https://github.com/libguestfs/libguestfs/tree/master/java
> >>
> >> These have been disabled in Fedora for ~2 years, but when they were
> >> around they had these BuildRequires:
> >>
> >>   BuildRequires: java-1.8.0-openjdk
> >>   BuildRequires: java-1.8.0-openjdk-devel
> >>   BuildRequires: jpackage-utils
> >>
> >> I believe the only requirements are javac, javah, javadoc (optional)
> >> and a JVM to run the tests on.
> >>
> >> Is it possible to keep this going, or would that require a lot of
> >> work?  I notice that javah no longer seems to exist.
> >>
> >> (Note I know almost nothing about how the modern JDK works)
> >>
> >> Rich.
> >
> > Hi, the functionality provided by javah has been folded into javac in
> > recent JDKs.
> >
> > These days you can make one call to "javac -h" instead of having to
> > call both "javac" and "javah"
> >
> > I ported quite a few packages this way when Fedora made the switch to
> > Java 11 by default. If you like I can probably take a look libguestfs
> > and send you a PR?
>  
>  Sure thing, thanks.
>  
>  However before you start you might also want to know that there are
>  apparently some serious GC-related problems with how those bindings
>  work:
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=1536762
>  
>  so it might be more of a saga than just changing a few commands.
>  
>  Rich. 
As the person who reported that bug, I don’t think it is likely to be hit
normally.  Most of the problems are either poor performance (not using
direct ByteBuffers) or potential crashes in low memory conditions (which
most users will not run into).   I do not believe that any of these crashes
are exploitable.

That said, I am also unsure if anyone is using those bindings.  Why were they
added originally?

Sincerely,

Demi Marie Obenour (she/her/hers)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 28, 2021 at 04:33:39PM +0200, Fabio Valentini wrote:
>  But as you guessed, there's no such support for gradle, sbt,
> bazel, or
>  whatever new build system Google has been cooking up recently. Nor is
>  there support for Groovy (no longer available in Fedora, as it
>  depended on gradle), Kotlin (was never packaged), or Scala (no longer
>  available) - all of which are now dependencies of gradle. Oh, fun.
>  While gradle *used* to be available as an option for Fedora Java
>  packages, recent versions of gradle are a barely-open-source mess that
>  apparently only upstream itself manages to build from source, and
>  everybody else is supposed to "just build with internet access and use
>  our binary JAR, it's fine (TM)".
>  
>  Another problem is projects that use ant or maven, but do horrendous,
>  nonstandard things *within* those build systems, either with custom
>  ant targets, or weird maven plugins. 
I think this difference in philosophical approach is the crux of
the problem. Elsewhere in the thread people mentioned many smaller and
larger *technical* issues, and we probably would have overcome those
with enough motivation. But packaging of Java is so horrible because
upstreams are completely uninterested in people consuming their
software by compiling it from sources and reusing within other projects.

Hence: crazy build systems that only work on some developer's mac on
alternate weekdays, self-dependent build systems, downloading of
random stuff from the network, constant api breaks and renames of
things, and I'd say generally low quality of output.

>  using maven is actually not terrible for making RPM packages, 
Yeah, we have maven under control. I remember how maven started being
popular, and was a huge improvement over the older java build systems.
But looking back, it was never so great: for example, it was always
intended only a always-online build system; the local builds we do with Xmvn
are one giant hack. Version dependencies are pinned exactly, there was
never any idea of version ranges or semantic versioning. And doing
anything slightly non-standard with Maven was always extremely painful;
things that would be one or two lines in Make or other build systems
could turn into an extremely fragile 150 lines of XML. And even though
Maven could be the best this ecosystem produced, it already started
moving in the directions that ultimately made the later systems unusable.

Ultimately, I think the Java packages in Fedora are dying because
their ecosystem has philosophies which go in a different direction
than our subset of the software world: building a pipeline directly
from version-controlled code to any build artifacts, reproducible
builds, limited trust, testing and scanning at all levels, automatization,
simplification of build systems and packaging.

Zbyszek

[Miro Hrončok]

On 26. 09. 21 21:20, Fabio Valentini wrote:
>  Should the @java-maint-sig group be removed from any packages it is
>  still associated with? Should it be dissolved, and members be removed?
>  Should the remaining ruins that used to be packages be orphaned?
>  Retired? Buried? Forgotten? 
Since many have moved this discussion away from this question, let me please 
bring back the main reason this was posted.

Since the @java-maint-sig group is esentially non-responsive, I suggest we do 
the following:


1) We remove all BZ assignee overrides to @java-maint-sig. This is a must.
2) We remove access of @java-maint-sig from all packages.
3) We ask the members of the group if they want to admin the list/BZ account.
   3a) We give it to the volunteer.
   3b) We empty the group and cancel the BZ account/list if nobody shows up.
4) We *don't orphan the packages*, they have some "de jure" maintainers.

The packages that fail to install and/or build will eventually die out due to 
the existing processes.

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Aleksandar Kurtakov]

On Wed, Sep 29, 2021 at 2:50 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

>  On 26. 09. 21 21:20, Fabio Valentini wrote:
>  > Should the @java-maint-sig group be removed from any packages it is
>  > still associated with? Should it be dissolved, and members be removed?
>  > Should the remaining ruins that used to be packages be orphaned?
>  > Retired? Buried? Forgotten?
>
>  Since many have moved this discussion away from this question, let me
>  please
>  bring back the main reason this was posted.
>
>  Since the @java-maint-sig group is esentially non-responsive, I suggest we
>  do
>  the following:
>
>
>  1) We remove all BZ assignee overrides to @java-maint-sig. This is a must.
>  2) We remove access of @java-maint-sig from all packages.
>  3) We ask the members of the group if they want to admin the list/BZ
>  account.
>     3a) We give it to the volunteer.
>     3b) We empty the group and cancel the BZ account/list if nobody shows
>  up.
>  4) We *don't orphan the packages*, they have some "de jure" maintainers.
>
>  
Please do so! There is nothing worse than false assumptions like there is
active Java SIG.


>  The packages that fail to install and/or build will eventually die
> out due
>  to
>  the existing processes.
>
>  --
>  Miro Hrončok
>  --
>  Phone: [phone]
>  IRC: mhroncok
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team

[Fabio Valentini]

On Wed, Sep 29, 2021 at 1:49 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 26. 09. 21 21:20, Fabio Valentini wrote:
>  > Should the @java-maint-sig group be removed from any packages it is
>  > still associated with? Should it be dissolved, and members be removed?
>  > Should the remaining ruins that used to be packages be orphaned?
>  > Retired? Buried? Forgotten?
>
>  Since many have moved this discussion away from this question, let me please
>  bring back the main reason this was posted.
>
>  Since the @java-maint-sig group is esentially non-responsive, I suggest we do
>  the following:
>
>
>  1) We remove all BZ assignee overrides to @java-maint-sig. This is a must.
>  2) We remove access of @java-maint-sig from all packages.
>  3) We ask the members of the group if they want to admin the list/BZ account.
>     3a) We give it to the volunteer.
>     3b) We empty the group and cancel the BZ account/list if nobody shows up.
>  4) We *don't orphan the packages*, they have some "de jure" maintainers.
>
>  The packages that fail to install and/or build will eventually die out due to
>  the existing processes. 
Thanks for getting back to my original question :)
The points you outlined seem like a good plan.

Maybe file a ticket with FESCo and copy-paste these 4 points?
FESCo already handles non-responsive maintainer process, to it's
probably the best fit.
Not sure if we'd actually need to vote on it, but it would be good to
have it documented.

Fabio

[Peter Boy]

>  Am 29.09.2021 um 13:49 schrieb Miro Hrončok
> <mhroncok(a)redhat.com&gt;:
>  
>  Since many have moved this discussion away from this question, let me please bring back
> the main reason this was posted.
>  
>  Since the @java-maint-sig group is esentially non-responsive, I suggest we do the
> following:
>  
>  
>  1) We remove all BZ assignee overrides to @java-maint-sig. This is a must.
>  2) We remove access of @java-maint-sig from all packages.
>  3) We ask the members of the group if they want to admin the list/BZ account.
>   3a) We give it to the volunteer.
>   3b) We empty the group and cancel the BZ account/list if nobody shows up.
>  4) We *don't orphan the packages*, they have some "de jure" maintainers.
>  
>  The packages that fail to install and/or build will eventually die out due to the
> existing processes. 
Given the current situation, that seems like a sensible way to go.

However, under no circumstances should such a move be put into action unless all current
group members have been explicitly asked for their opinions. 

For one thing, I think that would be simply bad practice. For another, about half of the
current 12 members seem to be dedicated to Java, (they are "only" assigned to
the 200 - 300 mostly Java core packages, not thousands of packages across the
distribution). So they are potentially the ones who are currently actively maintaining the
Fedora Java stack. They should have a say in the matter how to organise the work.

If no one responds within 1-2 weeks (which I would almost expect, unfortunately), then
this structure is clearly obsolete.

[Karlis K.]

This: https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Java-Rough...

Brought my attention, what can be done to help?

[Peter Boy]

>  Am 29.09.2021 um 13:57 schrieb Fabio Valentini
> <decathorpe(a)gmail.com&gt;:
>  
>  On Wed, Sep 29, 2021 at 1:49 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
> > 
> > On 26. 09. 21 21:20, Fabio Valentini wrote:
> >> Should the @java-maint-sig group be removed from any packages it is
> >> still associated with? Should it be dissolved, and members be removed?
> > ...
> > 
>  
>  Thanks for getting back to my original question :)
>  The points you outlined seem like a good plan. 
I would like to get back to the other part or your question:

>  I'd rather have the group start from zero now, and start
> *adding*
>  packages again that are actually really needed, wanted, and
>  maintained. 

How can we not only remove something not working, but also buildup something (hopefully)
working?

A few items to build upon emerge from this thread:

- There are people who want to contribute but don’t find a starting point
- Technically, there is a stable support for core packages providing a solid base to build
upon
- In terms of communication/information, there is uncertainty and missinformation
- (Re-)structure the huge Fedora Java body into manageable areas (core, lib, apps)
- Various ideas to streamline and simplify the building process
- Guidelines (and maybe new tools or procedures) to install third party binaries (e.g.
curated list of maven packages, Ansible Wildfly developed by Server WG)
- Specifying a reliable core, and an application layer will build up


By far the most important and urgent task is likely to be documentation / communication /
transparency and to eliminate the misinformation, uncertainties and irritations that have
arisen. That would probably be a prerequisite for everything else and followed by
documentation and information for new maintainers / application packages. 

It would be really nice to have not only a ripping title and mourn the situation, but also
a ripped action and energetic doing. 



Any ideas to get it started to fly?

[Peter Boy]

>  Am 29.09.2021 um 22:13 schrieb Karlis K.
> <karliskavacis(a)gmail.com&gt;:
>  
>  This: https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Java-Rough...
>  
>  Brought my attention, what can be done to help? 

I take it as a question how to contribute to Fedora Java.

In the end, I guess, we will need to find a group of people who are willing to commit and
to collaborate.

The first thing that comes to mind would be to briefly express your opinion on the topics
discussed here and perhaps outline your ideas on contributions. And whether you would be
willing to make real contributions, ie. spend work and time.

[Emmanuel Seyman]

* Peter Boy [29/09/2021 23:29] :
>  Any ideas to get it started to fly? 
The first step should be to empty the group in FAS and remove its
bugzilla account from component ownership in Bugzilla (I happen
to think that this is not a good idea in general but it's even worse
when the group has no active members).

The second step should be to document the current state of affairs
in the wiki along with the steps that someone would need to go through
to revive the group for another try. We could the point anyone who
wants to contribute to that page and get out of their way while they
fix things.

As an aside, I'm somewhat surprised that the only commit on the Java
SIG's main wiki page in nearly 4 years is one that simply fixes a
spelling mistake.  This doesn't jive with the amount of discussion we've
had on this list nor does it match the amount of work that people claim
to have done on the stack in recent times.

I would encourage people who want to restart the SIG to reach out to
other distributions and enquire as to how they handle their Java stack.
While I'm as much into Fedora exceptionalism as any other packager, I'm
certain that other distributions have the same problems packaging Java
that we do.  At worst, doing this would give us insight into how the
stack can be kept in working condition and, at best, we could gain
new contributers.

On that topic, I've just read an interview of Nicolas Lécureuil, the
president of the Mageia board, in which he says that Mageia's Java stack
is based on Fedora's and that he interacts with Fedora's Java team
(leading me to wonder who exactly he is interacting with given Fabio's
description of the SIG's activity in the opening mail of this thread). 

Emmanuel

[Neal Gompa]

On Wed, Sep 29, 2021 at 6:48 PM Emmanuel Seyman <emmanuel(a)seyman.fr&gt; wrote:
>  * Peter Boy [29/09/2021 23:29] :
>  >
>  > Any ideas to get it started to fly?
>
>  The first step should be to empty the group in FAS and remove its
>  bugzilla account from component ownership in Bugzilla (I happen
>  to think that this is not a good idea in general but it's even worse
>  when the group has no active members).
>
>  The second step should be to document the current state of affairs
>  in the wiki along with the steps that someone would need to go through
>  to revive the group for another try. We could the point anyone who
>  wants to contribute to that page and get out of their way while they
>  fix things.
>
>  As an aside, I'm somewhat surprised that the only commit on the Java
>  SIG's main wiki page in nearly 4 years is one that simply fixes a
>  spelling mistake.  This doesn't jive with the amount of discussion we've
>  had on this list nor does it match the amount of work that people claim
>  to have done on the stack in recent times.
>
>  I would encourage people who want to restart the SIG to reach out to
>  other distributions and enquire as to how they handle their Java stack.
>  While I'm as much into Fedora exceptionalism as any other packager, I'm
>  certain that other distributions have the same problems packaging Java
>  that we do.  At worst, doing this would give us insight into how the
>  stack can be kept in working condition and, at best, we could gain
>  new contributers.
>
>  On that topic, I've just read an interview of Nicolas Lécureuil, the
>  president of the Mageia board, in which he says that Mageia's Java stack
>  is based on Fedora's and that he interacts with Fedora's Java team
>  (leading me to wonder who exactly he is interacting with given Fabio's
>  description of the SIG's activity in the opening mail of this thread).
>  
I also wonder about openSUSE's Java team, since their packages are
*also* based on ours.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Mat Booth]

On Wed, 29 Sept 2021 at 23:48, Emmanuel Seyman <emmanuel(a)seyman.fr&gt; wrote:
>  * Peter Boy [29/09/2021 23:29] :
>  >
>  > Any ideas to get it started to fly?
>
>  The first step should be to empty the group in FAS and remove its
>  bugzilla account from component ownership in Bugzilla (I happen
>  to think that this is not a good idea in general but it's even worse
>  when the group has no active members).
>
>  The second step should be to document the current state of affairs
>  in the wiki along with the steps that someone would need to go through
>  to revive the group for another try. We could the point anyone who
>  wants to contribute to that page and get out of their way while they
>  fix things.
>
>  As an aside, I'm somewhat surprised that the only commit on the Java
>  SIG's main wiki page in nearly 4 years is one that simply fixes a
>  spelling mistake.  This doesn't jive with the amount of discussion we've
>  had on this list nor does it match the amount of work that people claim
>  to have done on the stack in recent times.
>
>  I would encourage people who want to restart the SIG to reach out to
>  other distributions and enquire as to how they handle their Java stack.
>  While I'm as much into Fedora exceptionalism as any other packager, I'm
>  certain that other distributions have the same problems packaging Java
>  that we do.  At worst, doing this would give us insight into how the
>  stack can be kept in working condition and, at best, we could gain
>  new contributers.
>
>  On that topic, I've just read an interview of Nicolas Lécureuil, the
>  president of the Mageia board, in which he says that Mageia's Java stack
>  is based on Fedora's and that he interacts with Fedora's Java team
>  (leading me to wonder who exactly he is interacting with given Fabio's
>  description of the SIG's activity in the opening mail of this thread).
>  
I've interacted with Java people from Mageia many times over the
years. They periodically rebase their stack on Fedora's and have been
pretty good at finding things that I didn't notice had stopped working
such as bootstapping modes that we don't exercise very often for
example. I've made a bunch of changes based on their reports and
merged a bunch of changes from them too, so kudos to them. They've
historically been active on #fedora-java IRC channel, so I'm sure I'm
not the only one with such interactions.


--
Mat Booth
http://fedoraproject.org/get-fedora

[Mat Booth]

On Thu, 30 Sept 2021 at 00:23, Mat Booth <fedora(a)matbooth.co.uk&gt; wrote:
>  On Wed, 29 Sept 2021 at 23:48, Emmanuel Seyman <emmanuel(a)seyman.fr&gt; wrote:
>  >
>  > * Peter Boy [29/09/2021 23:29] :
>  > >
>  > > Any ideas to get it started to fly?
>  >
>  > The first step should be to empty the group in FAS and remove its
>  > bugzilla account from component ownership in Bugzilla (I happen
>  > to think that this is not a good idea in general but it's even worse
>  > when the group has no active members).
>  >
>  > The second step should be to document the current state of affairs
>  > in the wiki along with the steps that someone would need to go through
>  > to revive the group for another try. We could the point anyone who
>  > wants to contribute to that page and get out of their way while they
>  > fix things.
>  >
>  > As an aside, I'm somewhat surprised that the only commit on the Java
>  > SIG's main wiki page in nearly 4 years is one that simply fixes a
>  > spelling mistake.  This doesn't jive with the amount of discussion we've
>  > had on this list nor does it match the amount of work that people claim
>  > to have done on the stack in recent times. 
I kind of hate this assumption that work only happens when SIGs are active.

I've been maintaining Java packages here for more than a decade, and
have seen SIGs come and go. The dormancy or not of a formal SIG has no
bearing at all on the amount of care that I have tried to give our
packages. And when discussions of revitalising the SIG inevitiably
appear, there's a thousand opinions about it from people who (a) are
not involved in Java packaging and (b) end up never *becoming*
involved in Java packaging. It's hard not to be cynical about such
sentiments.

[Kevin Kofler]

Stephen John Smoogen wrote:
>  I think Kevin's comment is meant more towards the way the
> language
>  packages itself versus the rpm packaging of the language. Going from
>  Kevin's comments on languages over the years, a 'good' language should
>  not require such sort of rebuilding. 
The OCaml language is to blame for a lot of issues. Still, there are also
issues I see in the RPM packaging (now that I know what those .cm* files
actually are), where it does not conform to best practices and/or to the
general packaging guidelines (which can be overridden by language-specific
ones, sure, but those exceptions are what I have a problem with):

* The main packages of libraries contain files that are only used for static
  linking (.cma files, i.e., "metadata for bytecode static linking" as
  Richard explained). Those main packages should actually contain only
  shared libraries and data files needed at runtime.

* No shared libraries (.so/.cmxs) are shipped for most libraries.

* Executables are not linked against those that are shipped.

That said, I agree that the Go and Rust packaging is worse.

        Kevin Kofler

[Kevin Kofler]

Robert Marcano via devel wrote:
>  Even in the case of SCM repositories committed binaries, allowing
>  bundling would help a lot, 
Well, we cannot allow just using the bundled binaries! There are various 
technical and legal concerns that make this a no go. But:

>  add some kind of automation that replace these jar for the proposed
> local
>  created maven repository, and link to them, and add the metadata to the
>  RPM to know it need to be rebuilt when that dependency is updated. 
that is fine (if you really replace ALL bundled JARs with versions built 
from source in Fedora), and as Fabio explained, we already have scripting 
for that.

But IMHO, you'll really want to replace the JARs with symlinks to the system 
versions *twice* in the build process: once before building (because you do 
not want to build against a bundled binary blob, which may or may not be 
compatible with the system version), and once after installing (because you 
want to ship symlinks rather than copies).

        Kevin Kofler

[Demi Marie Obenour]

On 9/28/21 8:41 AM, Stephen John Smoogen wrote:
>  On Tue, 28 Sept 2021 at 08:20, Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
> >
> > On Tue, Sep 28, 2021 at 02:06:58PM +0200, Kevin Kofler via devel wrote:
> >> Richard W.M. Jones wrote:
> >>> OCaml library code can in principle be dynamically linked, eg:
> >>>
> >>> $ rpm -ql ocaml-extlib | grep cmxs
> >>> /usr/lib64/ocaml/extlib/extLib.cmxs
> >>> $ file /usr/lib64/ocaml/extlib/extLib.cmxs
> >>> /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64,
> >>> version 1 (SYSV), dynamically linked,
> >>> BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info,
> >>> not stripped
> >>>
> >>> but upstream doesn't make it possible to ship OCaml binaries this way,
> >>> (they would still require rebuilding on every library update) and so
> >>> we only ship the DLLs not fully dynamically linked OCaml binaries
> >>> (except for the C code).
> >>
> >> Ah?
> >>
> >> So what sits in the main packages of libraries (e.g., in ocaml-facile as
> >> opposed to ocaml-facile-devel) then? Don't only shared libraries belong in
> >> the main package?
> >
> > The original split of ocaml-FOO / ocaml-FOO-devel doesn't make a lot
> > of sense these days.  Ideally we'd put them all in one package.
> >
> >> So I take back my comment that the OCaml stack is properly packaged. ;-)
> >> That sounds like almost as much of a mess as Go and Rust then.
> >
> > I'd hardly say OCaml packging is a mess.  It's much closer to the
> > spirit of C packaging than those others.  If you have *specific,
> > actionable* objections I will listen to them.
> >
> >
>  
>  I think Kevin's comment is meant more towards the way the language
>  packages itself versus the rpm packaging of the language. Going from
>  Kevin's comments on languages over the years, a 'good' language should
>  not require such sort of rebuilding. 
I believe (though I could be wrong) that *most* natively-compiled languages require
cascading rebuilds.  The only exceptions I am aware of are C, C++ (excluding
templates!), and Swift.  Haskell, OCaml, Rust, and Go all require cascading rebuilds;
I am not sure about Nim or Zig.

Providing a stable ABI requires major tradeoffs in a language implementation.
It prevents cross-module inlining and other optimizations, and is incompatible
with monomorphized generics (unless one takes the C++ route).  Furthermore,
ABI stability requires committing to the runtime representation of data types
and not changing it, even if these decisions prove to later be suboptimal.
Rust in particular has changed the way it represents structs by default to
improve packing of members.

Furthermore, in at least Rust and Haskell, `1 + 2` is actually a call to a
standard library routine.  If this is not inlined, performance will be abysmal.
Rust generics are basically C++ templates, in that code is generated for them
when they are instantiated, so ABI stability would require a commitment to
never changing the representation of `Vec` or `HashMap`.  That is not a
commitment that the Rust project has made yet.

Overall, I consider automated cascading rebuilds a far more feasible and realistic
path forward.  Arch already does cascading rebuilds of its Haskell packages,
for example, which shows that it can be done.

Sincerely,

Demi Marie Obenour (she/her/hers)

[Dan Čermák]

Neal Gompa <ngompa13(a)gmail.com&gt; writes:

> >
> > On that topic, I've just read an interview of Nicolas Lécureuil, the
> > president of the Mageia board, in which he says that Mageia's Java stack
> > is based on Fedora's and that he interacts with Fedora's Java team
> > (leading me to wonder who exactly he is interacting with given Fabio's
> > description of the SIG's activity in the opening mail of this thread).
> >
>
>  I also wonder about openSUSE's Java team, since their packages are
>  *also* based on ours. 
The openSUSE Java team is one overworked guy who managed to bootstrap
gradle 4 (iirc) a few years ago and now tries to put fires out whenever
there is little time.

We could try to coordinate & collaborate with him, but afaik neither
openSUSE has a ton of manpower when it comes to Java.


Cheers,

Dan

[Mikolaj Izdebski]

On Thu, Sep 30, 2021 at 1:25 AM Mat Booth <fedora(a)matbooth.co.uk&gt; wrote:
>  On Wed, 29 Sept 2021 at 23:48, Emmanuel Seyman <emmanuel(a)seyman.fr&gt; wrote:
>  > On that topic, I've just read an interview of Nicolas Lécureuil, the
>  > president of the Mageia board, in which he says that Mageia's Java stack
>  > is based on Fedora's and that he interacts with Fedora's Java team
>  > (leading me to wonder who exactly he is interacting with given Fabio's
>  > description of the SIG's activity in the opening mail of this thread).
>  >
>
>  I've interacted with Java people from Mageia many times over the
>  years. They periodically rebase their stack on Fedora's and have been
>  pretty good at finding things that I didn't notice had stopped working
>  such as bootstapping modes that we don't exercise very often for
>  example. I've made a bunch of changes based on their reports and
>  merged a bunch of changes from them too, so kudos to them. They've
>  historically been active on #fedora-java IRC channel, so I'm sure I'm
>  not the only one with such interactions. 
Likewise, I talked with Mageia Java maintainers, including Nicolas,
numerous times in the past couple years. I am happy to work with them
as relationship with Mageia brings value to Fedora for several
reasons, such as getting bugs/RFEs from them that help our packages to
be improved.

--
Mikolaj

>  --
>  Mat Booth
>  http://fedoraproject.org/get-fedora
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Mikolaj Izdebski]

On Mon, Sep 27, 2021 at 4:06 PM PGNet Dev <pgnet.dev(a)gmail.com&gt; wrote:
>  Many valid/interesting points being made.  Most of them sound, reasonably, like
> developer-/maintainer-centric issues.
>
>  Question: Is a primary goal of Fedora distro (JAVA sig, etc) to 'service' its
> (java app) users? 
There is no single primary goal of Java SIG.  The group consists of
individuals and sub-groups that have different focus or goals.

I think of Java packages as grouped into logical layers.  The lowest
first foundation layer is OpenJDK.  The second layer is Java RPM
tooling (with dependencies, the build systems) which enables
everything else, the third layer, to be built.  In other words,
OpenJDK with Maven/Ant/Javapackages/XMvn form a platform on which
other packages can be built.

I am mostly working within MBI sub-SIG that is working on
development and maintenance of the second layer - Java build systems
and RPM tooling for Java packaging.  The group has 2 goals:

1) We deliver, maintain and support Ant and Maven in Fedora.  Our aim
is to provide developers with the most popular Java build systems
which are reviewed, tested, and updated through the release lifecycle.

2) We design, develop and document tooling that enables anyone to
package Java software with a simple, efficient and scalable process.
We are also active members of Java SIG, collaborating on complex
changes and guiding new contributors.

The first goal is directed towards Fedora Linux users who want to
build any Java software, the second one towards anyone who wants
to package software they care about, but primarily towards Fedora contributors.
Maintenance of random Java libraries or apps is a non-goal for us.

From my PoV, all Fedora Java buildsystem packages (around 120 of them)
are in good shape, with only two known security bugs, no important or
critical security bugs, no FTBFS or FTI bugs.  I am actively triaging
all bugs reported and responding to pull requests opened.  Due to
recent CentOS Stream 9 development work we are behind on a couple of
updates, but we should process them in the next month or two.

--
Mikolaj Izdebski

>  If so, what's the current understanding of a user-driven ProductRequirements
> spec'n of JAVA apps 'round here?
>  Who's included in "users"? Developers? End-users? etc.
>  Perhaps I've missed it ...
>
>  I know as a representative of my end-users I've got plenty of opinions about our JAVA
> env.  Also as a representative of my org's JAVA devs.
>  But as a developer/maintainer OF java/apps @ Fedora, not much at all; the "solid
> OpenJDK & Maven" approach is good enuf here.  Mostly.
>
>  And, if that^ is not a primary goal, then back to the discussion at hand.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Mikolaj Izdebski]

On Wed, Sep 29, 2021 at 1:51 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  Since the @java-maint-sig group is esentially non-responsive, I
> suggest we do
>  the following: 
Thanks for making this distinction - @java-maint-sig group is not the
same as Java SIG.
Some of the most active members of Java SIG (like me or OpenJDK
maintainers) are not
(and never were) members of @java-maint-sig.

>  1) We remove all BZ assignee overrides to @java-maint-sig. This is a
> must.
>  2) We remove access of @java-maint-sig from all packages.
>  3) We ask the members of the group if they want to admin the list/BZ account.
>     3a) We give it to the volunteer.
>     3b) We empty the group and cancel the BZ account/list if nobody shows up.
>  4) We *don't orphan the packages*, they have some "de jure" maintainers.
+1 That is a good plan.

Several months ago I demoted @java-maint-sig from admin to committer
for all packages I am primary maintainer of, and I was considering
demoting it further to collaborator or ticket level, or removing
altogether as I my packages did not receive any contribution from the
group for the past months, except for a couple PRs that don't require
direct access to the packages.

--
Mikolaj Izdebski

>  The packages that fail to install and/or build will eventually die out due to
>  the existing processes.
>
>  --
>  Miro Hrončok
>  --
>  Phone: [phone]
>  IRC: mhroncok
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Fabio Valentini]

On Thu, Sep 30, 2021 at 11:17 AM Mikolaj Izdebski <mizdebsk(a)redhat.com&gt; wrote:
>  On Wed, Sep 29, 2021 at 1:51 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  > Since the @java-maint-sig group is esentially non-responsive, I suggest we do
>  > the following:
>
>  Thanks for making this distinction - @java-maint-sig group is not the
>  same as Java SIG.
>  Some of the most active members of Java SIG (like me or OpenJDK
>  maintainers) are not
>  (and never were) members of @java-maint-sig. 
That's true. The "old" Java SIG was never properly set up as a FAS
group. Its Wiki page has contained obsolete information for *years*,
and the list of members there hasn't been accurate for years, either.
On the other hand, you were explicitly welcome to join the newly set
up group, which you never bothered to do, since you were pretending
that Modularity will solve all of humanity's problems, and obviously
preferred to work alone, never offering help or feedback, unless
*maybe* when explicitly asked. Now that modules won't solve Java
packaging either, you're back, and bad-mouthing all the work the SIG
did while it was active to keep the shit from hitting the fan while
you were AWOL, which I find a bit rich.

I am sorry for having delayed this seeminly inevitable end for Java
packages in Fedora by three years.
It looks like the time and energy I invested into the effort of
keeping Java packages alive in Fedora were in vain.

This will be my *last* ML post on this topic. I will no longer
participate in any Java-related discussions, for the sake of my own
(mental and physical) health.

Goodbye.

> > 1) We remove all BZ assignee overrides to @java-maint-sig. This is a must.
> > 2) We remove access of @java-maint-sig from all packages.
> > 3) We ask the members of the group if they want to admin the list/BZ account.
> >    3a) We give it to the volunteer.
> >    3b) We empty the group and cancel the BZ account/list if nobody shows up.
> > 4) We *don't orphan the packages*, they have some "de jure"
maintainers.
>
> +1 That is a good plan.
>
> Several months ago I demoted @java-maint-sig from admin to committer
> for all packages I am primary maintainer of, and I was considering
> demoting it further to collaborator or ticket level, or removing
> altogether as I my packages did not receive any contribution from the
> group for the past months, except for a couple PRs that don't require
> direct access to the packages.
>
> --
> Mikolaj Izdebski
>
> >
> > The packages that fail to install and/or build will eventually die out due to
> > the existing processes.
> >
> > --
> > Miro Hrončok
> > --
> > Phone: [phone]
> > IRC: mhroncok
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> > Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
>

[Mikolaj Izdebski]

On Thu, Sep 30, 2021 at 12:13 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Thu, Sep 30, 2021 at 11:17 AM Mikolaj Izdebski <mizdebsk(a)redhat.com&gt; wrote:
>  >
>  > On Wed, Sep 29, 2021 at 1:51 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  > > Since the @java-maint-sig group is esentially non-responsive, I suggest we do
>  > > the following:
>  >
>  > Thanks for making this distinction - @java-maint-sig group is not the
>  > same as Java SIG.
>  > Some of the most active members of Java SIG (like me or OpenJDK
>  > maintainers) are not
>  > (and never were) members of @java-maint-sig.
>
>  That's true. The "old" Java SIG was never properly set up as a FAS
>  group. Its Wiki page has contained obsolete information for *years*,
>  and the list of members there hasn't been accurate for years, either. 
Java SIG is an informal group. By definition, SIGs are informal groups
within Fedora Project. Therefore there is no formal membership of Java
SIG. Anyone interested in contributing to make Java in Fedora better
can be considered a member of Java SIG.

>  On the other hand, you were explicitly welcome to join the newly set
>  up group, which you never bothered to do, since you were pretending 
@java-maint-sig evolved from Stewardship SIG, which was formed with a
goal of preventing unmaintained packages from being retired, which I
don't appreciate. My opinion is that retirement of unmaintained
packages is desired. I want Fedora Linux to be a high quality
distribution and I believe it's better to have fewer, but better
quality packages. This is the primary reason for me not joining
@java-maint-sig.

Besides that I'm not a big fan of collaborative package maintenance
groups such as @java-maint-sig. I prefer a model with a single primary
maintainer who owns the package, like a product owner - has the
authority to make technical decisions about the package. Similarly to
cathedral vs bazaar, both of which are valid software development
models.

>  that Modularity will solve all of humanity's problems, and
> obviously
>  preferred to work alone, never offering help or feedback, unless
>  *maybe* when explicitly asked. Now that modules won't solve Java 
I never claimed that modularity was perfect, nor that it was better
than traditional package maintenance. Modularity solves some important
problems, but introduces others.

From my PoV, the most important feature of modularity that I wanted to
take advantage of - building packages in a controlled, isolated
environment - is now implemented as Koji dynamic sidetags (BTW, I was
the original author of sidetag-koji-plugin). Another important feature
- private dependencies - is now solved by allowing bundling much more
freely and by exempting compat packages from the package review
process. Therefore I no longer see modularity as a good approach to
maintain default versions Maven and Ant - it could still be used for
alternative versions.

>  packaging either, you're back, and bad-mouthing all the work the
> SIG
>  did while it was active to keep the shit from hitting the fan while
>  you were AWOL, which I find a bit rich. 
I am back to maintaining non-modular Java packages because I want to
keep contributing to Fedora as a Java package maintainer and Fedora
engineering leadership decided that non-modular packages are strongly
preferred over modules. I don't disagree with that decision and I
respectfully obey it.

--
Mikolaj Izdebski

[Daniel P. Berrangé]

On Mon, Sep 27, 2021 at 09:35:23AM -0400, Stephen John Smoogen wrote:
>  In the end, we have never been able to keep a pool of people
>  interested in making Java work. We aren't the only ones as this
>  problem occurs in Debian also (and it occurs in other languages like
>  Ruby, JS, Python also). The people who want to volunteer time on the
>  language are more likely to work in an area where others interested in
>  the language are already there. Dealing with the vaguries of 40
>  different slightly different disk layouts, file permissions, and other
>  tools  from every distribution are grit in the shoe when you already
>  have a 'working layout' and have people who speak your language and
>  problems elsewhere. 
Yes, these observations are really key to sustainability problems
with language packaging.

For anything that is written in older vintage languages like C/C++
the value of the distro packaging is fairly unequivocal. There is
little-to-no support for package / dependancy management that comes
with the language toolchain as standard. Without the distro packages,
you are left doing all the hard work yourself to handle building and
install of native libraries you depend on. Both app developers and
users have self-interest in volunteering time as a distro maintainers
which benefits all parties.

For Java / Python / Go / Rust / etc, there are increasingly decent
package / dependancy management facilities that come as standard
with the language toolchain. Users turn to these standard tools
as their first choice, rather than the distros tools. So from the
POV of both application developers & users, distros are no longer
a critically important cog for helping users get the software built
+ installed. All they really need from the distro is the basic
language toolchain. In fact distros often just get in the way by
sucking in bug reports that then don't get seen by upstreams, or
by letting users run with un-tested combinations of dependancies.


It is easier to tell users "run go build and let it  download 
the dependancies" (replace with pip install, or whatever other
language tools fit), than to explain to people how to install
the distro packaged go code for dependancies, across all the
different Linux distros and non-Linux OS plaforms. Thus we
don't attract as many people into the packaging world and have
to rely on a smaller groups of heroic people to keep language
packages actively maintined. 

We're also getting squeezed by the increasing number of upstreams
directly building & shipping their deliverables to users, as
containers (whether docker/podman containers, or flatpaks), built
and tested in a controlled environment with CI systems integrated
into the git forges they use.

There are still valuable things done by distros of course, but it
is getting harder to demonstrate this value, in order to attract a
sufficient level of interest in package maint work :-(

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Stephen John Smoogen]

On Wed, 29 Sept 2021 at 18:49, Emmanuel Seyman <emmanuel(a)seyman.fr&gt; wrote:
>  
>  As an aside, I'm somewhat surprised that the only commit on the
> Java
>  SIG's main wiki page in nearly 4 years is one that simply fixes a
>  spelling mistake.  This doesn't jive with the amount of discussion we've
>  had on this list nor does it match the amount of work that people claim
>  to have done on the stack in recent times. 
Honestly I don't think checking the wiki for a SIGs work is any sign
of its work. The one thing I have seen taught to people in Fedora over
and over again is 'YOU NEVER TOUCH THE WIKI'. You change one thing and
you get someone yelling you broke all the translations, or that you
are an idiot for that word choice or quite a few other things, or you
play a game of ghost reversions where someone changes it back to what
was different and tell you 'its a wiki, I can do that.'  Or you spend
8 hours making a set of changes and then get a long 'well can you make
the layout a bit different, that hurts my eyes' from the other people
in the SIG. And finally, you are the new person so you are told by
every person who has had a bad experience or seen someone have a bad
experience to go make all these edits we have lined up but never done.
[Then get told, well that isn't what I would have done..]

Yes not all groups in Fedora are like this, but I have seen it happen
enough time to enough people to not judge wiki work as something
anyone does anymore.


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.

[Richard W.M. Jones]

On Tue, Sep 28, 2021 at 02:40:18PM -0400, Demi Marie Obenour wrote:
>  That said, I am also unsure if anyone is using those bindings.  Why
> were they
>  added originally? 
I think probably for oVirt, but oVirt now only uses the virt-* tools
(ie. command line).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

[Peter Boy]

We had a spirited and detailed discussion so far. But nevertheless,  I think we are none
the wiser at the moment. We have many informative contributions to the discussion and
analyses of the situation. 

However, we lack concepts on how to proceed after removing java-maint-sig. What
consequences do we draw from the analyses?

Emmanuel Seyman has made some suggestions, about 16 posts back.  Thoughts on those? I
posted on the java list some ideas some time ago ('Empowering Fedora Java’). Any
comments on those?



Peter

[Mat Booth]

On Mon, 4 Oct 2021 at 13:07, Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  We had a spirited and detailed discussion so far. But nevertheless,  I think we are none
> the wiser at the moment. We have many informative contributions to the discussion and
> analyses of the situation.
>
>  However, we lack concepts on how to proceed after removing java-maint-sig. What
> consequences do we draw from the analyses?
>
>  Emmanuel Seyman has made some suggestions, about 16 posts back.  Thoughts on those? I
> posted on the java list some ideas some time ago ('Empowering Fedora Java’). Any
> comments on those?
>
>
>  
Like many Open Source projects, Fedora is a "do-ocracy" -- those who
step up to do the work win the responsibility of getting it done. If
you have a clear goal in mind, just go for it.

As I said before there's always a lot of discussion from people who,
in the end, never get involved. And then there are people who are
quietly working away and Getting Things Done™ without the need for
endless discussion. A good example is Nicolas De Amicis who recently
stepped up to revive SWT because he really cares about openjfx in
Fedora and SWT was a dependency. And that is awesome; it is the
do-ocracy in action! Picking a goal you care about and setting about
achieving it doesn't require a SIG, it requires you to "do."

So, do you have any specific, concrete goal you want to achieve? If
the removal of a Java package has affected you directly or a Java
application you care about is in danger of being removed that would be
a excellent place to start.








--
Mat Booth
http://fedoraproject.org/get-fedora

[Mikolaj Izdebski]

On Mon, Oct 4, 2021 at 2:08 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  However, we lack concepts on how to proceed after removing
> java-maint-sig. What consequences do we draw from the analyses? 
The java-maint-sig formal group ceased to exist. Java SIG continues to
exist as an informal group, in the shape it existed before
java-maint-sig was formed. Anyone who wants to improve Java in Fedora
can simply do so. Eg. If you want to package something, you can do it.
If you need help, you can ask on IRC or mailing list. If you want to
test existing packages, feel free to do it and open bugs. If you want
to improve docs, just do it. And so on. Java SIG has resources in form
of communication channels that can be used by members to help each
other. There is a mailing list and an IRC channel. We can even
schedule an IRC meeting if anyone has a particular topic to discuss
during a meeting.

>  Emmanuel Seyman has made some suggestions, about 16 posts back. 
> Thoughts on those? 
I'm for removing java-maint-sig group and documenting the current
state of affairs. But I don't think there is a need to "restart Java
SIG" or to plan editing the wiki. Whoever wants to clean up some wiki
pages can simply do so, without asking.

>  I posted on the java list some ideas some time ago ('Empowering
> Fedora Java’). Any comments on those? 
These were about java-maint-sig, IIRC, which basically does not exist
any longer.

--
Mikolaj Izdebski


>  Peter
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Mikolaj Izdebski]

On Mon, Oct 4, 2021 at 3:08 PM Mat Booth <fedora(a)matbooth.co.uk&gt; wrote:
>  On Mon, 4 Oct 2021 at 13:07, Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  >
>  > We had a spirited and detailed discussion so far. But nevertheless,  I think we are
> none the wiser at the moment. We have many informative contributions to the discussion and
> analyses of the situation.
>  >
>  > However, we lack concepts on how to proceed after removing java-maint-sig. What
> consequences do we draw from the analyses?
>  >
>  > Emmanuel Seyman has made some suggestions, about 16 posts back.  Thoughts on those?
> I posted on the java list some ideas some time ago ('Empowering Fedora Java’). Any
> comments on those?
>  >
>  >
>  >
>
>  Like many Open Source projects, Fedora is a "do-ocracy" -- those who
>  step up to do the work win the responsibility of getting it done. If
>  you have a clear goal in mind, just go for it.
>
>  As I said before there's always a lot of discussion from people who,
>  in the end, never get involved. And then there are people who are
>  quietly working away and Getting Things Done™ without the need for
>  endless discussion. A good example is Nicolas De Amicis who recently
>  stepped up to revive SWT because he really cares about openjfx in
>  Fedora and SWT was a dependency. And that is awesome; it is the
>  do-ocracy in action! Picking a goal you care about and setting about
>  achieving it doesn't require a SIG, it requires you to "do."
>
>  So, do you have any specific, concrete goal you want to achieve? If
>  the removal of a Java package has affected you directly or a Java
>  application you care about is in danger of being removed that would be
>  a excellent place to start. 
I totally agree with Mat.

If you want to contribute, just do it. If you need help, feel free to
ask around.

--
Mikolaj Izdebski

>  --
>  Mat Booth
>  http://fedoraproject.org/get-fedora
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Eduard Lucena]

Hello,

I'm not a Fedora Maintainer, or packager, or developer. I was involved
more in marketing and more "people person"[1] stuff. I hope this can
close this thread.

This email has a specific goal, but it doesn't have a great title: For
starters, SIG can't die, because they aren't alive. Also the goal was
to announce that there aren't active members of @java-maint-sig, which
is ok, sometimes stuff like that happens in a community driven
project.

The problem is all the unnecessary words, and unnecessary responses in it.

On one side: Ok, no one is working towards the objective of the
@java-maint-sig, maybe someone later will pick it up, or simply it
will remain inactive, that's it. Some people are happy working more
freely without a heavy well organized structure, and it looks like the
Java SIG works this way.

On the other side: No need to be happy about something you don't like.
It's not working anymore. Some people need more formal structure and
it looks like the@java-maint-sig was working this way.

No need to interchange any word, no need to trash, minimize or insult
the work of any of the SIGs. I don't like Java, neither the language,
the way it works with the JVM and JDK and JRE, neither the company it
came from; but it's been around for 25 years and it probably will
continue for a long time; and people will come and go to maintain what
they need to work with it. Just please acknowledge that the
@java-maint-sig has no active members, and continue with your lifes.

Hope everyone is ok.

Best regards

[1] https://fedoraproject.org/wiki/Join#PeoplePerson

-- 
Eduard Lucena
Móvil: [phone]
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Matthew Miller]

On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>  I'm not sure what's the best solution, but I guess the number
> one
>  reason to have packages within the Fedora distribution is for a matter
>  of trust, if this is the case I would argue that a curated list of
>  maven packages served via a Fedora managed repository would be a
>  better investment. 
I'd love to see someone interested in this pursue this idea! I know we
talked about it as long ago as... Flock Prague... and probably before.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Fabio Valentini]

On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>  > I'm not sure what's the best solution, but I guess the number one
>  > reason to have packages within the Fedora distribution is for a matter
>  > of trust, if this is the case I would argue that a curated list of
>  > maven packages served via a Fedora managed repository would be a
>  > better investment.
>
>  I'd love to see someone interested in this pursue this idea! I know we
>  talked about it as long ago as... Flock Prague... and probably before. 
This approach will buy you *literally nothing* compared to how things
already work, assuming you don't advocate just redistributing binary
artifacts / JARs from Maven Central.

Given that assumption, JARs would still need to be built 1) from
source, in a 2) trusted environment, 3) against trusted dependencies,
as I don't think any other approach should be acceptable for content
distributed by the Fedora Project.

But then you're back to *exactly how Fedora packages for Java projects
already work* - only with the added complication that distributing
those build artifacts as plain JARs instead of RPMs now makes them
impossible to consume as dependencies from other RPM builds.

Fabio

[Peter Boy]

>  Am 04.10.2021 um 15:07 schrieb Mat Booth
> <fedora(a)matbooth.co.uk&gt;:
>  
>  Like many Open Source projects, Fedora is a "do-ocracy“ —  …. 
A nice phrase
with a decent connotation. And it’s true without doubt.

And at the same time it is also true, Fedora as many other Open Source projects is as well
about coordination and successful cooperation and communication. And when Debian
distribution got into rough waters decades ago it was not because of a lack of packaging
and "do-ocracy“, but of a lack of coordination and cooperation - just as an example.
Same is true for various Fedora sub-projects.

And by the way

>  As I said before there's always a lot of discussion from people
> who,
>  in the end, never get involved. ... 
your implicit advice for me to just take action instead of arguing is nice and welcome.
However, I have been doing this for quite some time, e.g. by igniting development of a
systematic and supported installation of Wildfly - albeit mainly as part of my commitment
to Fedora Server WG. Not via packaging - that was found to be practically unfeasible here
- but by alternative means. I invite you to support the effort with your knowledge and
experience, e.g. to find the optimal way to install the upstream binary (simply in /opt or
is there a better way of integration into Fedora Java runtime system, e.g. similar to
Tomcat split up to the different FSH subdirectories, or something else). 

The development of alternatives to rpm packaging was also one of the suggestions that came
up in this thread. 


>  … do-ocracy in action! Picking a goal you care about and setting
> about
>  achieving it doesn't require a SIG, it requires you to "do."
>  
>  So, do you have any specific, concrete goal you want to achieve? If
>  the removal of a Java package has affected you directly or a Java
>  application you care about is in danger of being removed that would be
>  a excellent place to start. 
Most of this thread was not about package x.y.z but about broader issues, such as
outdated/misleading documentation and information, disruptive and untrustworthy
development histories (failing one of the core values of Java), need for alternatives to
the current packaging process (e.g. "curated list“ as mentioned in a previous post),
etc. All this has an impact on the Fedora Java eco system. Unfortunately, an answer to
those issues cannot get worked out as a one-man show, I guess.


What else really interests me: The "java-maint-sig" will be removed soon. Then
you are really completely content with the Fedora Java world?  No change? No preferrable
improvement anywhere? 
  


Best
Peter



 



—
Dr. Peter Boy
Universität Bremen
Mary-Sommerville-Str. 5
28359 Bremen
Germany

pboy(a)uni-bremen.de
www.uni-bremen.de

————————————————

Are you looking for a web content management system for scientific research
organizations?
Have a look at http://www.scientificcms.org

[Peter Boy]

>  Am 04.10.2021 um 15:29 schrieb Mikolaj Izdebski
> <mizdebsk(a)redhat.com&gt;:
>  
>  On Mon, Oct 4, 2021 at 2:08 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
> > However, we lack concepts on how to proceed after removing java-maint-sig. What
> consequences do we draw from the analyses?
>  
>  … If you want
>  to improve docs, just do it. And so on. ...
>  ... or to plan editing the wiki. Whoever wants to clean up some wiki
>  pages can simply do so, without asking. 
It’s not as easy as you think of. That way you will end with the docs as Stephen Smoogen
described 4 posts back, just chaos and misinformation. You need  collaboration and
agreement (shared plan) from participants in all affected areas - including you as the
(main) developer of a core package (not writing text, but e.g check the concept, check
technical correctness and completeness). It simply doesn’t work the way you are
proposing.


> > I posted on the java list some ideas some time ago
> ('Empowering Fedora Java’). Any comments on those?
>  
>  These were about java-maint-sig, IIRC, which basically does not exist
>  any longer. 
No! It was about:
>  The biggest success is that with all the adversities in java
> packaging we have a stabilized Fedora Java core platform.
>  
>  The next urgent step, in my opinion, is to update and improve information materials and
> documentation, followed by a community building process based on it.
>  
>  
>  I can offer to do the writing. … 
followed by tentative ideas about details of
documentation. 

You wrote:
>  Java SIG has resources in form
>  of communication channels that can be used by members to help each
>  other. There is a mailing list and an IRC channel. 
So much for the theory, yes. I
would have appreciated even a tiny bit of it.



You are one of the developers without whose contributions the Fedora Java stack would
probably collapse in a short time.  I would really be interested in the same question as
to Mat: With java-paint-sig removed, are you really completely content with the Fedora
Java world?  No change? No improvement anywhere?

And just in case you see some preferable improvement anywhere, what do you think should be
done to promote and achieve this? 



Best
Peter

[Stephen John Smoogen]

On Tue, 5 Oct 2021 at 07:26, Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  > Am 04.10.2021 um 15:29 schrieb Mikolaj Izdebski <mizdebsk(a)redhat.com&gt;:
>  >
>  > On Mon, Oct 4, 2021 at 2:08 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  >> However, we lack concepts on how to proceed after removing java-maint-sig. What
> consequences do we draw from the analyses?
>  >
>  > … If you want
>  > to improve docs, just do it. And so on. ...
>  > ... or to plan editing the wiki. Whoever wants to clean up some wiki
>  > pages can simply do so, without asking.
>
>  It’s not as easy as you think of. That way you will end with the docs as Stephen Smoogen
> described 4 posts back, just chaos and misinformation. You need  collaboration and
> agreement (shared plan) from participants in all affected areas - including you as the
> (main) developer of a core package (not writing text, but e.g check the concept, check
> technical correctness and completeness). It simply doesn’t work the way you are proposing.
You also need people who are good at documentation which frankly many
developers are not. Be it a history of 'the only true documentation is
the code' to 'look its simple why didn't you just <do this one thing
no one would think of and impossible to document without knowing why
it was chosen or used>. It's the most obvious choice?'

It isn't that the developer is trying to be obtuse, I think it is how
the brain works for a lot of people. My autism makes it very hard for
me to communicate about code. I can think it, see it, dream it, but
once I get into 'word' mode I can't access it easily. And vice versa,
when I am in code mode, I am almost non-verbal and my emails get very
short and succinct (at least to me..).. Switch me over to word mode
and it takes me hours to be productive in code again. [I have to set
my emails and meetings in a block without working in much code.] My
social skills are also myopic.. I can work with people when I am in
word mode but I can not if I am in code mode beyond 'share code, get
reviewed, fix bugs, point out problems'.

It takes a lot of work to document what I do, and when I am under
water with too many tasks/packages it can be a lot easier to just make
it work versus doing that. I would like to say 'this is just me' but
when I have explained my problem to a lot of other developers there
are the nods of 'yep that is what it's like'. Getting a truly working
SIG together is a lot of emotional work that a lot of people don't
have the energy to deal with while also doing whatever they are
currently doing.

Getting documentation is a full time job usually with someone who has
to have patience and persistence to get the information they need out
of the developers in code mode and also get the words down into a way
that someone who isn't a developer in code mode can read.



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.

[Stephen Snow]

Hello,

(snip)
>  However, we lack concepts on how to proceed after removing java-
>  maint-sig. What consequences do we draw from the analyses?
>  
>  Emmanuel Seyman has made some suggestions, about 16 posts back. 
>  Thoughts on those? I posted on the java list some ideas some time ago
>  ('Empowering Fedora Java’). Any comments on those?
>   
I think the java-maint-sig should be shut down if it isn't actively
doing anything, and since the sentiment seems to be that there isn't a
real need for it. The only problem is I would be reluctant to offend
anyone who is a part of it by just arbitraily taking it down,
especially if they have been just quietly doing their part, and jsut
reluctant to talk about it for whatever reason.
>   
There are members of the comunity who have spoken up here that
are
actively contributing to java in Fedora Linux community.

So are the meetings being held with the java-sig? When are they? All of
us interested java community members should attend I think if we want
to offer an opinion or even just have something to say.

In my simple life and use of java, I find having a stable JDK and the
recent(ish) maven sufficient. Everything else is difficult to pin down
and I find alot of it is project dependant and changes based on that,
not based on the Distro I'm using. If I look at a commercially
available OS that is quite popular, they only package the JRE leaving
averything else up to the user WRT what they need for a dev stack. 

Just my 2c worth

Stephen
>   
> Peter
>   
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

[Stephen Snow]

>  (snip) 
>  You also need people who are good at documentation which frankly
> many
>  developers are not. Be it a history of 'the only true documentation
>  is
>  the code' to 'look its simple why didn't you just <do this one thing
>  no one would think of and impossible to document without knowing why
>  it was chosen or used>. It's the most obvious choice? 
Too true, I personally
have been doing systems integration goin on (oh
god) 35 yrs, and the last bit of work (you know tha documents that
prove you should get paid for the work) is the hardest for me. In fact
I have spent a considerable amount of foundation work over the years to
get templating and scripting in place for me to be able to automate as
much of my documentation as possible.
>  It isn't that the developer is trying to be obtuse, I think it is
> how
>  the brain works for a lot of people. My autism makes it very hard for
>  me to communicate about code. I can think it, see it, dream it, but
>  once I get into 'word' mode I can't access it easily. And vice versa,
>  when I am in code mode, I am almost non-verbal and my emails get very
>  short and succinct (at least to me..).. Switch me over to word mode
>  and it takes me hours to be productive in code again. [I have to set
>  my emails and meetings in a block without working in much code.] My
>  social skills are also myopic.. I can work with people when I am in
>  word mode but I can not if I am in code mode beyond 'share code, get
>  reviewed, fix bugs, point out problems'.
>   
Ditto, though I don't have to deal with an ASD, I stll find if I am at
the top of my technical game and really performing, then my
communication skills adjust to the berevity the thought mode enforces.

>  It takes a lot of work to document what I do, and when I am under
>  water with too many tasks/packages it can be a lot easier to just
>  make
>  it work versus doing that. I would like to say 'this is just me' but
>  when I have explained my problem to a lot of other developers there
>  are the nods of 'yep that is what it's like'. Getting a truly working
>  SIG together is a lot of emotional work that a lot of people don't
>  have the energy to deal with while also doing whatever they are
>  currently doing.
>   
Honestly, this is another area maybe the community is lacking in right
now, we don't seem to have as many "champions" taking the lead on
running things like a java-sig. It really does require some
organization skills and a marketing mindset.

>  Getting documentation is a full time job usually with someone who
> has
>  to have patience and persistence to get the information they need out
>  of the developers in code mode and also get the words down into a way
>  that someone who isn't a developer in code mode can read.
>   
As it has been revealed repeatedly, documentation is an ongoing and
ever demanding requirement that, since Fedora Linux release cadence is
what it is, and the changes that come every release cycle, ensure a
constant need and constant changes happening in those documents.

Stephen
>  
>  
>  -- 
>  Stephen J Smoogen.
>  I've seen things you people wouldn't believe. Flame wars in
>  sci.astro.orion. I have seen SPAM filters overload because of
>  Godwin's
>  Law. All those moments will be lost in time... like posts on a BBS...
>  time to shutdown -h now.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure

[Peter Boy]

>  Am 05.10.2021 um 14:56 schrieb Stephen Snow
> <s40w5s(a)gmail.com&gt;:
>  
>  Hello,
>  
>  (snip)
>  
>  So are the meetings being held with the java-sig? When are they? All of
>  us interested java community members should attend I think if we want
>  to offer an opinion or even just have something to say. 
If you search fedora calendar for java-sig you get an empty list. There is java-devel
mailing list which is a (very) „low traffic“ list.  



>  In my simple life and use of java, I find having a stable JDK and
> the
>  recent(ish) maven sufficient. Everything else is difficult to pin down
>  and I find alot of it is project dependant and changes based on that,
>  not based on the Distro I'm using. If I look at a commercially
>  available OS that is quite popular, they only package the JRE leaving
>  averything else up to the user WRT what they need for a dev stack. 
I use often what is probably „the other" commercially available OS. I’ve to download
everything including the JRE from third party sources and have to setup and maintain
everything myself. 

On Fedora, especially all my servers, I really appreciate that all of this is done for me
automatically, including notification and installation of updates - if a rpm is
available.


Peter

[Mat Booth]

On Tue, 5 Oct 2021 at 12:08, Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  Am 04.10.2021 um 15:07 schrieb Mat Booth <fedora(a)matbooth.co.uk&gt;:
>
>  Like many Open Source projects, Fedora is a "do-ocracy“ —  ….
>
>  A nice phrase with a decent connotation. And it’s true without doubt.
>
>  And at the same time it is also true, Fedora as many other Open Source projects is as
> well about coordination and successful cooperation and communication. And when Debian
> distribution got into rough waters decades ago it was not because of a lack of packaging
> and "do-ocracy“, but of a lack of coordination and cooperation - just as an example.
> Same is true for various Fedora sub-projects.
>
>  And by the way
>
>  As I said before there's always a lot of discussion from people who,
>  in the end, never get involved. ...
>
>
>  your implicit advice for me to just take action instead of arguing is nice and welcome.
> However, I have been doing this for quite some time, e.g. by igniting development of a
> systematic and supported installation of Wildfly - albeit mainly as part of my commitment
> to Fedora Server WG. Not via packaging - that was found to be practically unfeasible here
> - but by alternative means. I invite you to support the effort with your knowledge and
> experience, e.g. to find the optimal way to install the upstream binary (simply in /opt or
> is there a better way of integration into Fedora Java runtime system, e.g. similar to
> Tomcat split up to the different FSH subdirectories, or something else).
>  
Thanks for the invite, but I've never used Wildfly and have no
interest in contributing to Wildfly.


>  The development of alternatives to rpm packaging was also one of the
> suggestions that came up in this thread.
>  
Been there, done that, got the t-shirt. I used my knowledge and
experience to develop the flatpak distribution of Eclipse IDE as an
alternative to RPMs. Then we orphaned the RPMs in favour using Eclipse
as a flatpak application from Flathub. No-one stepped up to continue
maintenance of the RPM version so it went away. This is the proper
lifecycle of a RPM package; I won't be made to feel bad about that :-)


>  … do-ocracy in action! Picking a goal you care about and setting about
>  achieving it doesn't require a SIG, it requires you to "do."
>
>  So, do you have any specific, concrete goal you want to achieve? If
>  the removal of a Java package has affected you directly or a Java
>  application you care about is in danger of being removed that would be
>  a excellent place to start.
>
>
>  Most of this thread was not about package x.y.z but about broader issues, such as
> outdated/misleading documentation and information, disruptive and untrustworthy
> development histories (failing one of the core values of Java), need for alternatives to
> the current packaging process (e.g. "curated list“ as mentioned in a previous post),
> etc. All this has an impact on the Fedora Java eco system. Unfortunately, an answer to
> those issues cannot get worked out as a one-man show, I guess.
>
>
>  What else really interests me: The "java-maint-sig" will be removed soon. Then
> you are really completely content with the Fedora Java world?  No change? No preferrable
> improvement anywhere?
>
>  
Yes I'm content because I have everything I need: a well maintained
JDK and well maintained maven. I get my IDE from Flathub and my
libraries from Maven Central. I'm a programmer so my use-cases are
very basic.

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

>  Am 04.10.2021 um 21:08 schrieb Fabio Valentini
> <decathorpe(a)gmail.com&gt;:
>  
>  
>  But then you're back to *exactly how Fedora packages for Java projects
>  already work* - only with the added complication that distributing
>  those build artifacts as plain JARs instead of RPMs now makes them
>  impossible to consume as dependencies from other RPM builds. 
I think, the key is "via a Fedora managed repository“, something like a
fedora.maven.central. That could make the process easier. 

Somewhere I had read on "federated ....repository“ as a specific narrow defined
cooperation with distributions or projects with similar principles as Fedora.

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Colin Walters]

On Mon, Oct 4, 2021, at 3:08 PM, Fabio Valentini wrote:

>  But then you're back to *exactly how Fedora packages for Java
> projects
>  already work* - only with the added complication that distributing
>  those build artifacts as plain JARs instead of RPMs now makes them
>  impossible to consume as dependencies from other RPM builds. 
One needs to be a bit careful using the term "impossible" in software.
Some things, such as the halting problem have actually been proven impossible.
But this is not impossible =)  I use non-RPM things as part of building RPMs all the
time.
So do many other systems.

I think you instead mean e.g.: "would require our use of RPM to not be fully
self-hosting" or "would require some tooling to e.g. automatically generate RPMs
from external binaries" etc.
That's more of a policy question, far from impossible.

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Michal Srb]

Hi folks,

@Matthew Miller <mattdm(a)redhat.com&gt; Are you still trying to save Fedora
from packaging the ocean? :)

On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:

>  On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller
> <mattdm(a)fedoraproject.org&gt;
>  wrote:
>  >
>  > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>  > > I'm not sure what's the best solution, but I guess the number one
>  > > reason to have packages within the Fedora distribution is for a matter
>  > > of trust, if this is the case I would argue that a curated list of
>  > > maven packages served via a Fedora managed repository would be a
>  > > better investment.
>  >
>  > I'd love to see someone interested in this pursue this idea! I know we
>  > talked about it as long ago as... Flock Prague... and probably before.
>
>  This approach will buy you *literally nothing* compared to how things
>  already work, assuming you don't advocate just redistributing binary
>  artifacts / JARs from Maven Central.
>
>  Given that assumption, JARs would still need to be built 1) from
>  source, in a 2) trusted environment, 3) against trusted dependencies,
>  as I don't think any other approach should be acceptable for content
>  distributed by the Fedora Project.
>  
>  But then you're back to *exactly how Fedora packages for Java
> projects
>  already work* - only with the added complication that distributing
>  those build artifacts as plain JARs instead of RPMs now makes them
>  impossible to consume as dependencies from other RPM builds.
>  
I think it would actually make a huge difference.

Unlike RPM repositories, Maven repositories can easily hold multiple
versions of libraries. Once a JAR is built, the resulting bytecode will
work with current and future JVMs. There is no need to mass-rebuild JARs
every 6 months. And there is certainly no need to try to run every single
Java application with a single "system-wide" version of a library.

Fedora could ship just Java applications that would bundle JARs (whatever
version they need) from the Fedora Maven repository. I don't see this as a
problem, as long as it would be possible to track what JARs are bundled in
what application.

Fedora maintainers could then focus on maintaining applications, and not
maintaining a ton of individual libraries that nobody really cares about
that much.

Thanks,
Michal


>  Fabio
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Vít Ondruch]

Dne 06. 10. 21 v 7:08 Michal Srb napsal(a):
>  Hi folks,
>
>  @Matthew Miller <mailto:[e-mail]> Are you still trying to 
>  save Fedora from packaging the ocean? :)
>
>  On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini <decathorpe(a)gmail.com&gt; 
>  wrote:
>
>      On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller
>      <mattdm(a)fedoraproject.org&gt; wrote:
>      >
>      > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>      > > I'm not sure what's the best solution, but I guess the number one
>      > > reason to have packages within the Fedora distribution is for
>      a matter
>      > > of trust, if this is the case I would argue that a curated list of
>      > > maven packages served via a Fedora managed repository would be a
>      > > better investment.
>      >
>      > I'd love to see someone interested in this pursue this idea! I
>      know we
>      > talked about it as long ago as... Flock Prague... and probably
>      before.
>
>      This approach will buy you *literally nothing* compared to how things
>      already work, assuming you don't advocate just redistributing binary
>      artifacts / JARs from Maven Central.
>
>      Given that assumption, JARs would still need to be built 1) from
>      source, in a 2) trusted environment, 3) against trusted dependencies,
>      as I don't think any other approach should be acceptable for content
>      distributed by the Fedora Project.
>
>
>      But then you're back to *exactly how Fedora packages for Java projects
>      already work* - only with the added complication that distributing
>      those build artifacts as plain JARs instead of RPMs now makes them
>      impossible to consume as dependencies from other RPM builds.
>
>
>  I think it would actually make a huge difference.
>
>  Unlike RPM repositories, Maven repositories can easily hold multiple 
>  versions of libraries.
>  

RPM repositories can hold multiple version of libraries as well. This is 
self inflicted limitation of Fedora, because once you have multiple 
versions of libraries, you should also fix (security) bugs in those 
versions. And this is where it starts to be complicated.


Vít


>  Once a JAR is built, the resulting bytecode will work with current
> and 
>  future JVMs. There is no need to mass-rebuild JARs every 6 months. And 
>  there is certainly no need to try to run every single Java application 
>  with a single "system-wide" version of a library.
>
>  Fedora could ship just Java applications that would bundle JARs 
>  (whatever version they need) from the Fedora Maven repository. I don't 
>  see this as a problem, as long as it would be possible to track what 
>  JARs are bundled in what application.
>
>  Fedora maintainers could then focus on maintaining applications, and 
>  not maintaining a ton of individual libraries that nobody really cares 
>  about that much.
>
>  Thanks,
>  Michal
>
>
>      Fabio
>      _______________________________________________
>      devel mailing list -- devel(a)lists.fedoraproject.org
>      To unsubscribe send an email to devel-leave(a)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/[e-mail]
>      Do not reply to spam on the list, report it:
>      https://pagure.io/fedora-infrastructure
>
>
>  _______________________________________________
>  devel mailing list --devel(a)lists.fedoraproject.org
>  To unsubscribe send an email todevel-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure

[Miro Hrončok]

On 29. 09. 21 13:49, Miro Hrončok wrote:
>  On 26. 09. 21 21:20, Fabio Valentini wrote:
> > Should the @java-maint-sig group be removed from any packages it is
> > still associated with? Should it be dissolved, and members be removed?
> > Should the remaining ruins that used to be packages be orphaned?
> > Retired? Buried? Forgotten?
>  
>  Since many have moved this discussion away from this question, let me please 
>  bring back the main reason this was posted.
>  
>  Since the @java-maint-sig group is esentially non-responsive, I suggest we do 
>  the following:
>  
>  
>  1) We remove all BZ assignee overrides to @java-maint-sig. This is a must.
>  2) We remove access of @java-maint-sig from all packages.
>  3) We ask the members of the group if they want to admin the list/BZ account.
>     3a) We give it to the volunteer.
>     3b) We empty the group and cancel the BZ account/list if nobody shows up.
>  4) We *don't orphan the packages*, they have some "de jure" maintainers.
>  
>  The packages that fail to install and/or build will eventually die out due to 
>  the existing processes. 
https://pagure.io/fesco/issue/2672

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

>  Am 06.10.2021 um 07:08 schrieb Michal Srb <msrb(a)redhat.com
> <mailto:[e-mail]>>:
>  
>  Hi folks,
>  
>  @Matthew Miller Are you still trying to save Fedora from packaging the ocean? :)
>  
>  On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
> > 
> > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> >> I'm not sure what's the best solution, but I guess the number one
> >> reason to have packages within the Fedora distribution is for a matter
> >> of trust, if this is the case I would argue that a curated list of
> >> maven packages served via a Fedora managed repository would be a
> >> better investment.
> > 
> > I'd love to see someone interested in this pursue this idea! I know we
> > talked about it as long ago as... Flock Prague... and probably before.
>  
>  …..
>  
>  Fedora could ship just Java applications that would bundle JARs (whatever version they
> need) from the Fedora Maven repository. I don't see this as a problem, as long as it
> would be possible to track what JARs are bundled in what application.
>  
>  Fedora maintainers could then focus on maintaining applications, and not maintaining a
> ton of individual libraries that nobody really cares about that much. 
I've roughly thought this through with our Java Web CMS project (we don't
currently create Fedora rpm). I think with this idea the effort would be noticeably
reduced. A number of intermediate steps could be omitted. 

My main question: how can we get this going? 

Normally we would first need a concise description and then (try to) discuss it on
java-devel. 

Or is this a case of "do-ocracy“?

And who is able / willing to (co-)work?

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mat Booth]

On Wed, 6 Oct 2021 at 11:02, Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  Am 06.10.2021 um 07:08 schrieb Michal Srb <msrb(a)redhat.com&gt;:
>
>  Hi folks,
>
>  @Matthew Miller Are you still trying to save Fedora from packaging the ocean? :)
>
>  On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>
>
>  On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>
>  I'm not sure what's the best solution, but I guess the number one
>  reason to have packages within the Fedora distribution is for a matter
>  of trust, if this is the case I would argue that a curated list of
>  maven packages served via a Fedora managed repository would be a
>  better investment.
>
>
>  I'd love to see someone interested in this pursue this idea! I know we
>  talked about it as long ago as... Flock Prague... and probably before.
>
>
>  …..
>
>  Fedora could ship just Java applications that would bundle JARs (whatever version they
> need) from the Fedora Maven repository. I don't see this as a problem, as long as it
> would be possible to track what JARs are bundled in what application.
>
>  Fedora maintainers could then focus on maintaining applications, and not maintaining a
> ton of individual libraries that nobody really cares about that much.
>
>
>  I've roughly thought this through with our Java Web CMS project (we don't
> currently create Fedora rpm). I think with this idea the effort would be noticeably
> reduced. A number of intermediate steps could be omitted.
>
>  My main question: how can we get this going?
>
>  Normally we would first need a concise description and then (try to) discuss it on
> java-devel.
>
>  Or is this a case of "do-ocracy“?
>  
Yes ;-) I look forward to reading your proposal on java-devel.

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mikolaj Izdebski]

On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>  > I'm not sure what's the best solution, but I guess the number one
>  > reason to have packages within the Fedora distribution is for a matter
>  > of trust, if this is the case I would argue that a curated list of
>  > maven packages served via a Fedora managed repository would be a
>  > better investment.
>
>  I'd love to see someone interested in this pursue this idea! I know we
>  talked about it as long ago as... Flock Prague... and probably before. 
That's a very old idea that has been partially implemented years ago,
but never approved for use in Fedora. Maven artifacts can be built in
Koji (there is an existing "koji maven-build" command). Once built
they appear in a "curated" Maven repository hosted on Koji, that can
be synced to mirrors, from where users can consume it. Consumers of
this Maven repository don't need to be running Fedora, not even Linux.

Curated Maven repository contains additional metadata, eg. CVEs
affecting given artifact version, whether upstream is active, whether
given artifact is available in Fedora and in which releases, etc. For
each Fedora Linux release there is an auto-generated BOM (bill of
materials POM) listing artifacts available in the release.

Binaries from this trusted/curated Maven repository can also be
wrapped into RPMs (using "koji wrapper-rpm" command) and put into
distribution repos and composes. Other packages can depend on such
RPMs. This is a hybrid packaging model, where some Java RPM packages
can be built in the traditional way (where code is compiled during
rpmbuild) and some are built elsewhere, and only wrapped in RPMs.

--
Mikolaj Izdebski

>  --
>  Matthew Miller
>  <mattdm(a)fedoraproject.org&gt;
>  Fedora Project Leader
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Matthew Miller]

On Wed, Oct 06, 2021 at 07:08:46AM +0200, Michal Srb wrote:
>  @Matthew Miller <mattdm(a)redhat.com&gt; Are you still trying to
> save Fedora
>  from packaging the ocean? :) 
Oh, you remember. Yes. :)

Let's do what we do really well, really well, and not do things where we're
fighting against 99.9999% of all actual use both in dev and prod.



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Mikolaj Izdebski]

On Tue, Oct 5, 2021 at 1:27 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  > Am 04.10.2021 um 15:29 schrieb Mikolaj Izdebski <mizdebsk(a)redhat.com&gt;:
>  >
>  > On Mon, Oct 4, 2021 at 2:08 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  >> However, we lack concepts on how to proceed after removing java-maint-sig. What
> consequences do we draw from the analyses?
>  >
>  > … If you want
>  > to improve docs, just do it. And so on. ...
>  > ... or to plan editing the wiki. Whoever wants to clean up some wiki
>  > pages can simply do so, without asking.
>
>  It’s not as easy as you think of. That way you will end with the docs as Stephen Smoogen
> described 4 posts back, just chaos and misinformation. You need  collaboration and
> agreement (shared plan) from participants in all affected areas - including you as the
> (main) developer of a core package (not writing text, but e.g check the concept, check
> technical correctness and completeness). It simply doesn’t work the way you are proposing.
Sure, some major changes may indeed require planning or cooperation.
That's what we have the SIG and its communication channels for. For
example, if I wanted to rewrite Java documentation and move it from
the wiki to docs.fedoraproject.org at the same time, I would start
with sending a proposal to java-devel mailing list and ask for
feedback. We would discuss what should and what should not be
documented, who wants to document what and so on. Depending on how the
discussion goes there, I might propose an IRC meeting to ease the
discussion process.

>  >> I posted on the java list some ideas some time ago ('Empowering Fedora
> Java’). Any comments on those?
>  >
>  > These were about java-maint-sig, IIRC, which basically does not exist
>  > any longer.
>
>  No! It was about:
>  > The biggest success is that with all the adversities in java packaging we have a
> stabilized Fedora Java core platform. 
I'll re-read it then and try to reply.

>  >
>  > The next urgent step, in my opinion, is to update and improve information materials
> and documentation, followed by a community building process based on it.
>  >
>  >
>  > I can offer to do the writing. …
>  followed by tentative ideas about details of documentation.
>
>  You wrote:
>  > Java SIG has resources in form
>  > of communication channels that can be used by members to help each
>  > other. There is a mailing list and an IRC channel.
>  So much for the theory, yes. I would have appreciated even a tiny bit of it. 
I don't understand. These communication channels exist and are
functional. The most active Java packagers I know of are subscribed to
the mailing list and are present in the IRC channel. The fact that
there is not much ongoing communication is a different problem - I
find that people very often approach me directly or through other
channels, and many times I ask them to use public Java SIG channels
because that allows others to benefit from the conversation.

>  You are one of the developers without whose contributions the Fedora
> Java stack would probably collapse in a short time.  I would really be interested in the
> same question as to Mat: With java-paint-sig removed, are you really completely content
> with the Fedora Java world?  No change? No improvement anywhere? 
I'm happy with how Java SIG works in general - as an informal group
that does not limit packagers freedom, like by enforcing agile
processes, or mandating code review for every change. I like that Java
SIG doesn't have any authority to make any decisions - there can be
discussion, but ultimately each package owner makes decisions
regarding their own packages, within boundaries defined by Fedora
policies. The Fedora change process can be used when required - anyone
can propose a change, and once approved by FESCo, the package owner
must obey. I like that unmaintained packages are being removed from
distribution - with decreasing manpower in Java SIG I think it's
better to focus on fewer important packages.

For sure we should clean outdated Java SIG wiki pages - that's
relatively simple and I can do that myself. We should pay better
attention to announcing important changes that can affect others. We
can try regular IRC meetings instead of ad-hoc meetings. We could try
to come up with common goals for the SIG, but I'm not sure if that
will help. Right now I don't have any other ideas regarding improving
Java SIG organization.

Regarding Java content in Fedora Linux, there is a lot to improve, and
I have many ideas. I started writing them down as they come to my mind
and for each of them I'll start separate threads on java-devel list.

I also promise to document ongoing or planned projects that I am or
would like to be working on. Then anyone interested will be able to
more easily see what is going on, and possibly help with these
projects. Some of the projects that I have in mind:
Ongoing:
- MBI (Maven Bootstrap Initiative, an ability to build Maven and XMvn
fully from source from scratch, without reliance on pre-existing
binaries),
- Maven JDK bindings (ability to choose version of JDK used by Maven
at installation time),
- XMvn toolchains (ability to switch JDK used to build packages by
changing a single line of BuildRequires),
- embedded metadata for security scanners inside JARs (to reduce the
number of false-positives the scanners report),
- downstream patch tracking (similar to Debian DEP-3),
- updating Java packaging docs and moving them to docs.fedoraproject.org.
Planned or considered:
- redesign of auto-requires on JRE packages (bug 1993879),
- adding simple functional tests (smoke tests) for various packages,
- running upstream tests as gating tests (that allows running tests
that can't be ran during rpmbuild due to unpackaged dependencies),
- making use of gating and CI infrastructure to run generic Java tests
(that enforce packaging guidelines and bytecode version),
- browsable API documentation (javadocs extracted from RPMs and served
on a website),
- bringing back java-deptools (search engine for Java classes within
RPM packages that I used to host),
- updating Java Packaging HOWTO (writing missing sections, removing or
rewriting outdated parts).

>  And just in case you see some preferable improvement anywhere, what
> do you think should be done to promote and achieve this? 
I have no idea, other than doing the work myself and communicating
what I'm doing and why, hoping others will join the effort. I'm not
the best person to ask about promotion or community building.

--
Mikolaj Izdebski

>  Best
>  Peter
>
>
>
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Peter Boy]

>  Am 06.10.2021 um 17:04 schrieb Mikolaj Izdebski
> <mizdebsk(a)redhat.com&gt;:
>  
>  On Tue, Oct 5, 2021 at 1:27 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
> > 
> > 
> > 
> >> Am 04.10.2021 um 15:29 schrieb Mikolaj Izdebski <mizdebsk(a)redhat.com&gt;:
> >> 
> >> On Mon, Oct 4, 2021 at 2:08 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
> >>> However, we lack concepts on how to proceed after removing java-maint-sig.
> What consequences do we draw from the analyses?
> >> 
> >> … If you want
> >> to improve docs, just do it. And so on. ...
> >> ... or to plan editing the wiki. Whoever wants to clean up some wiki
> >> pages can simply do so, without asking.
> > 
> > It’s not as easy as you think of. That way you will end with the docs as Stephen
> Smoogen described 4 posts back, just chaos and misinformation. You need  collaboration and
> agreement (shared plan) from participants in all affected areas - including you as the
> (main) developer of a core package (not writing text, but e.g check the concept, check
> technical correctness and completeness). It simply doesn’t work the way you are
> proposing.
>  
>  Sure, some major changes may indeed require planning or cooperation.
>  That's what we have the SIG and its communication channels for. For
>  example, if I wanted to rewrite Java documentation and move it from
>  the wiki to docs.fedoraproject.org at the same time, I would start
>  with sending a proposal to java-devel mailing list and ask for
>  feedback. We would discuss what should and what should not be
>  documented, who wants to document what and so on. Depending on how the
>  discussion goes there, I might propose an IRC meeting to ease the
>  discussion process. 
Thanks. I will make some suggestions once I get through my current backlog (in about 2
weeks). Of course, I'm also willing to actually write texts then (and keep them up to
date).


> > You are one of the developers without whose contributions the
> Fedora Java stack would probably collapse in a short time.  I would really be interested
> in the same question as to Mat: With java-paint-sig removed, are you really completely
> content with the Fedora Java world?  No change? No improvement anywhere?
>  
>  I'm happy with how Java SIG works in general - as an informal group
>  that does not limit packagers freedom, like by enforcing agile
>  processes, or mandating code review for every change. I like that Java
>  SIG doesn't have any authority to make any decisions - there can be
>  discussion, but ultimately each package owner makes decisions
>  …...
>  I also promise to document ongoing or planned projects that I am or
>  would like to be working on. Then anyone interested will be able to
>  more easily see what is going on, and possibly help with these
>  projects. Some of the projects that I have in mind:
>  Ongoing:
>  - MBI (Maven Bootstrap Initiative, an ability to build Maven and XMvn
>  fully from source from scratch, without reliance on pre-existing
>  binaries),
>  - Maven JDK bindings (ability to choose version of JDK used by Maven
>  at installation time),
>  - XMvn toolchains (ability to switch JDK used to build packages by
>  changing a single line of BuildRequires),
>  - embedded metadata for security scanners inside JARs (to reduce the
>  number of false-positives the scanners report),
>  - downstream patch tracking (similar to Debian DEP-3),
>  - updating Java packaging docs and moving them to docs.fedoraproject.org.
>  Planned or considered:
>  - redesign of auto-requires on JRE packages (bug 1993879),
>  - adding simple functional tests (smoke tests) for various packages,
>  - running upstream tests as gating tests (that allows running tests
>  that can't be ran during rpmbuild due to unpackaged dependencies),
>  - making use of gating and CI infrastructure to run generic Java tests
>  (that enforce packaging guidelines and bytecode version),
>  - browsable API documentation (javadocs extracted from RPMs and served
>  on a website),
>  - bringing back java-deptools (search engine for Java classes within
>  RPM packages that I used to host),
>  - updating Java Packaging HOWTO (writing missing sections, removing or
>  rewriting outdated parts). 
Many thanks for that valuable information! Am very glad (and think it's important) to
read here such concrete and constructive perspectives alternatively to the posts that
(overly) point out the weak points (which also exist, as in any somewhat more complex
project) and that may spread a factually misleading message.  


> > And just in case you see some preferable improvement anywhere,
> what do you think should be done to promote and achieve this?
>  
>  I have no idea, other than doing the work myself and communicating
>  what I'm doing and why, hoping others will join the effort. I'm not
>  the best person to ask about promotion or community building. 
I hope I can help out here.


Peter


—
Dr. Peter Boy
Universität Bremen
Mary-Sommerville-Str. 5
28359 Bremen
Germany

pboy(a)uni-bremen.de
www.uni-bremen.de

————————————————

Are you looking for a web content management system for scientific research
organizations?
Have a look at http://www.scientificcms.org

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Kevin Kofler]

Michal Srb wrote:
>  Unlike RPM repositories, Maven repositories can easily hold multiple
>  versions of libraries. Once a JAR is built, the resulting bytecode will
>  work with current and future JVMs. There is no need to mass-rebuild JARs
>  every 6 months. And there is certainly no need to try to run every single
>  Java application with a single "system-wide" version of a library. 
And that is actually a problem rather than a solution. Maven artifacts are 
basically write once only. Everything depends on a hardcoded version which, 
once uploaded, is normally never touched again. This means that security 
bugs and other bugs never get fixed (unless the application bumps the 
dependency version, which can take months or years or even just never 
happen). That is exactly what the RPM system is designed to avoid.

>  Fedora could ship just Java applications that would bundle JARs
> (whatever
>  version they need) from the Fedora Maven repository. I don't see this as a
>  problem, as long as it would be possible to track what JARs are bundled in
>  what application. 
So you propose to bundle a whole bunch of JARs, some of which have been 
built many Fedora releases ago and might not even be buildable in any 
currently supported Fedora anymore? I think this would be not only a huge 
waste of space, but also a gigantic security nightmare.

        Kevin Kofler

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

>  Am 08.10.2021 um 02:06 schrieb Kevin Kofler via devel
> <devel(a)lists.fedoraproject.org&gt;:
>  
>  Michal Srb wrote:
> > Unlike RPM repositories, Maven repositories can easily hold multiple
> > versions of libraries. ...
>  
>  And that is actually a problem rather than a solution. Maven artifacts are 
>  basically write once only. Everything depends on a hardcoded version which, 
>  once uploaded, is normally never touched again. This means that security 
>  bugs and other bugs never get fixed ... 
A valid point, but only in case the app that consumes the maven artefact in unmaintained.


The goal of the "curated list“ is to make building an "app-rpm" less
burdensome and provide for more apps as rpm this way. And the updated „app-rpm“ would use
an updated version of that jar. And that app would be part of the usual rpm update
procedure.  



> > Fedora could ship just Java applications that would bundle JARs
> (whatever
> > version they need) from the Fedora Maven repository. I don't see this as a
> > problem, as long as it would be possible to track what JARs are bundled in
> > what application.
>  
>  So you propose to bundle a whole bunch of JARs, some of which have been 
>  built many Fedora releases ago and might not even be buildable in any 
>  currently supported Fedora anymore? 
No! See above.


>  I think this would be not only a huge 
>  waste of space 
given the current size of hard drive space, this really isn't a problem. You won't
be able to install a meaningful collection of apps whose cumulative footprint of jars
installed in parallel leaves any noticeable trace on a x tb disk. But you gain a lot in
security if as many of these apps as possible are managed as rpm.

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

>  Am 06.10.2021 um 14:37 schrieb Mikolaj Izdebski
> <mizdebsk(a)redhat.com&gt;:
>  
>  On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
> > 
> > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> >> I'm not sure what's the best solution, but I guess the number one
> >> reason to have packages within the Fedora distribution is for a matter
> >> of trust, if this is the case I would argue that a curated list of
> >> maven packages served via a Fedora managed repository would be a
> >> better investment.
> > 
> > I'd love to see someone interested in this pursue this idea! I know we
> > talked about it as long ago as... Flock Prague... and probably before.
>  
>  That's a very old idea that has been partially implemented years ago, 
That (and the following description) sounds great at first. 

>  but never approved for use in Fedora. 
Was the process not initiated or were there serious concerns? 

What would you recommend to do with it, discard, pursue, evaluate? 


Thanks
Peter

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mario Torre]

On Tue, Oct 5, 2021 at 10:20 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  > Am 04.10.2021 um 21:08 schrieb Fabio Valentini <decathorpe(a)gmail.com&gt;:
>  >
>  >
>  > But then you're back to *exactly how Fedora packages for Java projects
>  > already work* - only with the added complication that distributing
>  > those build artifacts as plain JARs instead of RPMs now makes them
>  > impossible to consume as dependencies from other RPM builds.
>
>  I think, the key is "via a Fedora managed repository“, something like a
> fedora.maven.central. That could make the process easier.
>
>  Somewhere I had read on "federated ....repository“ as a specific narrow defined
> cooperation with distributions or projects with similar principles as Fedora. 
Yes, also distributing jars via maven is a lot simpler than having to
package them (even if just wrapped) as RPM, so there's a lot of saving
just by that.

Those jars could be rebuilt from source, including their transitive
deps, or just a mirror of maven central if we trust the upstream (and
in many cases we do, i.e. for things coming from Eclipse.org or
Apache).

The infrastructure, I can't hardly think of this as an additional
burden, we have already hosted and built every single distribution
since the beginning of time, including those same jars in an RPM form.

Cheers,
Mario
-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mario Torre]

On Wed, Oct 6, 2021 at 2:39 PM Mikolaj Izdebski <mizdebsk(a)redhat.com&gt; wrote:
>  On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  >
>  > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>  > > I'm not sure what's the best solution, but I guess the number one
>  > > reason to have packages within the Fedora distribution is for a matter
>  > > of trust, if this is the case I would argue that a curated list of
>  > > maven packages served via a Fedora managed repository would be a
>  > > better investment.
>  >
>  > I'd love to see someone interested in this pursue this idea! I know we
>  > talked about it as long ago as... Flock Prague... and probably before.
>
>  That's a very old idea that has been partially implemented years ago,
>  but never approved for use in Fedora. Maven artifacts can be built in
>  Koji (there is an existing "koji maven-build" command). Once built
>  they appear in a "curated" Maven repository hosted on Koji, that can
>  be synced to mirrors, from where users can consume it. Consumers of
>  this Maven repository don't need to be running Fedora, not even Linux.
>
>  Curated Maven repository contains additional metadata, eg. CVEs
>  affecting given artifact version, whether upstream is active, whether
>  given artifact is available in Fedora and in which releases, etc. For
>  each Fedora Linux release there is an auto-generated BOM (bill of
>  materials POM) listing artifacts available in the release.
>
>  Binaries from this trusted/curated Maven repository can also be
>  wrapped into RPMs (using "koji wrapper-rpm" command) and put into
>  distribution repos and composes. Other packages can depend on such
>  RPMs. This is a hybrid packaging model, where some Java RPM packages
>  can be built in the traditional way (where code is compiled during
>  rpmbuild) and some are built elsewhere, and only wrapped in RPMs. 
So the only thing left to do is to convince Mr. Fedora to approve this ;)

Cheers,
Mario
-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mario Torre]

On Fri, Oct 8, 2021 at 2:11 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Michal Srb wrote:
>  > Unlike RPM repositories, Maven repositories can easily hold multiple
>  > versions of libraries. Once a JAR is built, the resulting bytecode will
>  > work with current and future JVMs. There is no need to mass-rebuild JARs
>  > every 6 months. And there is certainly no need to try to run every single
>  > Java application with a single "system-wide" version of a library.
>
>  And that is actually a problem rather than a solution. Maven artifacts are
>  basically write once only. Everything depends on a hardcoded version which,
>  once uploaded, is normally never touched again. This means that security
>  bugs and other bugs never get fixed (unless the application bumps the
>  dependency version, which can take months or years or even just never
>  happen). That is exactly what the RPM system is designed to avoid. 
Well, that's why it should be "curated" and not just a mirror of maven
central.

Cheers,
Mario

-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Kevin Kofler]

Peter Boy wrote:
>  A valid point, but only in case the app that consumes the maven
> artefact
>  in unmaintained. 
Many applications are maintained and never (or very rarely, only when they 
encounter some issue with the version they currently use) bother bumping 
their dependencies after adding them once. Especially in the corporate 
world, this is commonplace.

I wrote:
> > So you propose to bundle a whole bunch of JARs, some of which
> have been
> > built many Fedora releases ago and might not even be buildable in any
> > currently supported Fedora anymore? 
and Peter Boy replied: 
>  No! See above. 
Yet, that is exactly what "Once a JAR is built, the resulting bytecode will
work with current and future JVMs. There is no need to mass-rebuild JARs
every 6 months." (Michal Srb) implies.

> > I think this would be not only a huge
> > waste of space
>  
>  given the current size of hard drive space, this really isn't a problem.
>  You won't be able to install a meaningful collection of apps whose
>  cumulative footprint of jars installed in parallel leaves any noticeable
>  trace on a x tb disk. 
Considering that Fedora now also targets devices with as little as 16 or 32 
GB out-of-the-box storage:

https://fedoraproject.org/wiki/Architectures/ARM/PinePhone
https://wiki.pine64.org/index.php/PinePhone#Specifications

that argument is invalid.

>  But you gain a lot in security if as many of these
>  apps as possible are managed as rpm. 
Sure, a bunch of JARs in an RPM is marginally better than a bunch of JARs in 
a tarball. But it is no replacement for real packaging with unbundling.

        Kevin Kofler

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Kevin Kofler]

Mario Torre wrote:

>  On Fri, Oct 8, 2021 at 2:11 AM Kevin Kofler via devel wrote:
> > And that is actually a problem rather than a solution. Maven artifacts
> > are basically write once only. Everything depends on a hardcoded version
> > which, once uploaded, is normally never touched again. This means that
> > security bugs and other bugs never get fixed (unless the application
> > bumps the dependency version, which can take months or years or even just
> > never happen). That is exactly what the RPM system is designed to avoid.
>  
>  Well, that's why it should be "curated" and not just a mirror of maven
>  central. 
No amount of "curating" can fix this inherent design limitation of Maven. 
You cannot just replace foo-1.2.3 with a different version with security 
fixes, that opens all sorts of cans of worms (caching, reproducibility, 
changed checksums, etc.). So you need to upload something like foo-1.2.3.1 
and then bump the dependency in every single application. How is that any 
easier than just building against the latest foo to begin with?

        Kevin Kofler

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

>  Am 08.10.2021 um 14:08 schrieb Kevin Kofler via devel
> <devel(a)lists.fedoraproject.org&gt;:
>  
>  Peter Boy wrote:
> > A valid point, but only in case the app that consumes the maven artefact
> > in unmaintained.
>  
>  Many applications are maintained and never (or very rarely, only when they 
>  encounter some issue with the version they currently use) bother bumping 
>  their dependencies after adding them once. Especially in the corporate 
>  world, this is commonplace. 
Yes, unfortunately in case of security issues. But those people wouldn’t be amused either
if you silently exchanged a lib/jar.

As a Fedora rpm, the app will get rebuild about every 6 months. The „curated list“ as
proposed/implemented by Mikolaj keeps track of upstream maintenance and security issues
(at least it is constructed to be able to do as he described). So we can make a rebuild
fail if it uses a security tainted version instead of a newer one. 

That would be quite a broad hint. If someone ignores that, the problem is not one of jar
vs. rpm. 



> >> I think this would be not only a huge
> >> waste of space
> > 
> > given the current size of hard drive space, this really isn't a problem.
> > You won't be able to install a meaningful collection of apps whose
> > cumulative footprint of jars installed in parallel leaves any noticeable
> > trace on a x tb disk.
>  
>  Considering that Fedora now also targets devices with as little as 16 or 32 
>  GB out-of-the-box storage:
>  
>  https://fedoraproject.org/wiki/Architectures/ARM/PinePhone
>  https://wiki.pine64.org/index.php/PinePhone#Specifications
>  
>  that argument is invalid. 
Boxes with these storage limitation have usually other limitations as well and are not a
device to install a huge bunch of software. But even with 16g GB storage, what is a
typical size of jars? E.g. the set of log4j jars need about 2mb. You need a lot of jars
installed redundantly to flood 16 gb of storage. 

In theory you are right, but practically this will not be a problem in the vast majority
of cases.  

And in any case, it is better to have applications as rpm for a large number of typical
usage scenarios than no rpm version at all for anyone. 

All that under the assumption that said „curated list workflow“  will make it easier to
build a Java application rpm.

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Sérgio Basto]

On Wed, 2021-10-06 at 14:37 +0200, Mikolaj Izdebski wrote:
>  On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller <
>  mattdm(a)fedoraproject.org&gt; wrote:
>  > 
>  > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>  > > I'm not sure what's the best solution, but I guess the number one
>  > > reason to have packages within the Fedora distribution is for a
>  > > matter
>  > > of trust, if this is the case I would argue that a curated list of
>  > > maven packages served via a Fedora managed repository would be a
>  > > better investment.
>  > 
>  > I'd love to see someone interested in this pursue this idea! I know
>  > we
>  > talked about it as long ago as... Flock Prague... and probably
>  > before.
>  
>  That's a very old idea that has been partially implemented years ago,
>  but never approved for use in Fedora. Maven artifacts can be built in
>  Koji (there is an existing "koji maven-build" command). Once built
>  they appear in a "curated" Maven repository hosted on Koji, that can
>  be synced to mirrors, from where users can consume it. Consumers of
>  this Maven repository don't need to be running Fedora, not even Linux. 
ah Now I understand better this wiki page 
https://fedoraproject.org/wiki/KojiMavenSupport


>  Curated Maven repository contains additional metadata, eg. CVEs
>  affecting given artifact version, whether upstream is active, whether
>  given artifact is available in Fedora and in which releases, etc. For
>  each Fedora Linux release there is an auto-generated BOM (bill of
>  materials POM) listing artifacts available in the release.
>  
>  Binaries from this trusted/curated Maven repository can also be
>  wrapped into RPMs (using "koji wrapper-rpm" command) and put into
>  distribution repos and composes. Other packages can depend on such
>  RPMs. This is a hybrid packaging model, where some Java RPM packages
>  can be built in the traditional way (where code is compiled during
>  rpmbuild) and some are built elsewhere, and only wrapped in RPMs.
>  
>  --
>  Mikolaj Izdebski
>  
>  > 
>  > --
>  > Matthew Miller
>  > <mattdm(a)fedoraproject.org&gt;
>  > Fedora Project Leader
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  > Do not reply to spam on the list, report it: 
>  > https://pagure.io/fedora-infrastructure
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: 
>  https://pagure.io/fedora-infrastructure 
-- 
Sérgio M. B.

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

>  Am 08.10.2021 um 14:11 schrieb Kevin Kofler via devel
> <devel(a)lists.fedoraproject.org&gt;:
>  
>  Mario Torre wrote:
>  
> > On Fri, Oct 8, 2021 at 2:11 AM Kevin Kofler via devel wrote:
> >> And that is actually a problem rather than a solution. Maven artifacts
> >> are basically write once only. Everything depends on a hardcoded version
> >> which, once uploaded, is normally never touched again. This means that
> >> security bugs and other bugs never get fixed (unless the application
> >> bumps the dependency version, which can take months or years or even just
> >> never happen). That is exactly what the RPM system is designed to avoid.
> > 
> > Well, that's why it should be "curated" and not just a mirror of maven
> > central.
>  
>  No amount of "curating" can fix this inherent design limitation of Maven.
Maven may have a lot of design limitations, but this scenario is none of them. No build
system can completely compensate a careless developer or system administrator.

And what is the alternative? If we don't find a way to make building Java application
rpm easier, there will be no Fedora rpm for many applications at all. And then, what
happens? The sysadmin installs a binary from some source. And then happens exactly what
you fear: The program runs forever and  
>   that opens all sorts of cans of worms (caching, reproducibility, 
>  changed checksums, etc.). 

Peter

Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Matthew Miller]

On Fri, Oct 08, 2021 at 11:10:17AM +0200, Mario Torre wrote:
>  > RPMs. This is a hybrid packaging model, where some Java RPM
> packages
>  > can be built in the traditional way (where code is compiled during
>  > rpmbuild) and some are built elsewhere, and only wrapped in RPMs.
>  So the only thing left to do is to convince Mr. Fedora to approve this ;) 
Well, there's no magical "Mr. Fedora"... what needs to happen is someone
needs to make a proof of concept.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader