Re: Java Dev Group and Fedora Quality

[Andrew Haley]

On 1/29/20 3:15 PM, Alex Scheel wrote:

> I lump the Java SE platform into "roughly" what I was calling the JVM
> team. You're roughly the group that does what'd be the "core" work in
> other languages: maintains the compilers and the stdlib. My terminology
> there was incorrect; I suppose "JRE" is more correct.
>
> Is it correct to say that your team and immediate coworkers don't
> maintain say, the Apache libraries, the various build systems, IDEs,
> and the JBoss libraries?

Yes, it's exactly right. However, we (the Java SE team) are part of
the Red Hat Middleware division, who do indeed maintain the JBoss
libraries.

> My point is that some language SIGs/teams take a more active role in
> making sure a decent amount of non-stdlib software runs and is
> maintained by them. The "core" Java (JVM + JRE) team doesn't seem to
> engage in other places. Which is totally fine, from my PoV, as long
> as there is communication between the two parts and between the group
> and the wider Fedora community, and the overall experience is inclusive.

The issue here is as much about separation of concerns as anything
else. There's a limit to how much different stuff people can possibly
do, and we all have to draw the boundary somewhere. Of course we want
people to use Java, and to that end we ensure that it meets its
specification, performs well, and so on. One of the most important
things we do is maintain compatibility as much as we can, so that
packagers have a solid platform on which to build.

The wider Java community has created an amazing ecosystem of packages,
build tools, and so on. Some of these tools have, er, interesting
properties, and I think it's fair to say that the designers of Java
itself probably wouldn't have done it that way. However, such tools
are testament to the remarkable flexibility of the Java platform, and
in a way that flexibility is part of the problem.

> Instead, most of the library support falls to Joe's team, including
> Mikolaj. That's where most of the shortcomings in Java packaging are
> seen, including unfriendly, non-inclusive modularization policies.
> They're the ones that have orphaned large segments of packages, which
> ultimately lead to starting this mail thread. :-)

Even the word "modularization" is problematic here: I guess you mean
Fedora modules, not Java modules. Can you provide (or point me to) a
brief explanation of where Fedora's modularization policy conflicts
with Java's needs?

> Perhaps putting words in Bill's mouth here, but I don't subscribe any
> of his issues to the JRE team. They're mostly caused by issues in a
> lot of packages disappearing, and Matt Booth trying his best to clean
> up after that (with the help of Stewardship SIG). But we're all busy
> folks and sometimes we can handle that new package load and sometimes
> we can't.

Sure, I get that. There is inevitable tension between Red Hat's desire
to make Fedora a true community effort and the fact that sometimes
packaging is hard, and so needs full-time attention. This is
especially because of tools things like Maven, where the design of Maven
and Fedora packaging seem sometimes to be diametrically opposed. I
don't know enough about this to suggest a solution, but I am sure it
is a hard problem.

> And yes, you do a lot of great work in other places too. I thank you
> for that the few times I need to touch Java on non-Linux platforms. :-)
>
> Keep up the good work,

Thanks!

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Alex Scheel]

- Original Message -
> From: "Stephen John Smoogen" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, January 29, 2020 8:47:46 AM
> Subject: Re: Java Dev Group and Fedora Quality
> 
> On Wed, 29 Jan 2020 at 05:14, Andrew Haley  wrote:
> >
> > On 1/27/20 3:13 PM, Alex Scheel wrote:
> > > N.B.: I'd like to thank the Red Hat JVM team for being solid in
> > > their Fedora execution. But they maintain only the JVM, and not
> > > the rest of the Java ecosystem. :-)
> >
> > Thank you.
> >
> > One (perhaps) rather minor point in the middle of this important
> > discussion: there is no "Red Hat JVM team." We're responsible for the
> > entire base Java (SE) platform, that is to say the VM and the
> > surrounding Java libraries.
> >
> > Also, we're not just responsible for RHEL and Fedora: our team and our
> > partners in a few other organizations are responsible for all OpenJDK
> > updates for 7, 8, and 11, everywhere, not just GNU and Linux. Which is
> > to say, apart from Oracle's proprietary customers, most of the Java in
> > the world.
> >
> 
> The issue is that people (developers, users, maintainers) lump the
> entire ecosystem together.. so yes you maintain that but why don't you
> also maintain all the java packages which sit on that platform so it
> is 'useful' to them. [Yes the question is one of scope, time and
> resources.. but to a lot of people it needs clear explanations in the
> same way that people will take their Ford to a Toyoto autoshop because
> 'its a car, you should be able to fix it']

Right Andrew: Stephen was drawing the distinction I was trying to make.
I lump the Java SE platform into "roughly" what I was calling the JVM
team. You're roughly the group that does what'd be the "core" work in
other languages: maintains the compilers and the stdlib. My terminology
there was incorrect; I suppose "JRE" is more correct.

Is it correct to say that your team and immediate coworkers don't
maintain say, the Apache libraries, the various build systems, IDEs,
and the JBoss libraries? 

My point is that some language SIGs/teams take a more active role in
making sure a decent amount of non-stdlib software runs and is
maintained by them. The "core" Java (JVM + JRE) team doesn't seem to
engage in other places. Which is totally fine, from my PoV, as long
as there is communication between the two parts and between the group
and the wider Fedora community, and the overall experience is inclusive.


Instead, most of the library support falls to Joe's team, including
Mikolaj. That's where most of the shortcomings in Java packaging are
seen, including unfriendly, non-inclusive modularization policies.
They're the ones that have orphaned large segments of packages, which
ultimately lead to starting this mail thread. :-)

Perhaps putting words in Bill's mouth here, but I don't subscribe any
of his issues to the JRE team. They're mostly caused by issues in a
lot of packages disappearing, and Matt Booth trying his best to clean
up after that (with the help of Stewardship SIG). But we're all busy
folks and sometimes we can handle that new package load and sometimes
we can't.


And yes, you do a lot of great work in other places too. I thank you
for that the few times I need to touch Java on non-Linux platforms. :-)


Keep up the good work,

- Alex

> 
> 
> 
> --
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Stephen John Smoogen]

On Wed, 29 Jan 2020 at 05:14, Andrew Haley  wrote:
>
> On 1/27/20 3:13 PM, Alex Scheel wrote:
> > N.B.: I'd like to thank the Red Hat JVM team for being solid in
> > their Fedora execution. But they maintain only the JVM, and not
> > the rest of the Java ecosystem. :-)
>
> Thank you.
>
> One (perhaps) rather minor point in the middle of this important
> discussion: there is no "Red Hat JVM team." We're responsible for the
> entire base Java (SE) platform, that is to say the VM and the
> surrounding Java libraries.
>
> Also, we're not just responsible for RHEL and Fedora: our team and our
> partners in a few other organizations are responsible for all OpenJDK
> updates for 7, 8, and 11, everywhere, not just GNU and Linux. Which is
> to say, apart from Oracle's proprietary customers, most of the Java in
> the world.
>

The issue is that people (developers, users, maintainers) lump the
entire ecosystem together.. so yes you maintain that but why don't you
also maintain all the java packages which sit on that platform so it
is 'useful' to them. [Yes the question is one of scope, time and
resources.. but to a lot of people it needs clear explanations in the
same way that people will take their Ford to a Toyoto autoshop because
'its a car, you should be able to fix it']



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

 That's one of the big reasons I like Red Hat. You guys rock!  :-)

On Wednesday, January 29, 2020, 5:14:18 AM EST, Andrew Haley 
 wrote:  
 
 On 1/27/20 3:13 PM, Alex Scheel wrote:
> N.B.: I'd like to thank the Red Hat JVM team for being solid in
> their Fedora execution. But they maintain only the JVM, and not
> the rest of the Java ecosystem. :-)

Thank you.

One (perhaps) rather minor point in the middle of this important
discussion: there is no "Red Hat JVM team." We're responsible for the
entire base Java (SE) platform, that is to say the VM and the
surrounding Java libraries.

Also, we're not just responsible for RHEL and Fedora: our team and our
partners in a few other organizations are responsible for all OpenJDK
updates for 7, 8, and 11, everywhere, not just GNU and Linux. Which is
to say, apart from Oracle's proprietary customers, most of the Java in
the world.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Andrew Haley]

On 1/27/20 3:13 PM, Alex Scheel wrote:
> N.B.: I'd like to thank the Red Hat JVM team for being solid in
> their Fedora execution. But they maintain only the JVM, and not
> the rest of the Java ecosystem. :-)

Thank you.

One (perhaps) rather minor point in the middle of this important
discussion: there is no "Red Hat JVM team." We're responsible for the
entire base Java (SE) platform, that is to say the VM and the
surrounding Java libraries.

Also, we're not just responsible for RHEL and Fedora: our team and our
partners in a few other organizations are responsible for all OpenJDK
updates for 7, 8, and 11, everywhere, not just GNU and Linux. Which is
to say, apart from Oracle's proprietary customers, most of the Java in
the world.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Mikolaj Izdebski]

On Tue, Jan 28, 2020 at 12:18 AM Neal Gompa  wrote:
> Honestly, the correct thing is to make it so the maven to RPM
> interface is as transparent as possible. We've done a reasonably good
> job with this in Rust, Ruby, and Python, and the situation is (slowly)
> improving in Go. But nobody has sat down and looked at what we have in
> RPM today and taken a fresh look at how Java packaging *could* work. I
[...]
> Riffing off what Florian had for his DevConf.cz talk title,
> JPackage/RPM Java is basically packaging like it's 1999. The rest of
> the ecosystems are moving forward. Java has not. And I think that's
> where a lot of the pain exists.

That is not true. Java packaging in Fedora has been improved a lot
over the past years. In the last few years we have automated or
improved many things, such as:
- removal of post/postun scriptlets for Maven metadata generation,
- auto-requires/provides for Maven and OSGi artifacts,
- versioned auto-requires on JRE/JDK,
- macros for POM editing,
- integration with various build systems, incl. Maven, Tycho, Gradle, Ivy,
- automatic documentation (javadoc) generation,
- javadoc subpackage generation,
- buildrequires generation during build,
- auto buildrequires (with mock plugin),
and many more

> But without interest or investment from the Java stack packagers at
> Red Hat, there's basically no way to get a redesign of Java packaging
> done, much less even on the table.

I don't see any need for total redesign of Java packaging, but if
anyone wants to do it, you can count on me to participate in that
effort. Likewise, I'm interested in making smaller improvements to the
current design.

If anyone has any requests or suggestions for improvements to Java
packaging, you can write to java-devel list or open issue at
https://github.com/fedora-java/javapackages/issues

--
Mikolaj Izdebski
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

That is a very helpful explanation. I do have a lot of repos configured but 
most are necessary. Some are now added by gnome-software.

_copr_phracek-PyCharm.repo   fedora-updates.repo  
rpmfusion-nonfree-nvidia-driver.repo
dropbox.repo fedora-updates-testing-modular.repo  
rpmfusion-nonfree.repo
fedora-cisco-openh264.repo   fedora-updates-testing.repo  
rpmfusion-nonfree-steam.repo
fedora-modular.repo  google-chrome.repo   
rpmfusion-nonfree-updates.repo
fedora.repo  rpmfusion-free.repo  
rpmfusion-nonfree-updates-testing.repo
fedora-spotify.repo  rpmfusion-free-updates.repo
fedora-updates-modular.repo  rpmfusion-free-updates-testing.repo

