Java Dev Group and Fedora Quality
by Bill Chatfield
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=d8baf5...
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.
Gnome uses way too much of memory for an end-user's machine. It has an embedded JavaScript interpreter with JavaScript plugins that are slow. Most people don't have 32 GB of RAM on their machine so the memory consumption and the slowness has a real effect on your end users. Remember it's your end-user that matters, not how it runs on your 32 GB i9 development machine.
I have an 8GB machine which I think is pretty standard these days. Again, I'm talking about end-user machines, not developer machines. You have to have a mind set of what your end user is going to experience. But if I run Gnome, a Java IDE and a web browser, I'm pretty much out of memory. I don't want my operating system consuming all my memory. I don't use a computer just to run an operating system. I use it to run applications. I want my operating system to use a minimum amount of memory so that I have memory for my applications to run. Because the point of using a computer is to run applications, not just an operating system.
My apologies if I offended anyone. I am just trying to communicate to you how your end-users, like me, are experiencing the system. My experience is no different from anyone else that I've talked to who has tried Fedora. In fact, everyone I know has already given up on it. I don't know anyone besides myself that continues to believe that Fedora is worth using. Everyone else that I know who uses Linux, uses Ubuntu. I can't even get my kids to use Linux. One of my boys told me that the default Gnome desktop that I provided to him to use was the worst computer experience he's ever had. He'll never bother to try Linux again because he thinks it's stupid. Because of Gnome.
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.
I've also set up a Fedora Server to serve my Dropbox files over nfs to other machines I have that can't access Dropbox directly. It also runs dnsmasq. But, half the time this machine is unresponsive on the network. It doesn't respond to avahi requests until I restart the avahi daemon. nfs becomes unresponsive and ssh sessions become unresponsive for long periods of time. This machine worked fine under Windows. I have a 20 year old UltraSparc 5 running Solaris 8 that works better. It always responds on the network. Nfs, ssh, etc work flawlessly on it.
This all leads me to believe that Fedora is not being tested properly. Gnome should also be required to go through user-acceptance testing. Software should be required to meet the needs of end users, not the other way around. When Microsoft created the start menu and the task bar, they did it in response to proper end user testing where they observed how end users used and reacted to the system and then created solutions to the problems they experienced. THAT is how user interfaces should be developed. (Probably the only thing that Microsoft ever did right.) Certainly not by allowing one person to guess about how it should work and then trying to force everyone else to accept that theoretical idea until it seems like the right way to do it.
4 years, 2 months
How to handle circular build dependencies?
by Markku Korkeala
Hi,
sorry if this a newbie question, I tried to search this
but did not find good documentation on this problem.
I'm in the process of upgrading the clojure package to
next version, which has new dependencies. These dependencies
require certain clojure version themselves, so it makes a
chicken-and-egg kind of problem. Are there good ways to handle
these kind of circular dependencies?
I know I can update clojure to certain alpha version,
which the new libraries require. Then build those,
and when they are accepted then upgrade the
clojure package, and then upgrade those libraries, etc. But
it is tedious. I'm hoping there would be a better
way :) And also do I have to do that bootstrapping
again when building clojure for example EPEL-8?
Best regards,
Markku
--
Markku
4 years, 2 months
Review swaps (antlr4 reboot)
by Jerry James
Greetings,
The antlr4 package needs a reboot so that it can ship the various
language runtime libraries, and so that it can be updated to the
latest version. I have been in contact with the maintainers of the
current antlr4 package and have received approval to proceed with
this.
I would like to swap reviews for the following:
treelayout: https://bugzilla.redhat.com/show_bug.cgi?id=1795467
This package was previously in Fedora, but was retired after being
orphaned. It has been retired long enough that a re-review is
necessary.
mojo-executor: https://bugzilla.redhat.com/show_bug.cgi?id=1795468
string-template-maven-plugin:
https://bugzilla.redhat.com/show_bug.cgi?id=1795469
Depends on mojo-executor.
antlr4-cpp-runtime: https://bugzilla.redhat.com/show_bug.cgi?id=1795470
Depends on treelayout and string-template-maven-plugin. The funny
name is because, so far as I am aware, it is still not possible to
have a noarch main package with arch-specific subpackages. I selected
one of the arch-specific language runtimes to be the main package, and
antlr4 itself (which is noarch) is a subpackage. Once this package is
in Rawhide, the existing antlr4 package will be retired and the
antlr4-python3-runtime subpackage will be removed from the coq
package.
Thanks in advance. Regards,
--
Jerry James
http://www.jamezone.org/
4 years, 3 months
Re: What would it take to drop release and changelog from our spec
files? (and do we want to?)
by Neal Gompa
On Tue, Jan 28, 2020 at 6:12 PM Stasiek Michalski <hellcp(a)opensuse.org> wrote:
>
>
> On Tue, Jan 28, 2020 at 23:57, Dan Čermák
> <dan.cermak(a)cgc-instruments.com> wrote:
> > Neal Gompa <ngompa13(a)gmail.com> writes:
> >
> >> On Tue, Jan 28, 2020 at 7:27 AM Pierre-Yves Chibon
> >> <pingou(a)pingoured.fr> wrote:
> >>>
> >>> On Fri, Jan 10, 2020 at 09:54:59PM -0500, Neal Gompa wrote:
> >>> > On Fri, Jan 10, 2020 at 11:37 AM Pierre-Yves Chibon
> >>> <pingou(a)pingoured.fr> wrote:
> >>> > >
> >>> > >
> >>> > > The release field would need to be set by koji ignoring
> >>> whatever is in the spec
> >>> > > file. How do we want to do this?
> >>> > > - Based on dates?
> >>> > > - Using an always increasing integer?
> >>> > > - Using the number of successful builds since the last time
> >>> the version field changed?
> >>> > > - Another idea?
> >>> > >
> >>> > > The third option looks like to be the one closest to our
> >>> current behavior.
> >>> > >
> >>> >
> >>> > I always envisioned that we'd use a variant of the third option.
> >>> >
> >>> > The options I've thought of:
> >>> >
> >>> > * <commit-at-version>%{dist}.<build-at-version>
> >>> > * <commit-at-version>.<build-at-version>%{?dist}
> >>> > * %{dist}.<commit-at-version>.<build-at-version>
> >>>
> >>> I've been thinking a bit about this and been wondering any reason
> >>> why not to do
> >>> simply?
> >>> <build-at-version>%{dist}
> >>>
> >>> This would basically mimic what we are currently doing by hand, it
> >>> would be the
> >>> less changes to our current way of working (making opting-in
> >>> smoother).
> >>>
> >>
> >> If we're not doing automatic builds, sure. I've been going on two
> >> big
> >> assumptions:
> >>
> >> 1. We're going to do automatic building
> >> 2. We need *some* kind of stable leading portion of release for
> >> packagers to use for specified dependencies, especially
> >> Obsoletes+Provides combos.
> >
> > How is openSUSE taking care of 2 then? OBS bumps the release on each
> > rebuild and that can result in crazily high release numbers. I assume
> > they got a mechanism for Obsoletes+Provides and we could use that too?
>
> You got me curious there, so I looked it up with dnf, the highest
> release
> number in Factory is 1475.12 and it belongs to elib, which had its
> source/
> patches last updated 13 years ago, and its spec/changes 5 years ago.
>
The original commit of that package[1] had an absurdly high Release
number, so OBS stuck to it. At the fourth commit[2], the version was
synced and updated to 1451. The original autobuild system had a
Release value sync mechanism which I assume was dropped as part of the
migration from autobuild to OBS. That system likely synced the state
of that value as it was rebuilt without source changes. After that
point, we finally arrive at when the in-spec value was set to zero by
Stephen Kulow[3]. But regardless, OBS kept that value and kept
incrementing it on further commits, leading to the 1475 we have now.
There hasn't been a new version of elib to trigger OBS to reset the
Release value back to zero, so that's why the value is ridiculously
high. There have been 12 builds of the latest commit of elib (hence
the 12).
So if elib were theoretically replaced with something else, you'd do
the following:
Obsoletes: elib < 1.0-1476
Provides: elib = 1.0-1476
[1]: https://build.opensuse.org/package/view_file/openSUSE:Factory/elib/elib.s...
[2]: https://build.opensuse.org/package/rdiff/openSUSE:Factory/elib?linkrev=ba...
[3]: https://build.opensuse.org/package/rdiff/openSUSE:Factory/elib?linkrev=ba...
--
真実はいつも一つ！/ Always, there's only one truth!
4 years, 3 months
What would it take to drop release and changelog from our spec
files? (and do we want to?)
by Pierre-Yves Chibon
Good Morning Everyone,
This is not a new idea, it has been presented at flock last year and spoken
about on this very list this fall, so I'd like to push it a little further.
Do we want to drop release and changelog from our spec file?
If we do, how would this work?
The release field would need to be set by koji ignoring whatever is in the spec
file. How do we want to do this?
- Based on dates?
- Using an always increasing integer?
- Using the number of successful builds since the last time the version field changed?
- Another idea?
The third option looks like to be the one closest to our current behavior.
Another question regarding the release field is: how would we deal with
pre-releases and other unsortable versions?
The current doc relies on <extraver> etc. in the release field as per:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_un...
Would using the tilde to specify pre-releases in the version field be sufficient
(as described in
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_ve...
I.e., how can we cater for snapshot releases (e.g. based off a specific git
commit)?
With the changelog it becomes a little bit more tricky.
We currently have 3 changelogs in Fedora with 3 different target audience (this
is how I understand them):
- One for the files in the git repository, meant to be "consumed" by our
fellow packagers, not meant to leave the Fedora infrastructure
- One in the spec file describing the changes applied to it. This one is meant
to be accessible to sysadmins who want to know/check what changed in a package
- One in bodhi, meant for end-user consumption and which should give some
explanation as to why the package was updated or where information about the
update can be found
So we need to, somehow, merge two changelogs into one while realizing that some
information in one may not be desirable in the other (for example the world
famous commit message: "oops I've forgot to upload the sources" does not need to
appear in the RPM's changelog).
Would it be easier to merge the git changelog with the spec changelog or the
spec changelog with the bodhi notes?
For the former one easy way to achieve this is to consider all the commits since
the last successful build and have a magic keyword to either include or exclude
a commit message in the changelog.
For the latter, we discussed the idea of using annotated git tags this fall.
Both have their pros and cons, do people have some experience with either and
could share their feedback?
Is there a different approach, e.g. by using towncrier[1] or something
comparable, to track changes outside the spec file?
To give some context to this discussion, the CPE team is moving toward quarterly
planning and for the first months of 2020 a small team of people in the CPE team
is willing to do the work to make this happen, but there are two requirements:
- The work needs to be scoped and defined by January 20th 2020 (so we can
evaluate whether or not we have the knowledge, resources and time to do it)
- The work needs to be achievable before March 31st 2020 (cf the quarterly
objectives we're working towards)
Thus our call for input to accept or reject the idea and if the former
scope/define the system.
Thanks in advance for your help,
Pierre
[1] https://github.com/hawkowl/towncrier
4 years, 3 months
Fedora Packager Dashboard mockups
by Miro Hrončok
Hello devel,
I got nerdslipped and I ahve created some HTML only mockup of a thing that I
find very useful. A Fedora Packager Dashboard.
You can find the early mockup at:
https://hroncok.cz/packager-dashboard-mockup/
The idea is to collect some data about your packages and present them in some
nice form. Such data would be gathered by plugins. Examples on the mockup:
- active updates
- active buildroot overrides
- open PRs
- orphaned or broken depnddencies
- bugzillas
- FTBFS (from koschei)
Ideas not included in the mockup:
- running Koji builds
Let me know what you think. I can work on this on the backend level (plugin
architecture design, gathering data, cache...) but even copy pasting HTML from
Bodhi to present the mockup was very painful for me, so if we want this,
somebody with more fronted experience would need to help.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 3 months
Bubblemail: looking for package maintainer
by razer raz
Hi,
I'm the author of Bubblemail, a mail notification service providing a D-Bus interface :
http://bubblemail.free.fr
Git Repo :
https://framagit.org/razer/bubblemail
It's a brand new project coming from the fork of the mailnag project, with first goal to get it running on python3. Since then, I have rewritten almost all the code in a more modern and simplest way, get it pep8 compliant, improve stability, features and tests, and build a more modern gtk3 interface on it.
On top of that, I make the same work on the gnome-shell extension, already available on the gnome-shell extension website :
https://extensions.gnome.org/extension/2458/bubblemail/
https://framagit.org/razer/bubblemail-gnome-shell
I currently maintain myself rpm and deb packages, and I'm looking for someone for the rpm part of the task, hopping for proper Fedora integration.
It's almost pure python3 code using setuptools, I suppose it should be easy to build and maintain an rpm package for someone used with the task.
Please contact me: razerraz AT free DOT fr
4 years, 3 months