I added these to /etc/dnf/dnf.conf based on googling;
max_parallel_downloads=10
ip_resolve=4
keepcache=true
deltarpm=true


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Neal Gompa]

On Mon, Jan 27, 2020 at 1:44 PM Mario Torre  wrote:
>
> On Mon, Jan 27, 2020 at 7:11 PM Robbie Harwood  wrote:
>
> > Java packaging being extremely difficult is not a Fedora-specific
> > problem.  The modularity effects are, but the packaging has been
> > known-hard for a very long time in many distros (and even outside a
> > distro context, it's not fun to work with the Java package managers).
>
> Distribution of java libraries and sometime applications is a problem
> that the Java community has solved (arguably with mixed results and
> not completely) with the use of maven, and most of the de-facto
> standard solutions evolve around some use of maven for deployment and
> shipping of the dependencies required to run and build end
> applications.
>
> Fedora, for some reason that may have been understandable 15 years ago
> but that clearly show the sign of time and the drawbacks decided to go
> through a different form of distribution and instead of embracing
> maven as a native tool for java packages has wrapped everything around
> RPM, because this was how the rest was distributed. Of course, this
> made sense as I said, you want to have one way central way and one
> tool with one familiar interface to build up your distribution and OS,
> but in hindsight I can't help thinking that it would have been better
> to teach RPM about maven instead, after all xmvn is just an hack to do
> exactly that.
>
> There are a few things that can be done to improve this situation
> going forward, some of those ideas may include things like dropping
> RPM packages completely, use flatpaks, create a properly audited
> deployment channel similar to what maven central does but more
> controlled and closed world, etc...
>

Honestly, the correct thing is to make it so the maven to RPM
interface is as transparent as possible. We've done a reasonably good
job with this in Rust, Ruby, and Python, and the situation is (slowly)
improving in Go. But nobody has sat down and looked at what we have in
RPM today and taken a fresh look at how Java packaging *could* work. I
think you underestimate the value of having Java components shipped as
RPMs, but I'm not surprised, as you've probably never had to actually
be forced to audit the usage of Java components in various
applications and justify them. It's a lot easier to do when the
components are de-duplicated and used in a meaningfully uniform
manner. Also, RPM distribution is loads easier than dealing with the
disaster that is private Maven repositories.

Riffing off what Florian had for his DevConf.cz talk title,
JPackage/RPM Java is basically packaging like it's 1999. The rest of
the ecosystems are moving forward. Java has not. And I think that's
where a lot of the pain exists.

But without interest or investment from the Java stack packagers at
Red Hat, there's basically no way to get a redesign of Java packaging
done, much less even on the table.




-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Przemek Klosowski via devel]

On 1/26/20 5:33 PM, Bill Chatfield via devel wrote:

When I type "sudo dnf install something" it takes about 10 minutes to pull 
updates from every repository, every time I run dnf. The actual install or update 
proceeds at a reasonable pace. I wouldn't call it fast. I could send you a video of this 
if you'd like. I see this on all my machines and I see other people complaining about it 
too.

In contrast, if I type "sudo apt install something" on Ubuntu or Debian, a 
bunch of text goes by really fast and BAM, it's done...


How many repositories do you use (dnf repolist)? One trap I repeatedly 
fall in is to enable a special-purpose repo which then falls into 
disrepair or disappears---but yum still gets bogged down accessing it.


Historically, the Fedora/RedHat/Centos ecosystem evolved to have a great 
many repositories: Fedora, rpmfusion-free/nonfree, base/EPEL/extras for 
Centos, RHEL/EPEL for RedHat. This is a headache for everyone who 
manages a heterogeneous collection of computers, and often results in 
slow and often unpredictable operation because of so many combinations 
of the instantaneous mirroring situation. The reason for that was 
sometimes political (Fedora Free vs non-free repositories), sometimes 
business-related (RedHat repos are only available to subscribers) and 
sometimes technical/historical/other (EPEL vs extras).


In contrast, Debian has a simple repository scheme, and I think their 
packaging system uses less metadata, resulting in fast operation. One 
frustrating aspect of yum/dnf is that often it takes significant time to 
download the metadata updates, just to find out that there are no 
package updates to apply.


I think people have been discussing ideas for more granular and faster 
metadata updates, but it's a hairy problem due to a lot of history and 
backward compatibility issues.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Fabio Valentini]

On Mon, Jan 27, 2020 at 6:01 PM Mario Torre  wrote:
>
> On Mon, Jan 27, 2020 at 5:28 PM Robbie Harwood  wrote:
>
> > > You would not expect a GCC devroom to be concerned about the problems
> > > of all packages written in C and C++, so why would Java be any
> > > different?
> >
> > Honestly?  I totally would expect that.  Wouldn't that be better for
> > everyone?
> >
> > Compilers aren't special here: every package that wishes to continue to
> > have users *needs* to care about those users.  Maintenance and features
> > need to be tailored to actual use cases.  Otherwise, it's a waste of
> > time, and just further irritates said users.
>
> That's not the place for such discussions, this is not a problem that
> is general to Java (and wouldn't be general to the C or C++ languages
> in the case of the GCC example above), is specific to Fedora and even
> more specific to some of the packages and needs to be addressed within
> the Fedora community. If there are problems that leak upstream in
> terms of patching requirements the maintainers (and perhaps the
> package users) have the duty to carry this work, you can't expect the
> rest of the world to discuss those issues during a developer
> conference dedicated to the programming language and its development,
> even when there is a mild overlap in interest because some of the
> involved people are the same, and neither you can draw conclusions on
> the interests of the Red Hat Java leadership based on the schedule
> alone.
>
> To get back on topic, I don't have the feeling that the java packaging
> is so dismantled, and I use java packages from RHEL and Fedora often,
> but I do know there's a series of problems with some of the packages,
> and I understand from this thread that some of the issues stem from
> the decision to use modules (sorry, I don't make the rules here, and
> while I also don't understand why modules are such a hot topic I can't
> help on the merit). Now, a constructive discussion would go toward
> suggestions on how to fix those problems not focus on pointless
> deliberation on what or how the Java DevRoom should be run and whether
> it should transform into a Fedora Java Packaging DevRoom.

(snip)

> So, what are your suggestions, and what can we do to help?
>

You want to know how to help improve the Java stack in fedora?

Well, the Stewardship SIG is now basically the home of the RPM Java
stack, minus eclipse.
But we've been working together with mbooth to get eclipse into shape, as well.

So you can look at our tracking project to see what we're working on:
https://pagure.io/stewardship-sig/

There's some reports that I generate daily, which contain package
dependency information, open pull requests, and update backlogs:
- report: https://decathorpe.fedorapeople.org/stewardship-sig.html
- pull requests: https://decathorpe.fedorapeople.org/stewardship-sig-prs.html
- update backlogs:
https://decathorpe.fedorapeople.org/stewardship-sig-stats.html

There's also a spreadsheet for a "birds-eye view" of the packages we
maintain (which is most Java packages):
https://docs.google.com/spreadsheets/d/11RlwsEs-LJgTOrUD1P4LpsvW9icVQrvrU5RFqxUuccY/edit?usp=sharing

If anybody wants to help with Java packaging, these would be the
places where I would start:
- review our open Pull Requests,
- file Pull Requests for missing package updates,
- report issues with broken packages.

Keep in mind that we're only interested in non-modular Java packages.
Mikolaj is working on his Java modules, and sometimes we can benefit
from work he's already done there, but mostly the two ways of
packaging things have just diverged (since Mikolaj doesn't care about
non-modular packages anymore, and we don't want to futz around with
shiny Modularity).

If we get some people who are interested in keeping the Java stack in
fedora working, maybe we can even get the Java SIG off the ground
again.
The first step in that direction would be to delete the old and
outdated wiki page and start fresh ...

Fabio

PS: I don't even find Java packaging to be that difficult - unless
upstreams decide to do weird shit with maven - which you then have to
exorcise with XPATH voodoo. Or even better, if they hosted their
sources in SVN on Java.net or Google Code. :D

> Cheers,
> Mario
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH 
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 

Re: Java Dev Group and Fedora Quality

[Emmanuel Seyman]

* Bill Chatfield via devel [26/01/2020 22:33] :
>
> I don't know if the problem is dnf or a library, but it is a serious problem.

There are several issues here:

- Different servers will transmit repository metadata at different speeds
  and you need to factor these out when trying to find bottleneck in the
  client-side code.
- dnf handles more stuff than apt. For instance, perl packages have virtual
  provides in the form of 'perl($MODULE)' for every perl module in the
  package.  This allows users to install a given module without caring
  what package it is in. Last I checked, apt had no equivalent.

Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Mario Torre]

On Mon, Jan 27, 2020 at 7:11 PM Robbie Harwood  wrote:

> Java packaging being extremely difficult is not a Fedora-specific
> problem.  The modularity effects are, but the packaging has been
> known-hard for a very long time in many distros (and even outside a
> distro context, it's not fun to work with the Java package managers).

Distribution of java libraries and sometime applications is a problem
that the Java community has solved (arguably with mixed results and
not completely) with the use of maven, and most of the de-facto
standard solutions evolve around some use of maven for deployment and
shipping of the dependencies required to run and build end
applications.

Fedora, for some reason that may have been understandable 15 years ago
but that clearly show the sign of time and the drawbacks decided to go
through a different form of distribution and instead of embracing
maven as a native tool for java packages has wrapped everything around
RPM, because this was how the rest was distributed. Of course, this
made sense as I said, you want to have one way central way and one
tool with one familiar interface to build up your distribution and OS,
but in hindsight I can't help thinking that it would have been better
to teach RPM about maven instead, after all xmvn is just an hack to do
exactly that.

There are a few things that can be done to improve this situation
going forward, some of those ideas may include things like dropping
RPM packages completely, use flatpaks, create a properly audited
deployment channel similar to what maven central does but more
controlled and closed world, etc...

Yes, I can see how this sort of discussion would be interesting to
have during the devroom because it's definitely beyond just Fedora,
and I'm sure there will be also some discussion about that on the side
like always, but overall specific issues should be discussed where
they matter, so any issues specific to RPM packaging of Eclipse won't
really find its way in the Java DevRoom (but I know the Eclipse
developers would be happy to discuss some of those problems during/in
between their DevRoom:
https://fosdem.org/2020/schedule/track/free_tools_and_editors/ if you
happen to be there).

> > and neither you can draw conclusions on the interests of the Red Hat
> > Java leadership based on the schedule alone.
>
> (For what it's worth, I'm not interested in doing that which is why I
> trimmed the email the way I did, though I know Nicolas was.)

Acknowledged.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Robbie Harwood]

tMario Torre  writes:

> On Mon, Jan 27, 2020 at 5:28 PM Robbie Harwood  wrote:
>
>>> You would not expect a GCC devroom to be concerned about the
>>> problems of all packages written in C and C++, so why would Java be
>>> any different?
>>
>> Honestly?  I totally would expect that.  Wouldn't that be better for
>> everyone?
>>
>> Compilers aren't special here: every package that wishes to continue
>> to have users *needs* to care about those users.  Maintenance and
>> features need to be tailored to actual use cases.  Otherwise, it's a
>> waste of time, and just further irritates said users.
>
> That's not the place for such discussions, this is not a problem that
> is general to Java (and wouldn't be general to the C or C++ languages
> in the case of the GCC example above), is specific to Fedora

Java packaging being extremely difficult is not a Fedora-specific
problem.  The modularity effects are, but the packaging has been
known-hard for a very long time in many distros (and even outside a
distro context, it's not fun to work with the Java package managers).

> and even more specific to some of the packages and needs to be
> addressed within the Fedora community. If there are problems that leak
> upstream in terms of patching requirements the maintainers (and
> perhaps the package users) have the duty to carry this work, you can't
> expect the rest of the world to discuss those issues during a
> developer conference dedicated to the programming language and its
> development, even when there is a mild overlap in interest because
> some of the involved people are the same,

I think that the language and its packaging are too intertwined to be
separated like that.  Look at what python does (or any number of other
languages like it such as rust) - package building and dependencies go
through the same body (the PEP system) as everything else in the
language.  It's not left without attempting to be solved.

But I don't think we will come to agreement on this.

> and neither you can draw conclusions on the interests of the Red Hat
> Java leadership based on the schedule alone.

(For what it's worth, I'm not interested in doing that which is why I
trimmed the email the way I did, though I know Nicolas was.)

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Mario Torre]

On Mon, Jan 27, 2020 at 5:28 PM Robbie Harwood  wrote:

> > You would not expect a GCC devroom to be concerned about the problems
> > of all packages written in C and C++, so why would Java be any
> > different?
>
> Honestly?  I totally would expect that.  Wouldn't that be better for
> everyone?
>
> Compilers aren't special here: every package that wishes to continue to
> have users *needs* to care about those users.  Maintenance and features
> need to be tailored to actual use cases.  Otherwise, it's a waste of
> time, and just further irritates said users.

That's not the place for such discussions, this is not a problem that
is general to Java (and wouldn't be general to the C or C++ languages
in the case of the GCC example above), is specific to Fedora and even
more specific to some of the packages and needs to be addressed within
the Fedora community. If there are problems that leak upstream in
terms of patching requirements the maintainers (and perhaps the
package users) have the duty to carry this work, you can't expect the
rest of the world to discuss those issues during a developer
conference dedicated to the programming language and its development,
even when there is a mild overlap in interest because some of the
involved people are the same, and neither you can draw conclusions on
the interests of the Red Hat Java leadership based on the schedule
alone.

To get back on topic, I don't have the feeling that the java packaging
is so dismantled, and I use java packages from RHEL and Fedora often,
but I do know there's a series of problems with some of the packages,
and I understand from this thread that some of the issues stem from
the decision to use modules (sorry, I don't make the rules here, and
while I also don't understand why modules are such a hot topic I can't
help on the merit). Now, a constructive discussion would go toward
suggestions on how to fix those problems not focus on pointless
deliberation on what or how the Java DevRoom should be run and whether
it should transform into a Fedora Java Packaging DevRoom.

So, what are your suggestions, and what can we do to help?

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Robbie Harwood]

Andrew Haley  writes:

> On 1/26/20 11:52 AM, Nicolas Mailhot wrote:
>> Le dimanche 26 janvier 2020 à 10:10 +, Andrew Haley a écrit :
>>> On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote:
>>>
 Java has been in a terminal course in Fedora for a year at
 least. You can see how much Red Hat Java leadership cares about the
 situation by consulting next week’s Java dev room schedule. Red Hat
 is co- organisator of this dev room
 https://fosdem.org/2020/schedule/track/free_java/
>>>
>>> Okay, I'll bite. I am part of the Red Hat Java leadership.
>>>
>>> I'm pleased with this year's FOSDEM schedule. People have submitted
>>> a lot of interesting-looking talks, and I expect it'll be a good
>>> day. I take it that you don't approve of this list, but I don't know
>>> what it is you don't like about it.
>>
>> I was just pointing out that devroom schedules reflect the interests
>> and priorities of the people organizing the devroom. And that those
>> interests and priorities do not include Java getting in such a state
>> that all the Fedora maintainers quit, major apps no loner work, and
>> users are migrating elsewhere.
>
> You would not expect a GCC devroom to be concerned about the problems
> of all packages written in C and C++, so why would Java be any
> different?

Honestly?  I totally would expect that.  Wouldn't that be better for
everyone?

Compilers aren't special here: every package that wishes to continue to
have users *needs* to care about those users.  Maintenance and features
need to be tailored to actual use cases.  Otherwise, it's a waste of
time, and just further irritates said users.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Nicolas Mailhot via devel]

Le 2020-01-27 15:46, Mario Torre a écrit :


You keep ignoring that a large part of the packaged ecosystem comes
from different places and is maintained by different people,


That’s why coordination conferences like the FOSDEM exist.


and not everything is in a state of chaos as you imply


Others described the current state of Java packaging here. If you 
disagree with those descriptions, by all means correct them.


--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Alex Scheel]

- Original Message -
> From: "Tom Seewald" 
> To: devel@lists.fedoraproject.org
> Sent: Sunday, January 26, 2020 12:35:32 PM
> Subject: Re: Java Dev Group and Fedora Quality
> 
> > On Sat, Jan 25, 2020 at 11:07 PM Bill Chatfield via devel
> *snip*
> > True. Nobody cares about Java packages in fedora, not even Red Hat
> > employees. If you look at the members of the Java SIG, a lot of them
> > were (or still are) Red Hat employees. For example, even JBoss /
> > WildFly (a pretty big Java project by Red Hat) was unmaintained and
> > broken, and most of it has now been removed from future fedora
> > releases. I wonder what they are going to do with RHEL 9 - maybe
> > somebody notices their stuff isn't available on fedora anymore.
> 
> Do you happen to know what the Red Hat employees who maintain Java-based
> products use as their desktop OS? RHEL? macOS?

As a Hatter, I'm proud to say that I--and most all of my team--use
Fedora for our work machines. I run F31 without modular repos on all
four of my boxes in my home office.

I work on Dogtag PKI (https://www.dogtagpki.org), a private CA, built
on top of a Tomcat/Java stack.


Responding to the JBoss dismissal: JBoss is its own product and doesn't
have the goal of shipping on Fedora before it ships in its own product.
All of the JBoss packages maintained in Fedora are maintained by the
community (including non-JBoss Red Hatters) who need them in other
packages.

Concretely, if you'd like to see more JBoss packages, join us in the
Stewardship SIG and collaborate to revive the ones you care
about. :-)


- Alex


N.B.: I'd like to thank the Red Hat JVM team for being solid in
their Fedora execution. But they maintain only the JVM, and not
the rest of the Java ecosystem. :-)

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Mario Torre]

On Mon, Jan 27, 2020 at 3:32 PM Nicolas Mailhot
 wrote:

> When a community driven conference grows to the size and reach of FOSDEM
> yes you can infer quite a lot from its schedule (one could do the same,
> removing the community word, for things where community is not relevant;
> that’s how half the IT press gets written).

The Devroom only runs for barely a day and there's so much stuff to
discuss we can't really cover everything and nobody submitted a talk
about this topic so it wasn't even considered, but next year you are
fully welcomed to submit one if you want.

> > Also, it may help knowing that packaging of Java application and
> > packaging of OpenJDK are different aspects and not necessarily handled
> > by the same people.
>
> “someone else’s problem” is little different from “I don’t care” in my
> book. And so far, no one has been able to identify those mysterious
> someone elses.

You keep ignoring that a large part of the packaged ecosystem comes
from different places and is maintained by different people, and not
everything is in a state of chaos as you imply, and definitely is not
ignored or "someone else's problem".

But, well... I'm not even sure why I keep replying, trolling with
unconstructive sentences won't really bring us anywhere.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Nicolas Mailhot via devel]

Le 2020-01-27 15:13, Mario Torre a écrit :

On Sun, Jan 26, 2020 at 12:53 PM Nicolas Mailhot via devel
 wrote:


Le dimanche 26 janvier 2020 à 10:10 +, Andrew Haley a écrit :
> On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote:
>
> > Java has been in a terminal course in Fedora for a year at
> > least. You can see how much Red Hat Java leadership cares about the
> > situation by consulting next week’s Java dev room schedule. Red Hat
> > is co- organisator of this dev room
> > https://fosdem.org/2020/schedule/track/free_java/
>
> Okay, I'll bite. I am part of the Red Hat Java leadership.
>
> I'm pleased with this year's FOSDEM schedule. People have submitted a
> lot of interesting-looking talks, and I expect it'll be a good day. I
> take it that you don't approve of this list, but I don't know what it
> is you don't like about it.

I was just pointing out that devroom schedules reflect the interests
and priorities of the people organizing the devroom. And that those
interests and priorities do not include Java getting in such a state
that all the Fedora maintainers quit, major apps no loner work, and
users are migrating elsewhere.

It’s not for me to approve or disapprove. People can draw their own
conclusions.


Eh!!??

Nicholas, I'm not sure how you infer all this by the schedule of a
Community driven conference!


When a community driven conference grows to the size and reach of FOSDEM 
yes you can infer quite a lot from its schedule (one could do the same, 
removing the community word, for things where community is not relevant; 
that’s how half the IT press gets written).



Also, it may help knowing that packaging of Java application and
packaging of OpenJDK are different aspects and not necessarily handled
by the same people.


“someone else’s problem” is little different from “I don’t care” in my 
book. And so far, no one has been able to identify those mysterious 
someone elses.


--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Mario Torre]

On Sun, Jan 26, 2020 at 12:53 PM Nicolas Mailhot via devel
 wrote:
>
> Le dimanche 26 janvier 2020 à 10:10 +, Andrew Haley a écrit :
> > On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote:
> >
> > > Java has been in a terminal course in Fedora for a year at
> > > least. You can see how much Red Hat Java leadership cares about the
> > > situation by consulting next week’s Java dev room schedule. Red Hat
> > > is co- organisator of this dev room
> > > https://fosdem.org/2020/schedule/track/free_java/
> >
> > Okay, I'll bite. I am part of the Red Hat Java leadership.
> >
> > I'm pleased with this year's FOSDEM schedule. People have submitted a
> > lot of interesting-looking talks, and I expect it'll be a good day. I
> > take it that you don't approve of this list, but I don't know what it
> > is you don't like about it.
>
> I was just pointing out that devroom schedules reflect the interests
> and priorities of the people organizing the devroom. And that those
> interests and priorities do not include Java getting in such a state
> that all the Fedora maintainers quit, major apps no loner work, and
> users are migrating elsewhere.
>
> It’s not for me to approve or disapprove. People can draw their own
> conclusions.

Eh!!??

Nicholas, I'm not sure how you infer all this by the schedule of a
Community driven conference!

Also, it may help knowing that packaging of Java application and
packaging of OpenJDK are different aspects and not necessarily handled
by the same people.

Cheers,
Mario

> Regards,
>
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Nicolas Mailhot via devel]

Le 2020-01-27 10:52, Andrew Haley a écrit :


You would not expect a GCC devroom to be concerned about the problems
of all packages written in C and C++, so why would Java be any
different?


I would expect a GCC devroom to be concerned about the problems of all
packages written in C and C++ once it reached the general failure state
that Java exhibits today in Fedora (and, hopefully, before).

Problem children happen in all languages and are not a language issue.
General failure specific to a language is something else entirely. It
does not happen at the individual app level. It happens at the
tooling/culture/general priorities level.


The packaging of programs which depend on Java is somewhat outside
my remit. Having said that, I am interested to discover why Java
packaging in Fedora is particularly dysfunctional.


If you haven’t followed the story there are many people on the list
that can explain you in detail what happened (both the people that
quit Java packaging side, and the people who’ve been trying to keep
the ship from sinking completely since).

To keep the story short, the rift between the expectations of Java
developers and Java tooling and the needs of the people deploying
Java software in Fedora, reached such a level, that people trying
to bridge this rift burnt out one after the other and were not
replaced.

Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Tom Hughes]

On 27/01/2020 12:01, Adam Williamson wrote:


I don't know in detail how apt works, but IIRC (sorry if I'm wrong), in
a previous discussion of this it's been suggested that the difference
is apt doesn't refresh this data unless you explicitly ask it to, while
dnf does automatically refresh it on most operations, depending on a
refresh time specified in the repository configuration (this is several
days for mostly-not-changing repos, but more like a few minutes or
hours for update repos which change frequently).


Yes update (refresh metadata) and upgrade (update packages) are
separate operations with apt.

Even the updates repository has a 6 hour refresh interval in F31 though
so it shouldn't have to refresh every time - the base repository has
a 7 day refresh interval.

A refresh initially only checks the top level repomd.xml though, which
is tiny - it will only carry on and fetch other things if they appear to
have changed.

I wonder if Bill is running dnf as a normal user rather than as root
so that it is using a per-user metadata cache that will have to be
created if it doesn't exist yet. Running as root, even for operations
like list that don't really need it, is generally better as it can
use the shared system cache.

You should be able to use --cacheonly to stop it refreshing, or indeed
use --refresh to force a refresh. Using --cacheonly will also make it
use the system cache even when running as a normal user.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Adam Williamson]

On Sun, 2020-01-26 at 22:33 +, Bill Chatfield via devel wrote:
> > That's not really fair. DNF is pretty much only the user interface,
> > and everything it's built on top of (hawkey, librepo, libsolv) is
> > implemented in C / C++. And when I think back to using yum, dnf is
> > really fast :)
> 
> When I type "sudo dnf install something" it takes about 10 minutes to
> pull updates from every repository, every time I run dnf. The actual
> install or update proceeds at a reasonable pace. I wouldn't call it
> fast. I could send you a video of this if you'd like. I see this on
> all my machines and I see other people complaining about it too.

It's refreshing the repository metadata, which is mostly a network-
bound operation and has little to do with the efficiency of the code.

I don't know in detail how apt works, but IIRC (sorry if I'm wrong), in
a previous discussion of this it's been suggested that the difference
is apt doesn't refresh this data unless you explicitly ask it to, while
dnf does automatically refresh it on most operations, depending on a
refresh time specified in the repository configuration (this is several
days for mostly-not-changing repos, but more like a few minutes or
hours for update repos which change frequently).

I believe there's been some discussion of ways the size of the metadata
could be reduced, but that is a question of the overall design of the
system, it's not to do with the quality of the code that implements the
design.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Andrew Haley]

On 1/26/20 11:52 AM, Nicolas Mailhot wrote:
> Le dimanche 26 janvier 2020 à 10:10 +, Andrew Haley a écrit :
>> On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote:
>>
>>> Java has been in a terminal course in Fedora for a year at
>>> least. You can see how much Red Hat Java leadership cares about the
>>> situation by consulting next week’s Java dev room schedule. Red Hat
>>> is co- organisator of this dev room
>>> https://fosdem.org/2020/schedule/track/free_java/
>>
>> Okay, I'll bite. I am part of the Red Hat Java leadership.
>>
>> I'm pleased with this year's FOSDEM schedule. People have submitted a
>> lot of interesting-looking talks, and I expect it'll be a good day. I
>> take it that you don't approve of this list, but I don't know what it
>> is you don't like about it.
>
> I was just pointing out that devroom schedules reflect the interests
> and priorities of the people organizing the devroom. And that those
> interests and priorities do not include Java getting in such a state
> that all the Fedora maintainers quit, major apps no loner work, and
> users are migrating elsewhere.

You would not expect a GCC devroom to be concerned about the problems
of all packages written in C and C++, so why would Java be any
different? The problems of Fedora Java packaging, while important, are
somewhat disjoint from those of the platform, especially at a
conference which is not even strictly Linux-specific.

> It’s not for me to approve or disapprove.

As far as I can tell from what has been said, the problems being
discussed here relate to packaging and testing. The packaging of
programs which depend on Java is somewhat outside my remit. Having
said that, I am interested to discover why Java packaging in Fedora is
particularly dysfunctional.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Vít Ondruch]

Dne 26. 01. 20 v 23:33 Bill Chatfield via devel napsal(a):
>> You're right. The Java SIG was not organised around an account group,
>> so it does not exist. I don't know why it is that way, but that could
>> easily be fixed - other language interest groups are organised this
>> way, after all (python-sig, go-sig, ruby-sig, etc.).
> I don't really understand what you're saying here. But I'd like to fix it.


Historically, the SIGs were just bunch of people who typically signed up
on Wiki:


https://fedoraproject.org/wiki/SIGs/Java#Members


More modern approach is to use FAS groups:


https://fedoraproject.org/wiki/SIGs/Python#Python_SIG_FAS_group

https://fedoraproject.org/wiki/SIGs/Ruby#Members


There might or might not be advantages to this. Depending on the SIG
organization, it might give you access to all the packages maintained by
the specific SIG.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Gerald Henriksen]

On Sun, 26 Jan 2020 22:33:55 -, you wrote:

>> That's not really fair. DNF is pretty much only the user interface,
>> and everything it's built on top of (hawkey, librepo, libsolv) is
>> implemented in C / C++. And when I think back to using yum, dnf is
>> really fast :)

>> I don't know which performance problems you have with python - which
>> components (written in python) do you think cause bottlenecks here?
>
>dnf

Except as per above, the peformance parts of dnf aren't written in
Python anyway.

>firewalld is using 37MB right now on my desktop. If it was written in Java it 
>would be using more. But if it was written in C/C++ it would be less than half 
>that size. It's not terrible I guess, compared to other things. I just really 
>prefer more efficiency at this level because when you start allowing this for 
>more and more programs that extra memory usage adds up.

I believe you said your machine had 8GB, so that means firewalld is
using an extravagant 0.4% of your memory.

Now yes, in theory (I say theory because you need to find a volunteer
to do it) someone could rewrite in a different language and save you
0.2% of your memory.

But is that really a good use of scarce resources?

>I respect your opinion here. But, I feel that as the hardware guys provide 
>more RAM, we shouldn't be wasting it. Because we waste a little RAM here and 
>then there and eventually every program is wasteful and all that waste adds 
>up. You end up with a poorly performing system even though it has plenty of 
>RAM. We need to bring back a culture of efficiency rather than wastefulness. 

It's a trade off - one of the reasons presumably you are programming
in Java is because it makes you more productive than writing in C.

We exchange hardware use for productivity because developer time is
far more expensive and scarce a resource than hardware is.

>OK, I don't know about this but I believe you. I'm just looking at it from a 
>user's perspective that there are a lot of problems and makes me thing that 
>not enough testing is being done.

Have you looked at the complaints that the users of Windows and Apple
products have these days?  It makes Fedora look really, really good. I
mean, Microsoft's answer to their quality control problems on Windows
appears to be shipping updates that don't do anything new...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

> You're right. The Java SIG was not organised around an account group,
> so it does not exist. I don't know why it is that way, but that could
> easily be fixed - other language interest groups are organised this
> way, after all (python-sig, go-sig, ruby-sig, etc.).

I don't really understand what you're saying here. But I'd like to fix it.
 

> There's even a Java package group set up there:
> https://koschei.fedoraproject.org/groups/java

I will look at that.

> the retrace server not supporting Zstd-compressed RPM packages, which
> was a feature introduced in fedora 31. It's a known issue, and people
> are working on fixing it.

Awesome.
 
> The release cadence is not a problem, in my opinion. Even if fedora
> only released every two years, Java packages would still be
> unmaintained and broken - 

Yea, I guess that is the problem.

> That's not really fair. DNF is pretty much only the user interface,
> and everything it's built on top of (hawkey, librepo, libsolv) is
> implemented in C / C++. And when I think back to using yum, dnf is
> really fast :)

When I type "sudo dnf install something" it takes about 10 minutes to pull 
updates from every repository, every time I run dnf. The actual install or 
update proceeds at a reasonable pace. I wouldn't call it fast. I could send you 
a video of this if you'd like. I see this on all my machines and I see other 
people complaining about it too.

In contrast, if I type "sudo apt install something" on Ubuntu or Debian, a 
bunch of text goes by really fast and BAM, it's done...

If I do "sudo apt update" it's also a lot faster than dnf.

I don't know if the problem is dnf or a library, but it is a serious problem.

> I don't know which performance problems you have with python - which
> components (written in python) do you think cause bottlenecks here?

dnf
firewalld

This is probably not as big an issue as I though.

 I
> also don't see excessive RAM usage with python - at least for my
> use-cases, it usually stays at a few MBs, or ~20 MB tops - unless I'm
> reading 100MB+ JSON files into memory ...

firewalld is using 37MB right now on my desktop. If it was written in Java it 
would be using more. But if it was written in C/C++ it would be less than half 
that size. It's not terrible I guess, compared to other things. I just really 
prefer more efficiency at this level because when you start allowing this for 
more and more programs that extra memory usage adds up.

> Again, if done right, python has no problems with performance (also,
> people should use the right tool for the job ...). Which
> performance-critical, python-written components do you see in fedora?

dnf and firewalld. But already discussed above.

> IIRC, it was recently debunked that the JS part of gnome-shell is to
> blame for poor performance. A lot of improvements have been made
> during 3.32 and 3.34 release cycles, and it shows. While I agree that
> using JS as a scripting language for the desktop shell was probably a
> bad choice, unless you use some broken gnome-shell extensions, JS
> should not cause performance issues in gnome-shell (or at least, not
> anymore). (I also don't know why the developers didn't opt for a
> python scripting interface, which is pretty standard for a lot of
> other GNOME components, and probably a python interpreter has a lower
> footprint than a JS engine, but well ...)

OK. I can accept that. If I had to choose between python and JavaScript I would 
also choose python. We have fake news...well JavaScript is a fake programming 
language.

> Yeah, memory efficiency is a problem. People used to care about it
> when everything needed to fit into 512 MB of RAM :)
> But what do you want to do? Rewrite all non-C GNOME components in
> Rust? It's not going to happen - not because it wouldn't be great, but
> because nobody is getting paid to rewrite things that aren't broken :)

I respect your opinion here. But, I feel that as the hardware guys provide more 
RAM, we shouldn't be wasting it. Because we waste a little RAM here and then 
there and eventually every program is wasteful and all that waste adds up. You 
end up with a poorly performing system even though it has plenty of RAM. We 
need to bring back a culture of efficiency rather than wastefulness. I believe 
we could be getting a lot more performance out of the machines that we already 
have. Our basic library, glibc is wasteful compared to musl libc and that 
contributes to performance and memory usage across the system.

> Interesting - I converted friends and family over to use fedora, and
> they're all really happy with it (happier than with both windows 10 or
> ubuntu), even my not-so-technologically-savvy mother. Because it *just
> works*.

There are instances where this has worked out for me. My son and his girlfriend 
have been using a Fedora laptop for school for about a year. However, this one 
successful conversion now needs to run ProTools for her class in college. There 
is no way to make 

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

I understand it can be done. But in the past getting something to work in wine 
is a guessing game. The instructions don't work. Winetricks doesn't get you to 
a functioning game and PlayOnLinux was for a long time non-functional in Fedora 
as the windows would not display properly. So getting a single game to work 
usually requires days, sometimes weeks of work.

The only thing that has made it reasonable is Steam's emulation setup (proton I 
guess). It does just work. But, then the problem is that the games run a lot 
slower on Linux than they do on Windows. My e-bay laptop can play them at a 
reasonable frame rate in Windows 10 (before I replaced it with Fedora). But I 
have to lower the games settings to the lowest values under Fedora and still it 
is not very good. So I admit my hardware is a big part of the problem. At this 
point though I'm pretty convinced that if I buy some gaming hardware, I'm going 
to get better game performance if I run Windows on it. So, I may just buy a 
PlayStation 4 and bypass the problem altogether.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

> Well, I don't know if its indicative of what they use for development,
> but at Red Hat Summit last year, *all* the Java middleware demos were
> on macOS.

That is frustrating and I don't like it. But, I suppose it makes since if their 
customers are using Macs to do development work and then deploying to RHEL.

On the other hand it doesn't seem like Red Hat is as serious about their 
Desktop/Workstation product as they are with their Server product. They're 
really not championing desktop Linux like I feel they should be doing. I 
understand their customers maybe don't want it as much as the server product. 
But, then they should be finding out WHY their customers don't want it. And 
most importantly, feeding that information back into the development pipeline 
of Fedora and CentOS so that the problem can get fixed
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

Great info. Thanks! It's always more complicated than I first imagine.  :-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

Yea, I understand what you're saying.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

I will do that. Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

I hear what you're saying. But I am undeterred.  :-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

 So I need to fix something that is a one-person job to get started.

On Sunday, January 26, 2020, 4:04:06 PM EST, Felix Schwarz 
 wrote:  
 
 
Am 26.01.20 um 01:10 schrieb Bill Chatfield via devel:
> That's a very sad story. I had no idea. So it sounds like you mainly need 
> maintainers for Java packages. I have worked on building RPMs but I have 
> never been a package maintainer. However I have 20 years of experience as a 
> Java developer, so I'm pretty confident I can be helpful. How should I go 
> forward? Is there a particular package that would be good to start with?

Probably the best thing is to "scratch your own itch". Fixing Fedora's Java
ecosystem is likely too much even for a full-time packager but fixing a
particular application seems to be a more realistic goal (though fixing the
Eclipse stack probably requires multiple people).

As you mentioned Eclipse in your initial post you should probably talk to Mat
Booth who's Fedora's Eclipse maintainer.

Also at some point you will need a "sponsor". Finding a sponsor might appear
complicated but I think if you talk directly to some sponsors (check the list
archives) you find that this is not a such a big deal once you proposed a few
sensible changes.

Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Felix Schwarz]

Am 26.01.20 um 01:10 schrieb Bill Chatfield via devel:
> That's a very sad story. I had no idea. So it sounds like you mainly need 
> maintainers for Java packages. I have worked on building RPMs but I have 
> never been a package maintainer. However I have 20 years of experience as a 
> Java developer, so I'm pretty confident I can be helpful. How should I go 
> forward? Is there a particular package that would be good to start with?

Probably the best thing is to "scratch your own itch". Fixing Fedora's Java
ecosystem is likely too much even for a full-time packager but fixing a
particular application seems to be a more realistic goal (though fixing the
Eclipse stack probably requires multiple people).

As you mentioned Eclipse in your initial post you should probably talk to Mat
Booth who's Fedora's Eclipse maintainer.

Also at some point you will need a "sponsor". Finding a sponsor might appear
complicated but I think if you talk directly to some sponsors (check the list
archives) you find that this is not a such a big deal once you proposed a few
sensible changes.

Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Neal Gompa]

On Sun, Jan 26, 2020 at 12:36 PM Tom Seewald  wrote:
>
> > On Sat, Jan 25, 2020 at 11:07 PM Bill Chatfield via devel
> *snip*
> > True. Nobody cares about Java packages in fedora, not even Red Hat
> > employees. If you look at the members of the Java SIG, a lot of them
> > were (or still are) Red Hat employees. For example, even JBoss /
> > WildFly (a pretty big Java project by Red Hat) was unmaintained and
> > broken, and most of it has now been removed from future fedora
> > releases. I wonder what they are going to do with RHEL 9 - maybe
> > somebody notices their stuff isn't available on fedora anymore.
>
> Do you happen to know what the Red Hat employees who maintain Java-based 
> products use as their desktop OS? RHEL? macOS?

Well, I don't know if its indicative of what they use for development,
but at Red Hat Summit last year, *all* the Java middleware demos were
on macOS. Maybe that's part of the problem? I saw a lot less usage of
RHEL in various product demo stations over the past few years...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Tom Seewald]

> On Sat, Jan 25, 2020 at 11:07 PM Bill Chatfield via devel
*snip*
> True. Nobody cares about Java packages in fedora, not even Red Hat
> employees. If you look at the members of the Java SIG, a lot of them
> were (or still are) Red Hat employees. For example, even JBoss /
> WildFly (a pretty big Java project by Red Hat) was unmaintained and
> broken, and most of it has now been removed from future fedora
> releases. I wonder what they are going to do with RHEL 9 - maybe
> somebody notices their stuff isn't available on fedora anymore.

Do you happen to know what the Red Hat employees who maintain Java-based 
products use as their desktop OS? RHEL? macOS?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Nico Kadel-Garcia]

On Sat, Jan 25, 2020 at 5:07 PM Bill Chatfield via devel
 wrote:
>
> I'm trying to find out what's going on with Java in Fedora. Fedora 31 was 
> released with a broken Eclipse. I subscribe to the java-devel mailing list 
> but there is no traffic there. If I go to "Join a Group" and click on "J" 
> there is simply nothing there...

Some of the Java problems are upstream. I've been sending patches to
vendors for patching their package deployments to cooperate with
Fedora and Red Hat since.I published hooks to get Sun JDK to fit
into JPackage in 2013, and last submitted patches to a Java vendor to
fix Fedora and RHEL integration 2 months ago. I can't even get them to
*name the RPM file the same thing as the installed RPM*, a mistake Sun
was doing since they first published an RPM and which I considered a
sign of why people gave up on their Java, and one repeated by several
Java publishers for no rational reason. OpenJDK has been a very
effective replacement for commercial Javas, and at least one vendor,
Azul, provides commercial support for a repackaged OpenJDK referred to
as "Zulu JDK".

Perhaps Azul developers or packagers could be encouraged to
participate in a Java SIG? Does anyone have personal contact with
them?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Jaroslav Prokop]

Hi Bill,

On 25/01/2020 23:06, Bill Chatfield via devel wrote:

In another case I tried to set up a Fedora system to run games, as that is what 
kids want to do. That was an utter failure because Fedora can't run any game 
that kids want to run today. The ability to run games cannot be underestimated 
because that is how you get the younger generation interested. That isn't 
really the fault of Fedora, I'm just mentioning that as an example of how, in 
general, the experience of the end-user is not being taken into account. And 
Fedora is failing to capture and retain users.


As a young person interested in Fedora and also in gaming I must 
disagree on this.

I run lots of games on wine with great success.

There are exceptions that either are a result of some messy coding
(e.g. Dragon age Origins' aliasing when it crashes on me when going over 4x)
or of the developers deliberately not wanting to support a portion of 
community (e.g. Rust and Vulkan
or Apex legends disabling anticheat support for Linux clients for some 
reason).


It became much much easier with steam proton where I can run even games 
as old

as "Star Wars: Republic Command" without problems.

All in all, we have wine, dxvk, winedb (which I use when something goes 
wrong)

and I run games from various companies with varying release dates.

Cheers,

Jarek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Jan Vlug]

Unfortunately, I also experience several issues with using Eclipse in Fedora. 
Actually the standard Eclipse package is not working well, and I am confused by 
the regular package and modular package mixture.

See also what I wrote at: 
https://ask.fedoraproject.org/t/status-of-eclipse-in-fedora/5162 before I was 
pointed out to this list.

For me it would be especially useful to know what the status of Eclipse in 
Fedora is, and preferably guidance on how to use Eclipse in Fedora.

The troubles do not take away my appreciation for the Fedora team and the 
Java/Eclipse maintainers. But I would like to know if it is useful to create 
Bugzilla issues for my problems.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Fabio Valentini]

On Sat, Jan 25, 2020 at 11:07 PM Bill Chatfield via devel
 wrote:

Hi again,

I have a bit more time today, so I can respond to your more of your
arguments directly.

> I'm trying to find out what's going on with Java in Fedora. Fedora 31 was 
> released with a broken Eclipse. I subscribe to the java-devel mailing list 
> but there is no traffic there. If I go to "Join a Group" and click on "J" 
> there is simply nothing there...
>
> https://admin.fedoraproject.org/accounts/group/list/J*?_csrf_token=d8baf5dd81fbb8289de644963217177eddc13278

You're right. The Java SIG was not organised around an account group,
so it does not exist. I don't know why it is that way, but that could
easily be fixed - other language interest groups are organised this
way, after all (python-sig, go-sig, ruby-sig, etc.).

> Please take an example from the recent Boeing failures where management 
> pushed the engineers to cut corners to meet release dates instead of taking 
> the time to test and fix problems. Anyone who has worked in an office can see 
> that is what happened. I don't know if it's management that is the problem 
> with Fedora since open source works a bit differently than your typical 
> corporation. But there is a problem and it's resulting in a low quality 
> product. You need automated tests. You need a suit of manual tests. For every 
> package. And you need to take the time to fix problems when they're 
> discovered. Software Engineering isn't just about writing code. It's about 
> creating a product that works for your end user. Your end-user has to be your 
> priority and that means quality has to be a priority.

Well, there are *some* automated tests. For example, koschei does
regular test rebuilds of a lot of fedora packages to check whether
they still successfully build.

There's even a Java package group set up there:
https://koschei.fedoraproject.org/groups/java

However, this only helps if 1) it's enabled for a package, and 2) if
anybody is actually looking at build failures when they start
happening.

There's also automated tests for every update that gets submitted to
fedora. For an example, look at the "Automated tests" tab for this
recent maven update:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-0be8546e6d

For updates in the "critical path" there's even more automated tests
(does fedora boot with this update? does upgrading work? does
networking continue to work? etc), like for this kernel update:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-3278105741

> The poor quality of Fedora in general and the poor support for Java is 
> basically forcing me to use Ubuntu just so that I can get a system that 
> actually works. I've been using Fedora for a long time and I hate to switch 
> away from it. But, I do actually have to get work done. Between gnome shell 
> crashes, long periods of the whole system being unresponsive, core Java 
> programs that I can't even install, mysterious network failures in nfs, 
> avahi, sshd and submitting bug reports that almost always end up failing to 
> submit after spending 15 minutes collecting data...I can't get any work done.

I agree, this Java situation is not good. We've been trying to keep it
from exploding, but there's only so much 2-3 people can do for over
200 packages.

The problem with failing bug report submissions is (I think) caused by
the retrace server not supporting Zstd-compressed RPM packages, which
was a feature introduced in fedora 31. It's a known issue, and people
are working on fixing it.

> I think the main problem is that you are not spending enough time on testing 
> and fixing problems before you release. Maybe 6 months is too short of a 
> cycle for the number of people you have. You can't cut a buggy release and 
> depend on your users to find the bugs for you. If you do, you are going to 
> lose all your users. As much as I love Linux and Fedora, I have to admit that 
> the quality of Fedora is about equal to that of Windows 95. There were a few 
> releases where quality was pretty good but 31 is in the gutter. The reason I 
> use Linux is to get a better quality system than Windows. But, that just 
> isn't happening with Fedora.

The release cadence is not a problem, in my opinion. Even if fedora
only released every two years, Java packages would still be
unmaintained and broken - it would just take longer for people to
notice, I guess.

> I really apologize for being an a-hole here but I'm saying these things 
> because I REALLY care about Fedora and they really need to be said. Things 
> need to change...quality needs to be the highest priority. And I'm willing to 
> help but I have tried to join projects several times with no responses. The 
> Java project doesn't even seem to exist.

You're right. The Java SIG has basically dissolved. Of the 26 members
listed on their wiki page, I think only 2-3 still actively maintain
RPM packages for fedora.
https://fedoraproject.org/wiki/SIGs/Java

> Being that Java is the most 

Re: Java Dev Group and Fedora Quality

[Nicolas Mailhot via devel]

Le dimanche 26 janvier 2020 à 10:10 +, Andrew Haley a écrit :
> On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote:
> 
> > Java has been in a terminal course in Fedora for a year at
> > least. You can see how much Red Hat Java leadership cares about the
> > situation by consulting next week’s Java dev room schedule. Red Hat
> > is co- organisator of this dev room
> > https://fosdem.org/2020/schedule/track/free_java/
> 
> Okay, I'll bite. I am part of the Red Hat Java leadership.
> 
> I'm pleased with this year's FOSDEM schedule. People have submitted a
> lot of interesting-looking talks, and I expect it'll be a good day. I
> take it that you don't approve of this list, but I don't know what it
> is you don't like about it.

I was just pointing out that devroom schedules reflect the interests
and priorities of the people organizing the devroom. And that those
interests and priorities do not include Java getting in such a state
that all the Fedora maintainers quit, major apps no loner work, and
users are migrating elsewhere.

It’s not for me to approve or disapprove. People can draw their own
conclusions.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Andrew Haley]

On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote:

> Java has been in a terminal course in Fedora for a year at
> least. You can see how much Red Hat Java leadership cares about the
> situation by consulting next week’s Java dev room schedule. Red Hat
> is co- organisator of this dev room
> https://fosdem.org/2020/schedule/track/free_java/

Okay, I'll bite. I am part of the Red Hat Java leadership.

I'm pleased with this year's FOSDEM schedule. People have submitted a
lot of interesting-looking talks, and I expect it'll be a good day. I
take it that you don't approve of this list, but I don't know what it
is you don't like about it.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Nicolas Mailhot via devel]

Le dimanche 26 janvier 2020 à 05:25 +, Bill Chatfield via devel a
écrit :
> And if the Gnome guys actually had information like this, they'd be
> forced to deal with it. 

Forcing people does not work that well in real life, and even less in
free software circles where participation is voluntary.

GNOME was born in RH labs. It never outgrew this lab culture. As long
as the GNOME project will see its mission as inventing new user
experiences, instead of making current user experiences work well, all
the problem reports in the world won’t change a thing (you can find
thousands of such reports, in the GNOME issue tracker).

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Adam Williamson]

On Sat, 2020-01-25 at 22:06 +, Bill Chatfield via devel wrote:
> You need automated tests. You need a suit of manual tests. For every package.

So to chime in on the QA aspects of this: the above is not
realistically possible, and it's also an explicit non-goal of all QA
and CI efforts.

We have something like 10,000 source packages in Fedora. On a very
optimistic count we might have 100 people who might plausibly be
capable of doing something to do with the above (this is an over-
estimate, but I'm just doing this as an illustration). There's no way
each of those 100 people is going to contribute and maintain a
sufficient test suite for 100 source packages.

In practice the way we approach QA for Fedora is to try and define a
subset of all possible QA activities which is actually manageable. So
far as releases go, we define release criteria:

https://fedoraproject.org/wiki/Fedora_Release_Criteria

these are informed by other things, like the Edition PRDs and tech
specs, e.g. https://fedoraproject.org/wiki/Workstation/Workstation_PRD
and https://fedoraproject.org/wiki/Server/Product_Requirements_Documen
t .

We then *do* define test plans that cover the release criteria; we're
at something like 95% coverage right now. Counting automation is a bit
complex as there are fuzzy areas like what level of coverage across
arches, editions and images we need for what test cases, but by my last
count approximately 78% of those test cases are automated.

If you read through the release criteria, you'll note that 'Eclipse
must work' is not one of them. That's a choice the project has made,
and that's why Eclipse not working didn't block the Fedora 31 release.
(We require all applications *included in a default install of one of
the release-blocking desktops* to work; Eclipse is not included in a
default install of any release-blocking desktop). Of course these
decisions can always be changed, but given the info Emmanuel and Fabio
provided about the state of Java package maintenance, it doesn't seem
likely that we'd be able to start blocking on Java packages at present.

Beyond the release criteria and release validation process, we have a
process and framework for testing updates to released packages. This is
mostly an as-best-as-we-can arrangement for now. There is a mechanism
by which manual test cases can be 'associated' with a given source
package (via wiki categories), and when a package has test cases
associated with it, they will be shown in the Bodhi - that's the update
system, https://bodhi.fedoraproject.org/ - page for the update, so
testers will be aware that those tests are available (and can provide
specific feedback on them). We also have a couple of automated test
systems that run on updates and/or package builds: the CI pipeline and
openQA. The CI pipeline can run some basic checks and also per-package
automated tests which are defined in a git repository for the package,
if any have been written (more on this at
https://docs.fedoraproject.org/en-US/ci/ ). openQA runs a subset of the
automated release validation tests (which are distribution-level
integration tests) on certain updates (all critical path updates, and
updates containing some other whitelisted packages) - more on this at 
https://fedoraproject.org/wiki/OpenQA . The results from both systems
are shown on the 'Automated Tests' tab in Bodhi, and there is an
optional mechanism by which updates can be gated on the automated test
results if the packager decides this makes sense.

As I first explained, though, it's not realistically possible for us to
provide comprehensive manual and/or automated tests for every package.
That's just too much work. The mechanisms we have in place are, I
think, pretty good and getting better; we are trying to extend test
coverage as far as we can as well, but it is never going to be close to
100% of all packages in Fedora, and as a project we have to focus our
efforts on the most critical packages and areas.

I'm sorry you had a bad experience with Eclipse, it's definitely not
what we want people to run into.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Emmanuel Seyman]

* Bill Chatfield via devel [25/01/2020 23:23] :
>
> I'd be willing to work on that if I can figure out how to recreate the group.
> Can you point me in the right direction?

SIGs are rather informal and none of them have a joining procedure
that I know of. That said, this was already discussed on the list
in November.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5HLSAPTEZLH24Y3GPF5NJEKULYJ64PUU/

You should subscribe to the mailing list, introduce yourself and
request any commit rights you feel you need. Once that's done,
you can start making commits/pull requests and doing reviews of
package submissions (formal or informal). Updating the wiki page
and welcoming new members would be a huge plus.

Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Nicolas Mailhot via devel]

Le dimanche 26 janvier 2020 à 00:10 +, Bill Chatfield via devel a
écrit :
> That's a very sad story. I had no idea. So it sounds like you mainly
> need maintainers for Java packages. I have worked on building RPMs
> but I have never been a package maintainer. However I have 20 years
> of experience as a Java developer, so I'm pretty confident I can be
> helpful. How should I go forward? Is there a particular package that
> would be good to start with?

The core competence for reviving the Java SIG seems to be people skill.
ie being able to convince the Java upstreams to fix the things that
make current Java packaging hell, making people give up.

Unfortunately, doing it in Fedora is starting with a severe handicap.
Because of the Red Hat/IBM affiliation, others will expect Red Hat/IBM
Java projects to be exemplary, and dismiss requests that diverge from
what they see happening Red Hat/IBM side (do what you  preach, etc).

Java has been in a terminal course in Fedora for a year at least. You
can see how much Red Hat Java leadership cares about the situation by
consulting next week’s Java dev room schedule. Red Hat is co-
organisator of this dev room
https://fosdem.org/2020/schedule/track/free_java/

I honestly don’t see a way out of this situation. It will spread to
more technical areas as Red Hat/IBM diversify without care for Fedora
needs. The Red Hat link is too strong for Fedora to act as a third
party WRT Red Hat interests. 

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Samuel Sieb]

On 1/25/20 9:25 PM, Bill Chatfield via devel wrote:

I think that by applying basic engineering techniques like user testing we can 
weed out ideologies that don't provide any value to users. Do the testing and 
let the results decide.The principles of ISO 9000 can be applied to improve 
products. There are also metrics that can measure how good a user interface is, 
like how many clicks does it take to perform a specific task. If these kinds of 
techniques were being applied to Gnome, we'd be able to more impartially 
measure how good Gnome is and also improve it. We'd be able to make more 
informed decisions and get better results. And if the Gnome guys actually had 
information like this, they'd be forced to deal with it. Maybe they'd be forced 
to admit that they care more about their ideology than helping their users be 
more productive. Or maybe the results would support the Gnome ideology. Until 
someone takes a scientific/engineering approach to measuring it, the issue 
can't really be resolved.

My problem with Gnome is that they just do whatever they feel like instead of 
applying well-established engineering or software engineering quality processes.


Except that they have actually done user testing and metrics like you're 
suggesting.  Maybe you personally don't like their choices, but many 
others do.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

I appreciate the sensibility of your suggestion but I'm afraid that I enjoy the 
aggravation of my love/hate relationship with Gnome too much. You got me 
thinking though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Benson Muite]

On 1/26/20 8:25 AM, Bill Chatfield via devel wrote:

I think that by applying basic engineering techniques like user testing we can 
weed out ideologies that don't provide any value to users. Do the testing and 
let the results decide.The principles of ISO 9000 can be applied to improve 
products. There are also metrics that can measure how good a user interface is, 
like how many clicks does it take to perform a specific task. If these kinds of 
techniques were being applied to Gnome, we'd be able to more impartially 
measure how good Gnome is and also improve it. We'd be able to make more 
informed decisions and get better results. And if the Gnome guys actually had 
information like this, they'd be forced to deal with it. Maybe they'd be forced 
to admit that they care more about their ideology than helping their users be 
more productive. Or maybe the results would support the Gnome ideology. Until 
someone takes a scientific/engineering approach to measuring it, the issue 
can't really be resolved.

My problem with Gnome is that they just do whatever they feel like instead of 
applying well-established engineering or software engineering quality processes.


Desktop change can be done from terminal [0],[1],[2] (though not in 
software center which may be helpful for some users):


sudo dnf -y group install "KDE Plasma Workspaces"


Not sure if any of the available desktops takes the above measurement  
approach. Many linux users value privacy, but some data collection would 
be helpful.



[0] https://computingforgeeks.com/install-kde-plasma-environment-on-fedora/

[1] 
https://computingforgeeks.com/how-to-install-deepin-desktop-environment-on-fedora/


[2] 
https://www.tecmint.com/install-and-switch-desktop-environments-in-fedora/



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

I think that by applying basic engineering techniques like user testing we can 
weed out ideologies that don't provide any value to users. Do the testing and 
let the results decide.The principles of ISO 9000 can be applied to improve 
products. There are also metrics that can measure how good a user interface is, 
like how many clicks does it take to perform a specific task. If these kinds of 
techniques were being applied to Gnome, we'd be able to more impartially 
measure how good Gnome is and also improve it. We'd be able to make more 
informed decisions and get better results. And if the Gnome guys actually had 
information like this, they'd be forced to deal with it. Maybe they'd be forced 
to admit that they care more about their ideology than helping their users be 
more productive. Or maybe the results would support the Gnome ideology. Until 
someone takes a scientific/engineering approach to measuring it, the issue 
can't really be resolved.

My problem with Gnome is that they just do whatever they feel like instead of 
applying well-established engineering or software engineering quality processes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

No problem. I like hearing peoples' opinions.

I will look for a package that might be a good starting point.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Alexander Ploumistos]

Hello Bill,

And sorry for digressing.

On Sun, Jan 26, 2020 at 1:10 AM Bill Chatfield via devel
 wrote:
>
> That's a very sad story. I had no idea. So it sounds like you mainly need 
> maintainers for Java packages. I have worked on building RPMs but I have 
> never been a package maintainer. However I have 20 years of experience as a 
> Java developer, so I'm pretty confident I can be helpful. How should I go 
> forward? Is there a particular package that would be good to start with?

You should start here:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/

As for which package you should tackle first, since you're a Java
programmer, you are the most qualified to identify what you think is
missing or malfunctioning and work your way (up the dependency chain)
from there.

I hope this helps.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Ty Young]

On 1/25/20 7:30 PM, Alexander Ploumistos wrote:

Hello Ty,

On Sun, Jan 26, 2020 at 1:42 AM Ty Young  wrote:

The unfortunate reality is that none of what you describe will likely
change in any significant way, at least not with the standard Linux
distros(Ubuntu, Fedora, Debian, Arch) etc. Too much of Linux is ideology
based(GNU, among other political ideologies) instead of just making the
best software/platform possible, which pushes away people who would like
to contribute and use Linux software. There is little, if any,
compromises by those who believe in these ideologies. They are willing
to stand by their beliefs until the very end.

How you conduct yourself in your everyday life, whether you realize it
or not, not only reflects your political beliefs, it is in itself
politics. Someone volunteering a portion of their finite time to a
project that benefits many, but does not result in direct compensation
for them, is a deeply political act. Without ideologists willing to
fight for their beliefs and stand their ground, we'd all be worshiping
god-kings, who'd hold an absolute power over the life or death of
their subjects. In a much narrower scope, over the last thirty years
or so, had there not been ideologists promoting and defending the
precious idea of Free Software, we'd all be doomed to run windows and
browse a Microsoft-defined web using internet explorer.



This is an assumption being masqueraded as a fact. Firefox is open 
source and uses DRM(For better or for worse). There are more colors than 
black and white.



There are also ways for Open Source developers to be compensated for 
their work. Elementary has a donate button IIRC in their package 
manager. Some developers also use Patron or Librepay(I think it's 
called?). Fedora doesn't offer users the option via Gnome Software.



Of course there is a difference between donations and paying for 
software, but if you're complaining about developers not being "thanked" 
then Fedora is in part responsible for that. You choose not to have the 
option right front and center.





Your own post, is indeed political and it is quite telling. I do not
know what your particular beef with GNOME is and frankly I don't care.
Bill here had one of the healthiest reactions to the situation he was
facing. He actually offered to do something about it, instead of
whining. That should serve as an example.



The desire to help was expressed and what was it. Not downplaying the 
importance of it per se but rather putting it into perspective. Fedora 
in particular utilizes a lot of in-house tools and systems. Many of 
those seem to have some kind of issue or another that frustrates even 
long time packagers and developers. The Java SIG all quit in part IIRC 
because packaging Java stuff was too hard in Fedora.



And lets not even get into the modular mess. I've been subscribed to 
this list long enough to know how much everyone "loves" modules.







It's best not to bring up any such issues, especially in Fedora/Gnome
home turf. They have "Code of Conduct" nukes that are used to silence
any discussion they don't agree with. Just take a look at the Gnome
subreddit, wherein the moderators have been caught and continue to issue
thread/comment locks and temp bans for (nicely) pointing out bugs in
Gnome. It's scary stuff, and is only getting worse with Gnome's Code of
Conduct allowing racism. They will deny it endlessly that this is the
intent but have publicly fought against revising it to clear up the
intent after public outcry.

The Code of Conduct is decided by people participating in the project.
Among its objectives, is to protect those doing actual and often
thankless work from the demoralizing abuse of ungrateful and entitled
egoists, hiding behind a computer screen and a handle.



Ah, allowing racism is to somehow protect developers and the majority of 
Gnome is OK with it. Got it.




  The Code of
Conduct is not set in stone and those participating in the project may
at any time choose to alter it. Participation is the operative word
here and under no circumstance does griping count as participation.
Neal already covered the other points I wanted to make.



TL;DR: Only the opinions of those that are part of the clubhouse matter.


(Sadly the only way to be apart of the clubhouse is by agreeing with the 
existing clubhouse members. Darn.)




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: Java Dev Group and Fedora Quality

[Alexander Ploumistos]

Hello Ty,

On Sun, Jan 26, 2020 at 1:42 AM Ty Young  wrote:
>
> The unfortunate reality is that none of what you describe will likely
> change in any significant way, at least not with the standard Linux
> distros(Ubuntu, Fedora, Debian, Arch) etc. Too much of Linux is ideology
> based(GNU, among other political ideologies) instead of just making the
> best software/platform possible, which pushes away people who would like
> to contribute and use Linux software. There is little, if any,
> compromises by those who believe in these ideologies. They are willing
> to stand by their beliefs until the very end.

How you conduct yourself in your everyday life, whether you realize it
or not, not only reflects your political beliefs, it is in itself
politics. Someone volunteering a portion of their finite time to a
project that benefits many, but does not result in direct compensation
for them, is a deeply political act. Without ideologists willing to
fight for their beliefs and stand their ground, we'd all be worshiping
god-kings, who'd hold an absolute power over the life or death of
their subjects. In a much narrower scope, over the last thirty years
or so, had there not been ideologists promoting and defending the
precious idea of Free Software, we'd all be doomed to run windows and
browse a Microsoft-defined web using internet explorer.

Your own post, is indeed political and it is quite telling. I do not
know what your particular beef with GNOME is and frankly I don't care.
Bill here had one of the healthiest reactions to the situation he was
facing. He actually offered to do something about it, instead of
whining. That should serve as an example.


> It's best not to bring up any such issues, especially in Fedora/Gnome
> home turf. They have "Code of Conduct" nukes that are used to silence
> any discussion they don't agree with. Just take a look at the Gnome
> subreddit, wherein the moderators have been caught and continue to issue
> thread/comment locks and temp bans for (nicely) pointing out bugs in
> Gnome. It's scary stuff, and is only getting worse with Gnome's Code of
> Conduct allowing racism. They will deny it endlessly that this is the
> intent but have publicly fought against revising it to clear up the
> intent after public outcry.

The Code of Conduct is decided by people participating in the project.
Among its objectives, is to protect those doing actual and often
thankless work from the demoralizing abuse of ungrateful and entitled
egoists, hiding behind a computer screen and a handle. The Code of
Conduct is not set in stone and those participating in the project may
at any time choose to alter it. Participation is the operative word
here and under no circumstance does griping count as participation.
Neal already covered the other points I wanted to make.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Ty Young]

On 1/25/20 7:12 PM, Neal Gompa wrote:

On Sat, Jan 25, 2020 at 7:42 PM Ty Young  wrote:

You miss the point of how FOSS projects work. Read up on some history
and get some understanding of the cultural background before you
blithely say that ideology and passion are what is killing Linux
distros. People who are passionate about FOSS and develop their
platforms work to produce quality software because they care for it.
High quality software is an effect of the process, not the deliberate
goal. And this means that sometimes FOSS *isn't* the highest quality
it could be, because the person working on it as a passion cannot do
so alone. That's the opportunity for you to step up and help make it
better.

That, in itself, is the core difference between FOSS and proprietary
software. FOSS is full of passion and possibility, while proprietary
software is defined only by its usefulness and restrictions.



You say this as if everything is black and white; that things like 
"passion" can't possibly hurt you.



Anyway, getting off topic. I don't mind personally but I don't want any 
excuses to nuke this off the face of the planet.






It's best not to bring up any such issues, especially in Fedora/Gnome
home turf. They have "Code of Conduct" nukes that are used to silence
any discussion they don't agree with. Just take a look at the Gnome
subreddit, wherein the moderators have been caught and continue to issue
thread/comment locks and temp bans for (nicely) pointing out bugs in
Gnome. It's scary stuff, and is only getting worse with Gnome's Code of
Conduct allowing racism. They will deny it endlessly that this is the
intent but have publicly fought against revising it to clear up the
intent after public outcry.


Be silent and fall in line, or be sent to the gulag.


This is very rude and definitely a huge misrepresentation of the
Fedora community. While it is true that Fedora Workstation is GNOME
centric, Fedora is one of a select few that contains virtually every
major desktop environment and window manager, as well as several minor
ones. We have Lumina, Xfce, MATE, KDE (my favorite and what I
personally run), Cinnamon, Deepin, Pantheon (from elementary OS!), and
many others. We support several desktop environments quite well, and
offer spins for most of them at https://spins.fedoraproject.org. Most
of these have official teams (Special Interest Groups) that support
these environments. If you're interested in one, join one of them.



Not calling out anyone who isn't aware of or agrees with Fedora and/or 
Gnome's tendencies to nuke discussions into orbit(or their Code of 
Conducts). I guess I should have been more clear on that. Apologies.





I don't know anything about the GNOME subreddit, nor do I really care.
GNOME is not Fedora. And Fedora itself is not defined by GNOME. We are
a separate, larger entity that does quite a bit more and has a much
more diverse audience.



While that's true, it's well known that Gnome and Fedora have a very 
incestuous relationship. So much so that people point to Fedora as the 
"premium" Gnome 3 experience. Whether or not that is actually true is 
neither here nor there, point is that there is a lot of developers that 
are apart of both(which is why people say that).





Like all good communities, respectful discourse is permitted, but
being belligerent, hateful, and condescending is unnecessary and
unwanted. Let's be excellent to each other. Be good to your fellow
human.



This isn't a universally shared way of thinking, sadly.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Neal Gompa]

On Sat, Jan 25, 2020 at 7:42 PM Ty Young  wrote:
>
>
> Hi Bill,
>
>
> Not an average Fedora user but I've used several Linux
> distributions(including Fedora and versions there of) over the years.
> What you are bringing up is 100% valid and isn't new or specific to
> Fedora. It's been a known and valid complaint that there isn't enough
> software in distro X or that the quality of what does exist in distro X
> is poor.
>
>
> The unfortunate reality is that none of what you describe will likely
> change in any significant way, at least not with the standard Linux
> distros(Ubuntu, Fedora, Debian, Arch) etc. Too much of Linux is ideology
> based(GNU, among other political ideologies) instead of just making the
> best software/platform possible, which pushes away people who would like
> to contribute and use Linux software. There is little, if any,
> compromises by those who believe in these ideologies. They are willing
> to stand by their beliefs until the very end.
>
>
> This, sadly, results in the situation where we are now: lots of Linux
> distributions and/or desktop shells that are either of poor quality or
> abandoned. Software developers don't want to support half or dozen(or
> more!) Linux distributions, so they either don't support Linux or only
> target a specific distribution. That makes users mad and leave so
> developers don't bother targeting those distributions... and well, yeah,
> you get the idea.
>
>

You miss the point of how FOSS projects work. Read up on some history
and get some understanding of the cultural background before you
blithely say that ideology and passion are what is killing Linux
distros. People who are passionate about FOSS and develop their
platforms work to produce quality software because they care for it.
High quality software is an effect of the process, not the deliberate
goal. And this means that sometimes FOSS *isn't* the highest quality
it could be, because the person working on it as a passion cannot do
so alone. That's the opportunity for you to step up and help make it
better.

That, in itself, is the core difference between FOSS and proprietary
software. FOSS is full of passion and possibility, while proprietary
software is defined only by its usefulness and restrictions.

> It's best not to bring up any such issues, especially in Fedora/Gnome
> home turf. They have "Code of Conduct" nukes that are used to silence
> any discussion they don't agree with. Just take a look at the Gnome
> subreddit, wherein the moderators have been caught and continue to issue
> thread/comment locks and temp bans for (nicely) pointing out bugs in
> Gnome. It's scary stuff, and is only getting worse with Gnome's Code of
> Conduct allowing racism. They will deny it endlessly that this is the
> intent but have publicly fought against revising it to clear up the
> intent after public outcry.
>
>
> Be silent and fall in line, or be sent to the gulag.
>

This is very rude and definitely a huge misrepresentation of the
Fedora community. While it is true that Fedora Workstation is GNOME
centric, Fedora is one of a select few that contains virtually every
major desktop environment and window manager, as well as several minor
ones. We have Lumina, Xfce, MATE, KDE (my favorite and what I
personally run), Cinnamon, Deepin, Pantheon (from elementary OS!), and
many others. We support several desktop environments quite well, and
offer spins for most of them at https://spins.fedoraproject.org. Most
of these have official teams (Special Interest Groups) that support
these environments. If you're interested in one, join one of them.

I don't know anything about the GNOME subreddit, nor do I really care.
GNOME is not Fedora. And Fedora itself is not defined by GNOME. We are
a separate, larger entity that does quite a bit more and has a much
more diverse audience.

Like all good communities, respectful discourse is permitted, but
being belligerent, hateful, and condescending is unnecessary and
unwanted. Let's be excellent to each other. Be good to your fellow
human.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Ty Young]

Hi Bill,


Not an average Fedora user but I've used several Linux 
distributions(including Fedora and versions there of) over the years. 
What you are bringing up is 100% valid and isn't new or specific to 
Fedora. It's been a known and valid complaint that there isn't enough 
software in distro X or that the quality of what does exist in distro X 
is poor.



The unfortunate reality is that none of what you describe will likely 
change in any significant way, at least not with the standard Linux 
distros(Ubuntu, Fedora, Debian, Arch) etc. Too much of Linux is ideology 
based(GNU, among other political ideologies) instead of just making the 
best software/platform possible, which pushes away people who would like 
to contribute and use Linux software. There is little, if any, 
compromises by those who believe in these ideologies. They are willing 
to stand by their beliefs until the very end.



This, sadly, results in the situation where we are now: lots of Linux 
distributions and/or desktop shells that are either of poor quality or 
abandoned. Software developers don't want to support half or dozen(or 
more!) Linux distributions, so they either don't support Linux or only 
target a specific distribution. That makes users mad and leave so 
developers don't bother targeting those distributions... and well, yeah, 
you get the idea.



It's best not to bring up any such issues, especially in Fedora/Gnome 
home turf. They have "Code of Conduct" nukes that are used to silence 
any discussion they don't agree with. Just take a look at the Gnome 
subreddit, wherein the moderators have been caught and continue to issue 
thread/comment locks and temp bans for (nicely) pointing out bugs in 
Gnome. It's scary stuff, and is only getting worse with Gnome's Code of 
Conduct allowing racism. They will deny it endlessly that this is the 
intent but have publicly fought against revising it to clear up the 
intent after public outcry.



Be silent and fall in line, or be sent to the gulag.


Hope this helps.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

That's a very sad story. I had no idea. So it sounds like you mainly need 
maintainers for Java packages. I have worked on building RPMs but I have never 
been a package maintainer. However I have 20 years of experience as a Java 
developer, so I'm pretty confident I can be helpful. How should I go forward? 
Is there a particular package that would be good to start with?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Fabio Valentini]

On Sun, Jan 26, 2020 at 12:24 AM Bill Chatfield via devel
 wrote:
>
> > As has been discussed time and time again on this mailing list, the last
> > member of the Java SIG left it at the end of 2018, leaving the group emptIy.


> I'd be willing to work on that if I can figure out how to recreate the group. 
> Can you point me in the right direction?

I think you'll be interested to read this post I wrote two months ago:
https://discussion.fedoraproject.org/t/whats-the-state-of-the-java-sig/11714

The problem is that almost none (between zero and one) of the original
Java package maintainers in fedora are still actively maintaining any
Java packages. Most have either just left, or have jumped ship for the
shiny new world of Modularity, leaving users out in the rain.

Since early 2019, there's been an ongoing effort to try to keep things
from exploding, led by the Stewardship SIG, but it's not a permanent
solution, since it's not a replacement for "real" maintainers for Java
packages.

TL;DR: We've been trying to keep things working as best as we can -
but with severely limited manpower, it's basically maintenance on a
best-effort basis for almost the entire Java stack.

Fabio

> > There are several FAS groups with 'java' in their name but non that start
> > with the letter 'J'. I'm not sure why you would expect this to be the 
> > case...
>
> Because Java starts with "J".   ;-)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

> As has been discussed time and time again on this mailing list, the last
> member of the Java SIG left it at the end of 2018, leaving the group emptIy.

I'd be willing to work on that if I can figure out how to recreate the group. 
Can you point me in the right direction?


> There are several FAS groups with 'java' in their name but non that start
> with the letter 'J'. I'm not sure why you would expect this to be the case...

Because Java starts with "J".   ;-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Emmanuel Seyman]

* Bill Chatfield via devel [25/01/2020 22:06] :
>
> I'm trying to find out what's going on with Java in Fedora. Fedora 31 was 
> released with a broken Eclipse. I subscribe to the java-devel mailing list 
> but there is no traffic there.

As has been discussed time and time again on this mailing list, the last
member of the Java SIG left it at the end of 2018, leaving the group empty.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YFUXS7ZX6UDEMEKJWONKFMVDTSBABZID/

> If I go to "Join a Group" and click on "J" there is simply nothing there...

There are several FAS groups with 'java' in their name but non that start
with the letter 'J'. I'm not sure why you would expect this to be the case...

Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

I'm trying to find out what's going on with Java in Fedora. Fedora 31 was 
released with a broken Eclipse. I subscribe to the java-devel mailing list but 
there is no traffic there. If I go to "Join a Group" and click on "J" there is 
simply nothing there...

https://admin.fedoraproject.org/accounts/group/list/J*?_csrf_token=d8baf5dd81fbb8289de644963217177eddc13278

Please take an example from the recent Boeing failures where management pushed 
the engineers to cut corners to meet release dates instead of taking the time 
to test and fix problems. Anyone who has worked in an office can see that is 
what happened. I don't know if it's management that is the problem with Fedora 
since open source works a bit differently than your typical corporation. But 
there is a problem and it's resulting in a low quality product. You need 
automated tests. You need a suit of manual tests. For every package. And you 
need to take the time to fix problems when they're discovered. Software 
Engineering isn't just about writing code. It's about creating a product that 
works for your end user. Your end-user has to be your priority and that means 
quality has to be a priority.

The poor quality of Fedora in general and the poor support for Java is 
basically forcing me to use Ubuntu just so that I can get a system that 
actually works. I've been using Fedora for a long time and I hate to switch 
away from it. But, I do actually have to get work done. Between gnome shell 
crashes, long periods of the whole system being unresponsive, core Java 
programs that I can't even install, mysterious network failures in nfs, avahi, 
sshd and submitting bug reports that almost always end up failing to submit 
after spending 15 minutes collecting data...I can't get any work done.

I think the main problem is that you are not spending enough time on testing 
and fixing problems before you release. Maybe 6 months is too short of a cycle 
for the number of people you have. You can't cut a buggy release and depend on 
your users to find the bugs for you. If you do, you are going to lose all your 
users. As much as I love Linux and Fedora, I have to admit that the quality of 
Fedora is about equal to that of Windows 95. There were a few releases where 
quality was pretty good but 31 is in the gutter. The reason I use Linux is to 
get a better quality system than Windows. But, that just isn't happening with 
Fedora.

I really apologize for being an a-hole here but I'm saying these things because 
I REALLY care about Fedora and they really need to be said. Things need to 
change...quality needs to be the highest priority. And I'm willing to help but 
I have tried to join projects several times with no responses. The Java project 
doesn't even seem to exist.

Being that Java is the most popular programming language in the industry by 
multiple metrics, most corporations use it, a large part of Red Hat's business 
is Java, Hadoop is written in Java, I'd expect to see much better support for 
it in Fedora. But, it's like a second-class citizen. Python, the slowest 
language ever created (except for Ruby), is about the only thing people care 
about. Python is part of the problem with Fedora as it is a big part of what 
makes Fedora slow. Anyone who has compared the performance of dnf versus apt 
can see that dnf sucks...bad. Apt is extremely fast and dnf is extremely slow. 
There is no room for argument there. It's just the truth. I'm not saying that 
to be mean. I'm trying to point out a serious problem that needs to be 
addressed. It does not matter now nice a language is to program in. What 
matters is the user experience. Programs that are integral to the operating 
system should not be written in Python or Java. They need to be written in an 
memory
  and CPU efficient language like C/C++ or Ada. If you could get better 
performance out of Python, that could be an option too, like maybe running 
Python programs in pypy instead of regular python. The important thing is 
getting the right user experience. By that I mean that the program has to run 
fast and not take up large amounts of memory on the user's machine so that 
other programs don't have enough room to run. 

These issues apply to Gnome, Python and Java. As a Java programmer I understand 
that Java uses massive amounts of memory. It's not an appropriate 
implementation language for operating system level components because of that. 
If you have 15 Java programs running on an end-user machine, the machine is 
going to run out of memory. It is fine to run 1 or 2 application-level programs 
on an end-user machine. And Java is great on the server where you can have a 
large amount of memory.

Python has the same problem but in addition it is also slow. If you think Java 
is slow you need to re-educate yourself, because it is not. You can test this 
yourself by writing some equivalent Java and Python programs and timing them. 
I'm not saying anything here you can't verify on your own.