Re: [Java related] packaging Italian ID card middleware
On Thu, Jul 18, 2024 at 5:33 PM Marián Konček wrote: > they should not even be in *any* GitHub repository unless they are used > for testing. Binary components are not sources. I would argue that these should not be included even for testing, as the recent XZ attack unfortunately reminded us... Cheers, Mario -- Mario Torre Manager, Software Engineering, Red Hat OpenJDK, Java Champion https://keybase.io/neugens 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 Mastodon: https://mastodon.social/@MarioTorre Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243, Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
I know Matthew mentioned long replies to long posts as a problem, so I'll do what on discourse would be an emoticon to sum a complex discussion: +1 Simo :) Cheers, Mario On Fri, Apr 21, 2023 at 1:22 AM Simo Sorce wrote: > > Hi Matthew, you say: "We're missing people", and I think, "who?". > And who are you going to miss if you move to discourse? > > I will be candid, I tried to use forums since the old phpBB times, it > never works for me. > I have no time to go roaming over forums except if a search engine > brings me there. > > The mailing list make messages land in my client, on which I am very > efficient, therefore I can check all messages once a day, and respond > if I find a worthy topic. > > Unless this discourse has some great mail bridge (it doesn't) or maybe > an rss feed (I do not use those at work, but I guess I could ?) So that > I can skim messages on my terms, I think I (and those like me) will be > the next "missing people". > > Btw I could make exactly the same quote about any forum that Major made > for Mailing lists, messy discussions are messy and a forum does not > make them easier to follow by any means (perhaps except for those that > chose inferior email readers). > > All that said, why waste time with this discussion? > > Your own post communicates to me (whether you intended it or not) that > in the end the thread that will be generated by this post won't matter, > because this is just a courtesy post and you already think that the > opinion of the "minority of self selected mailing list lovers and > dinosaurs" does not matter much. > > On Thu, 2023-04-20 at 17:20 -0400, Matthew Miller wrote: > > It’s time to transform the Fedora devel list into something new > > === > > -- > Simo Sorce > RHEL Crypto Team > Red Hat, Inc > > > ___ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Mario Torre Manager, Software Engineering, Red Hat OpenJDK, Java Champion https://keybase.io/neugens 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 Mastodon: https://mastodon.social/@MarioTorre Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243, Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Tue, May 10, 2022 at 11:52 PM Neal Gompa wrote: > I'm confused how this would not negatively impact the user experience, > because things like FreeType and HarfBuzz in Fedora have features and > configuration that are non-default that improve the font rendering > capabilities of applications that link to FreeType. I would rather > have our shared maintenance and evolution of font stuff be reused in > Java too... The rendering is always done in OpenJDK, those libraries are not used for the actual rendering. The generation of glyphs types and the metrics are obtained via those libraries, but it's been ages since the old patented algorithms would produce better quality, and anyway those would not be available in Fedora anyway. There are settings that influence the rendering, which is why sometimes users have worse quality on KDE vs Gnome, but those aren't settings in the libraries, are configurations such as environment variables or gnome properties. If you experience font quality differences, I would pretty much like to know, this would be a bug. They would also be very surprising though, applications such as IntelliJ bundle their own JDKs, I recall once one argument was exactly because of "better" font rendering, which is clearly not an actual argument. Btw, I know this because I fixed a gazillion font related bugs in OpenJDK in the past, most of which in the OpenJDK 6 and 7 era, I rarely ever had to touch 8 or later. Cheers, Mario -- Mario Torre Manager, Software Engineering, OpenJDK 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 Red Hat GmbH, Registered seat: Werner von Siemens Ring 14, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243, Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
OpenJDK Changed in Fedora
Hi Everyone, We are working on moving OpenJDK 17 as the system runtime for Fedora: https://fedoraproject.org/wiki/Changes/Java17 Since, like last time we did something similar, the change may have a somewhat large impact, especially on other packages, we would like to collect some feedback about the prospective timeline. Right now we are thinking about targeting Fedora 36, that is one release after the next, for this change to be effective, we can delay to 37 if it's considered a problem however (although I think most of us want to have 17 as soon as possible!). Of course, 8 and 11 aren't going away for now, they will still be around and maintained, this impacts the system default packages however and the detaulf provides for java and java-devel. I added Jiri in CC for questions. Cheers, Mario -- Mario Torre Manager, Software Engineering, core OpenJDK Red Hat GmbH <https://www.redhat.com> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]
On Fri, Oct 8, 2021 at 2:11 AM Kevin Kofler via devel wrote: > > Michal Srb wrote: > > Unlike RPM repositories, Maven repositories can easily hold multiple > > versions of libraries. Once a JAR is built, the resulting bytecode will > > work with current and future JVMs. There is no need to mass-rebuild JARs > > every 6 months. And there is certainly no need to try to run every single > > Java application with a single "system-wide" version of a library. > > And that is actually a problem rather than a solution. Maven artifacts are > basically write once only. Everything depends on a hardcoded version which, > once uploaded, is normally never touched again. This means that security > bugs and other bugs never get fixed (unless the application bumps the > dependency version, which can take months or years or even just never > happen). That is exactly what the RPM system is designed to avoid. Well, that's why it should be "curated" and not just a mirror of maven central. Cheers, Mario -- Mario Torre Manager, Software Engineering, core OpenJDK Red Hat GmbH <https://www.redhat.com> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]
On Wed, Oct 6, 2021 at 2:39 PM Mikolaj Izdebski wrote: > > On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller > wrote: > > > > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote: > > > I'm not sure what's the best solution, but I guess the number one > > > reason to have packages within the Fedora distribution is for a matter > > > of trust, if this is the case I would argue that a curated list of > > > maven packages served via a Fedora managed repository would be a > > > better investment. > > > > I'd love to see someone interested in this pursue this idea! I know we > > talked about it as long ago as... Flock Prague... and probably before. > > That's a very old idea that has been partially implemented years ago, > but never approved for use in Fedora. Maven artifacts can be built in > Koji (there is an existing "koji maven-build" command). Once built > they appear in a "curated" Maven repository hosted on Koji, that can > be synced to mirrors, from where users can consume it. Consumers of > this Maven repository don't need to be running Fedora, not even Linux. > > Curated Maven repository contains additional metadata, eg. CVEs > affecting given artifact version, whether upstream is active, whether > given artifact is available in Fedora and in which releases, etc. For > each Fedora Linux release there is an auto-generated BOM (bill of > materials POM) listing artifacts available in the release. > > Binaries from this trusted/curated Maven repository can also be > wrapped into RPMs (using "koji wrapper-rpm" command) and put into > distribution repos and composes. Other packages can depend on such > RPMs. This is a hybrid packaging model, where some Java RPM packages > can be built in the traditional way (where code is compiled during > rpmbuild) and some are built elsewhere, and only wrapped in RPMs. So the only thing left to do is to convince Mr. Fedora to approve this ;) Cheers, Mario -- Mario Torre Manager, Software Engineering, core OpenJDK Red Hat GmbH <https://www.redhat.com> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]
On Tue, Oct 5, 2021 at 10:20 PM Peter Boy wrote: > > > > > Am 04.10.2021 um 21:08 schrieb Fabio Valentini : > > > > > > But then you're back to *exactly how Fedora packages for Java projects > > already work* - only with the added complication that distributing > > those build artifacts as plain JARs instead of RPMs now makes them > > impossible to consume as dependencies from other RPM builds. > > I think, the key is "via a Fedora managed repository“, something like a > fedora.maven.central. That could make the process easier. > > Somewhere I had read on "federated repository“ as a specific narrow > defined cooperation with distributions or projects with similar principles as > Fedora. Yes, also distributing jars via maven is a lot simpler than having to package them (even if just wrapped) as RPM, so there's a lot of saving just by that. Those jars could be rebuilt from source, including their transitive deps, or just a mirror of maven central if we trust the upstream (and in many cases we do, i.e. for things coming from Eclipse.org or Apache). The infrastructure, I can't hardly think of this as an additional burden, we have already hosted and built every single distribution since the beginning of time, including those same jars in an RPM form. Cheers, Mario -- Mario Torre Manager, Software Engineering, core OpenJDK Red Hat GmbH <https://www.redhat.com> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 💔 Java: The Death of Two SIGs
On Mon, Sep 27, 2021 at 5:23 PM Fabio Valentini wrote: > I'm not sure about this (the internals of Red Hat are quite opaque), > but as far as I know, are two different, non-overlapping teams > involved here: > One that maintains OpenJDK packages (which are fine), and one that > maintains Java packages (which have been dying in Fedora for years). > (I'm sorry If I am misrepresenting the situation inside Red Hat, but > this the extent of my knowledge.) I think this is because different teams do different things and projects and contributions to Fedora are generally driven by individuals that follow up on their main projects and maintain them for Fedora, so it's more than "two" but probably a lot less than "teams" :) This makes sense, since Fedora is a community effort. Cheers, Mario -- Mario Torre Manager, Software Engineering, core OpenJDK Red Hat GmbH <https://www.redhat.com> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 💔 Java: The Death of Two SIGs
On Sun, Sep 26, 2021 at 10:36 PM Christopher wrote: > > I think part of the problem is that Java is too big. There are too > many libraries to fit into a single community. I think there's > probably willing volunteers to maintain some libraries and application > packages, but these are not necessarily the same people willing to do > all the work of maintaining OpenJDK packages or the whole Eclipse > stack. > > When modularity took out the whole Java stack, it did a lot of lasting > damage that is going to be hard to recover from. In order for the vast > majority of Java packagers to return, there needs to be a reliable > base. I'm thinking OpenJDK (which I think is reliably maintained right > now) and XMvn. Java packagers who might be willing to support a lot of > the rest of the libraries (guava, commons-*, etc.) need to be able to > rely on those core components being stable first. Then, when that > trust is restored, I'm sure end-user applications will trickle in. > > Right now, I'm not sure there's adequate expertise to reestablish > trust in the Java core tools for Java packagers to start coming back. Just my 0.2 euro cents here. The OpenJDK packages are well maintained, in fact, the packaging work and their updates are done by the very same team that participate to the upstream OpenJDK development. Regarding Eclipse, it's really a lot of work and I understand this, so effort moved toward a flatpack version of it. I'm not sure this saves anything, and in my experience it actually introduces some problems, but the Eclipse maintainers have a different opinion and I think we should trust their judgment. However the majority of people just usually download Eclipse (or IntelliJ for what matters) from the upstream website anyway, further suggesting that maintaining Eclipse is not really a rewarding nor useful task. For maven, I don't think anyone really relies on installed packages other than a few (mostly because of cross/transitive dependency reasons), so I'm not sure if there is any real benefit in having packagers spending resources and time to maintain packages that inevitably go out of sync. I'm not sure what's the best solution, but I guess the number one reason to have packages within the Fedora distribution is for a matter of trust, if this is the case I would argue that a curated list of maven packages served via a Fedora managed repository would be a better investment. For that to work we need a solid distribution of OpenJDK (which we have) and a solid distribution of maven (which we also have). Cheers, Mario -- Mario Torre Manager, Software Engineering, core OpenJDK Red Hat GmbH <https://www.redhat.com> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intent to orphan JDK Mission Control
Thanks Alex for the hard (and often thankless) work in maintaining those packages for so much time! Cheers, Mario On Thu, Jun 17, 2021 at 5:46 PM Alex Macdonald wrote: > > Hi everyone, > > I am writing to let everyone know that JDK Mission Control (JMC) and > it’s dependencies will be orphaned in Fedora by the end of tomorrow > (June 18th). This encompasses packages owned by both myself (almac) > and jkang, and includes the jmc and jmc-core packages along with the > dependencies we currently maintain. > > This includes packages owned by: > > almac, 4: > - jakarta-activation > - jakarta-mail > - mvel > - lz4-java > > jkang, 8: > - felix-scr > - directory-maven-plugin > - HdrHistogram > - jaf > - jmc > - modules/jmc > - jmc-core > - owasp-java-encoder > > I’ll be co-ordinating the orphaning of these packages by the end of > tomorrow. In their place, I have created a couple of copr repositories > containing rpm wrappers for AdoptOpenJDK’s JMC builds, which can be > used to install and use their JMC builds in Fedora. I currently have a > repo for the JMC 8.0.0 release > (https://copr.fedorainfracloud.org/coprs/almac/jmc8/) and a repo for > snapshot builds > (https://copr.fedorainfracloud.org/coprs/almac/jmc-snapshot/). > > Regards, > > Alex > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Mario Torre Manager, Software Engineering Red Hat GmbH <https://www.redhat.com> 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Future of the Java Stack (also regarding ELN and RHEL)
On Fri, Sep 11, 2020 at 11:04 AM Hans de Goede wrote: > So for this tomcat needed for testing problem, I'm thinking that we > might solve this in a very non Fedora way. Why not bundle the old > tomcat-sources with the sources which need it for their test-suite > (and build it before running the tests). To be honest, when I look at this example, I think we shouldn't have that library/application packaged at all. If something can't even run the tests without requiring a 12+ year old obsoleted code/infrastructure, what chances are that it's maintained correctly? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com> 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
The Future of the Java Stack (also regarding ELN and RHEL)
I think there's a difference between libraries and applications though. I for one think that not having Eclipse packaged in Fedora/RHEL etc.. would be a big loss, the same goes for Mission Control which we maintain On Wed, Sep 9, 2020 at 5:00 PM Aleksandar Kurtakov wrote: > > > > On Wed, Sep 9, 2020 at 5:33 PM Stephen John Smoogen wrote: >> >> >> >> On Wed, 9 Sep 2020 at 09:37, Björn Persson wrote: >>> >>> Guido Aulisi wrote: >>> > IMHO we could package only the JDK and let the user use Java software directly from upstream. >>> > Usually upstream means Apache, which is a trusted source, and Java users are smart enough to manage the Java packages. >>> > I usuali do so when using maven, hadoop, tomcat, etc. >>> > I think this solution could be valid for any other language, like php, python: packaging only the base language and anything that is not available in executable formats. >>> >>> And how well does that scale? >>> >> >> It doesn't scale.. but neither does having all those packages owned and looked at by 1 person. Either people need to start helping or this is the future. People have instead spent the last decade usually saying 'I need this but have no idea how to maintain it so you can't get rid of it.' That has led to the point where the people who were trying to do this made it into modules to make their lives easier and when that made other people's lives harder.. deciding that it was an unwinnable game so why participate any longer. > > > Couldn't agree more!!! From big proponent of RPM packaging I went to the "meh, who cares" group - because I see more and more things coming our way for maintenance so the choice in front of us is "work on upstream Eclipse" or "keep Eclipse RPM packages". One can easily guess what wins. > >> >> >> The cost of free packages is eternal vigilance on their maintenance. >> >> >>> >>> As a sysadmin I don't normally need to know what language each program >>> is written in. I use language-specific tools only on programs I'm >>> developing, not on programs I merely use. Should I periodically run >>> cpan to check for Perl program updates, pip to check for Python program >>> updates, npm to check for Javascript program updates, gem to check for >>> Ruby program updates, and so on and so forth? And then manually check a >>> bunch of individual upstream websites for updates to programs that >>> aren't in those language-specific repositories either? No way! I run >>> "yum update" and get *all* the updates for my system. >>> >>> Björn Persson >>> ___ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: https://docs.fedoraproject. org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: https://lists.fedoraproject. org/archives/list/devel@lists.fedoraproject.org >> >> >> >> -- >> Stephen J Smoogen. >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: https://docs.fedoraproject. org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists. fedoraproject.org > > > > -- > Alexander Kurtakov > Red Hat Eclipse Team > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject. org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists. fedoraproject.org -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com>;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: Package uses Gradle (retired) to build: what to do?
The problem with Gradle as far as I'm aware is that it's a moving target. It insist on updating itself when you have an incompatible version and versions tend to break compatibility a lot, with new features added often, all of which makes impossible for a Linux distribution to keep up realiably. Cheers, Mario On Sat, Feb 8, 2020 at 12:23 PM Ankur Sinha wrote: > > Hello, > > netcdf-java[1] uses the Gradle build system, and is required to update > hdfview[2] to the latest version. Gradle, however, was retired[3] as > "out of date, broken, fails to build, basically unmaintainable". > > Now, I know that following our system, one must package Gradle first but > given the retirement comment, packaging and then maintaining it does not > appear a simple task, and for one dependency only, it seems overkill. > > Is there perhaps a way of bypassing that somehow? For example, is there > a way to use good old Maven to build a Gradle based project? > > [1] > https://docs.unidata.ucar.edu/netcdf-java/5.2/userguide/building_from_source.html > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1797361 > [3] https://src.fedoraproject.org/rpms/gradle/blob/master/f/dead.package > > -- > Thanks, > Regards, > Ankur Sinha "FranciscoD" (He / Him / His) | > https://fedoraproject.org/wiki/User:Ankursinha > Time zone: Europe/London > ___ > 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 <https://www.redhat.com> 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: Any plans on maintaining Apache NetBeans
On Wed, Feb 5, 2020 at 2:41 PM Fabio Valentini wrote: > > > Currently impossible due to completely broken Java stack in Fedora. > > > > When I read this I'm always puzzled by the negativity. > > > > What is "completely broken" exactly that you need? Things seem to work > > quite well. > > The problem is that the current "work[s] quite well" situation relies > entirely on a small number of volunteers (including me), who don't > even want to maintain Java packages. > If I alone decide to finally give up on Java packages in fedora > (because why not?), you can say goodbye to almost 200 Java packages > (not including dependencies). First of all, thank you for your work! I know it may not mean much but it is appreciated. On a general side, I would say, however, that this is the nature of every collaborative effort, isn't it? Also, I can only speak for JMC (since my team owns this) and for OpenJDK (since I'm part of the OpenJDK team an Jiri own this), and I know the base is sound. And we aren't required to do any of this work, but we do it because we want to have Fedora a great platform for Java development, so we put efforts in ensuring that OpenJDK (and JMC) are packaged correctly. Also, there is always the risk that someone leaves to do better things, but this doesn't mean "completely broken" (otherwise why haven't the packages been retired?), so I think my first question is still valid. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com> 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: Any plans on maintaining Apache NetBeans
On Wed, Feb 5, 2020 at 9:22 AM Vitaly Zaitsev via devel wrote: > > On 05.02.2020 05:05, Code Zombie wrote: > > Is Fedora considering to add it to its packages? Does anyone already > > plan to maintain it or can I take it over? > > Currently impossible due to completely broken Java stack in Fedora. When I read this I'm always puzzled by the negativity. What is "completely broken" exactly that you need? Things seem to work quite well. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com> 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
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 <https://www.redhat.com> 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
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 <https://www.redhat.com> 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
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 <https://www.redhat.com> 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
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 <https://www.redhat.com> 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: Attention Gmail users, please turn off HTML mail
On Mon, Apr 15, 2019 at 10:11 AM Richard W.M. Jones wrote: > > On Tue, Oct 02, 2018 at 12:55:12PM +0200, Igor Gnatenko wrote: > > On Tue, Oct 2, 2018 at 12:50 PM Dominik 'Rathann' Mierzejewski < > > domi...@greysector.net> wrote: > > > > > Dear developers, > > > > > > > Hello, Dominik ;) > > > > sorry for a slightly off-topic post, but I've noticed that a significant > > > number of posters is sending HTML e-mail to this list (not to mention > > > top-replying), which generates unnecessary network traffic. Some people > > > pay for every bit downloaded, so they're paying for the same information > > > twice, because the e-mails are sent with multipart/alternative format, > > > which contains BOTH text/plain and text/html. One thing I noticed those > > > senders have in common is that they use Gmail. > > > > > > So, a plea to Gmail users: please stop sending HTML e-mail to Fedora > > > mailing lists. > > > > > > > I'm sending you this HTML email because Google dropped possibility to send > > plaintext emails. Sorry =( It seems to randomly change the settings over time, however there's a way to do so, in the bottom corner of the reply textfield, next to trash icon, there's a menu. If you click on that you will have access to the "plain text mode" option. > At least it's sending a proper text/plain alternative. > > I've seen far worse, such as corporate mail systems that send a snotty > message along the lines of "install an HTML-capable email reader" as > the text alternative. Clue for those developers: If your software is > too stupid to create a text alternative, don't send one at all. Well, yeah, but some people don't really have a choice and it would be unfair to ask them not to contribute because we don't like HTML mailers (which is a problem, I agree, but shouldn't be discriminatory). Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com> 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On Tue, 2015-02-24 at 18:22 +0100, Mikolaj Izdebski wrote: > On 02/24/2015 05:21 PM, Mario Torre wrote: > > On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote: > >> On 02/24/2015 02:15 PM, Jiri Vanek wrote: > >>> On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote: > >>>> I am against official guidelines or policy for legacy JDK packages. I > >>>> don't think that any such policy is needed and it would only encourage > >>>> adoption of old packages for which there might be no security updates. > >>> > >>> Well thats the point - people are calling for them. And wont to maintain > >>> them with this risk. > >> > >> I thought that the point of this change proposal was "enabling community > >> to maintain legacy JDKs", not encouraging people to package them without > >> good reason or without involvement to truly maintaining them. Packaging > >> older JDKs is *already* possible, so IMHO this change accomplishes > >> nothing but showing people how they can dump old, unmaintained software > >> into Fedora. > > > > Well, in this case it would not be un-maintained, the Fedora package > > would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we > > are still actively contributing to the upstream software in its various > > versions. While you as a packager cannot specifically count on that, > > there's still a level of confidence that the base software won't be > > abandoned any time soon. And even when we will stop supporting those > > older versions, the community will take over if there is a need for > > that, exactly like we have done ourselves before. > > > > Indeed, there's an overhead for the downstream maintainers, we may need > > to drop specific version of OpenJDK, or skip a release, or do other > > funny things and the Fedora maintainers will have to adapt, but this is > > no different than usual I believe. Realistically, we are so conservative > > with older JDKs that I doubt this will ever really be an issue. > > Correct me if I am wrong, but in my understanding maintaining JDK > package requires a lot of ongoing work (including obtaining and applying > patches, running TCK, pushing updates in timely manner and so on). JDK > maintainers should know this and I'm assuming that the amount of > required work is the main reason for them not wanting to maintain older > JDKs. > > The work required to add old JDK package to Fedora is relatively small > compared to ongoing maintenance work. Someone willing to truly maintain > JDK in Fedora should have knowledge about JDK packaging and they > shouldn't have problem finding time to come up with a working solution, > proposing and discussing it. Indeed, but don't underestimate this "relatively", which is the main reason why *we* won't do that. > If you make the process of adding legacy JDKs to Fedora too easy then > someone without enough time and required knowledge will surely do that > and we may easily end with unmaintained package. I'd rather not have old > JDK than have unmaintained JDK with security holes. I don't see how giving proper rules means making something like that "easy". The fact is that making things artificially complicated just to scare off people from doing them doesn't really match with my view of Freedom. I think instead that rules, however complex for the matter at hand, should be crafted so that they impose the minimum possible overhead. In this case, it's about giving users one thing they asked, which is easy access to a previous version of Java. We can't afford maintaining it as Java Team, but this doesn't mean we will refuse to help people doing it. In fact, the exact existence of this very same discussion is our attempt to pass the ball back to the Community. > >> Package that doesn't pass review shouldn't be part of Fedora. > > > > Well, if your goal is to reduce the user base of Fedora, I'm sure we can > > talk about removing the JDK :) > > We can't sacrifice our basic principles (such as passing review) for the > sake of increasing user base. If you put the mean before the end, yes. But I hope you will agree with me that one of those core principles *is* the Freedom of allowing users to use such a critical tool as Java for their own daily reasons *without* forcing them to switch distribution. While I see your point that this can be extended to anything (why don't we package an older Eclipse?) so we need to draw a line, I believe an important core component like the JDK falls in that category of things that should be allowed to coexist even a bit longer than originally intended. Now, the question is how to make this happens by preserving both quality and freedom. Cheers, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On Thu, 2015-02-26 at 09:00 +0100, Jiri Vanek wrote: > On 02/24/2015 08:36 PM, Sumit Bhardwaj wrote: > > Hi All, > > > > I have been reading this mail chain for some time and there is something I > > wanted to say. It's kind > > of a long mail, I apologize for taking so much of your time but request you > > to please bear with me. > > I work as a technical consultant on IBM WebSphere, IBM BPM, Java/J2EE and > > Python technology stacks, > > who has to code on Java/J2EEquite often as well and I use Fedora 21 > > Workstation as my primary OS. My > > field of work is such that I need to use JDK versions 1.4, 5, 6, 7 and 8, > > all from time to time. > > This is because as time passed, solutions delivered to customers were built > > using incremental > > versions of Java/J2EE specifications and were not frequently upgraded. In > > my role, the changes/fixes > > I do to these enterprise apps are usually small and require only a certain > > jar file to be > > recompiled, or in some cases only one class. In such cases, maintaining > > binary compatibility is a > > must and for that I need to recompile that one jar/class with the original > > version of JDK that was > > used to compile the rest of the project in the first place. > > > > I use Oracle java in most cases due to corporate policies (for personal > > use, I use the latest > > version of OpenJDK). Now as per Oracle's policy, which I am sure is similar > > for OpenJDK as well, a > > particular version of JDK/JRE is updated till and even some time after the > > next major version is > > released, and then at a certain Update level, Oracle stops supporting it. > > That update version > > becomes the final update for that particular major release, and is sent > > into archives, while updates > > keep on getting released for the current version. > > > > With Oracle JDK, there are two installation approaches available for RPM > > based systems. They provide > > an RPM package which installs java in /usr/java, i.e. in system area and > > the latest installed java > > version become default. However, they also provides tarballs of JDKs, that > > contain certain standard > > directory structure of JDK intact inside one folder. These tarballs can be > > extracted and placed in > > any place on file system and once JAVA_HOME is pointed towards these+PATH > > is locally updated to > > include it, user can basically use this JDK without any issues. What > > version of Java is installed in > > system as default, in system area (/usr/java) become irrelevant. > > > > With IDEs like Eclipse and NetBeans the process is even simpler, as you can > > define these individual > > folders as JDKs for particular API versions in IDE configuration > > permanently and while creating a > > project can choose to use any of these "defined JDKs". This is the approach > > that I take. I have the > > last updated versions of all the JDKs from 1.4 to 8 in my /opt folder. I > > have these configured in > > Eclipse and NetBeans for each API version and I use them all as required by > > the project. > > > > So I guess if OpenJDK can follow the same approach and can give an option > > to download tarballs of > > older versions and use them in place, without requiring any installation, > > as a definite directory > > structure, then the problem is solved. There is no need to maintain old > > version per se in > > repositories, as these are not updated anymore and the user will be able to > > use multiple versions > > without conflict of any kind. As for the default JDK, it can be kept how it > > is now i.e. The latest > > available JDK can be maintained in Fedora repos as they are being > > maintained now and updates can be > > provided for the defined lifetime of that JDK. > > > > Let me know what you guys think about this approach. > > > > This is lying on openjdk table for long time to have at least source > tarballs... As you can see, > nothing,. However once you are able to build jdk on your own, nothing > prevents you form mercurial > clone of *any* version. So this is the way you should go. > > If you wont binary images to be supported by openjdk itself, its completely > different and more > complex story. Indeed, and for that you need to go to an OS that supports long term stability, like RHEL or Centos (playing in house, but you have other choices). Fedora is not really good for that, since it promotes bleeding edge code over long term stability. Cheers, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote: > On 02/24/2015 02:15 PM, Jiri Vanek wrote: > > On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote: > >> I am against official guidelines or policy for legacy JDK packages. I > >> don't think that any such policy is needed and it would only encourage > >> adoption of old packages for which there might be no security updates. > > > > Well thats the point - people are calling for them. And wont to maintain > > them with this risk. > > I thought that the point of this change proposal was "enabling community > to maintain legacy JDKs", not encouraging people to package them without > good reason or without involvement to truly maintaining them. Packaging > older JDKs is *already* possible, so IMHO this change accomplishes > nothing but showing people how they can dump old, unmaintained software > into Fedora. Well, in this case it would not be un-maintained, the Fedora package would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we are still actively contributing to the upstream software in its various versions. While you as a packager cannot specifically count on that, there's still a level of confidence that the base software won't be abandoned any time soon. And even when we will stop supporting those older versions, the community will take over if there is a need for that, exactly like we have done ourselves before. Indeed, there's an overhead for the downstream maintainers, we may need to drop specific version of OpenJDK, or skip a release, or do other funny things and the Fedora maintainers will have to adapt, but this is no different than usual I believe. Realistically, we are so conservative with older JDKs that I doubt this will ever really be an issue. > >> Currently anyone is allowed to maintain legacy JDKs in Fedora according > >> to general rules, so this change proposal does not "enable" maintenance > >> of legacy JDKs. > > > > It is not true. We were killing old packages withut handling the > > owenership or maintainerships to others. > > Why this is not true? What prevents me from reviving java-1.6.0-openjdk > or java-1.7.0-openjdk in Fedora and making it available in rawhide? If I > wanted could just follow standard process and bring it back any time. You may be able to do that, but you should be careful to not break existing functionality or you're attract the wrath of your own users! Changes should be carefully pondered, so defining a process for such thing to go smooth is not a bad thing. > >>> === Proposed rules === > >>> 0. '''Main JDK maintainers are not never ever responsible for any > >>> legacy jdk. > >>> This must remain clear''' > >> > >> Package maintainers are responsible for their packages. If maintainer of > >> "main JDK" is also maintaining "legacy JDK" then (s)he should be > >> responsible for both of them. I don't see why any special rule should be > >> defined. > > > > As I higlighted - we - main jdk team - are never ever going to do so. > > Imagine that someone become comaintainer of "main JDK". This rule would > prevent him from maintaining (and "being responsible") for older JDK. > This limits people's freedom and that's why I am against that. I really fail to see in what way this is limiting people freedom to do anything, a process is just a way to organise work, is a mean, not the end goal in itself, and to what I'm able to judge the proposed process makes mostly sense. > >>> 6. as it is generally not new package, the review process > >>> '''should''' be only > >>> formal - to know maintainer and to create cvs repo > >>> 1. this is quite important, otherwise the new maintainer can become > >>> really > >>> frustrated, and we are forcing the "dead" package over"orpahned" so > >>> the full > >>> review (especially in alignment with rule 5) really should not be > >>> forced. > >>> 2. on the contrary, rules agreed here '''must''' be checked. (even > >>> the > >>> number 5) > >> > >> Currently all compat packages must complete full review before being > >> introduced. Why JDK should be treated specially? I think that with > >> complex system of virtual provides, alternatives and strict directory > >> layout it's necessary to fully review "legacy JDK" package to make sure > >> it doesn't conflict with primary JDK and that it is integrated with > >> Fedora as expected. > > > > Well the jdk - as is now - will never pass regular review - it is > > handling config files and libraries and shared jars really differently - > > and have good purposes for it. > > Package that doesn't pass review shouldn't be part of Fedora. Well, if your goal is to reduce the user base of Fedora, I'm sure we can talk about removing the JDK :) Cheers, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On Tue, 2015-02-24 at 15:19 +0100, Jiri Vanek wrote: > On 02/24/2015 02:58 PM, Dominik 'Rathann' Mierzejewski wrote: > > On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote: > > [...] > >> There were several attempts in past like "can you please support jdk > >> 7,6...in newer fedoras" and we always told no. When come speech about "do > >> it > >> on your own" suddenly many questions marks raised up. > >> > >> The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137 > >> the guy is willing to maintain it. > > > > Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk > > and its successors. You shouldn't arbitrarily block people from > > re-introducing an older branch of any package back into Fedora in the > > first place. > > > We can not do it. It will keep legacy jdks in users system. We don't wont > 99% of users to keep > (unwillingly and unknowingly) old jdks. 99% of users is hepy with one - main > - jdk. To provide new > jdk , we have to obsolate old jdk... > > If you have workaround for this, please share. (Sewerin already higlighted it > on devel discussion). > I'm not an expert so probably I'm saying something wrong, but can't we have -compact packages like we do with other libraries, and then handle the compact libraries similarly to what the kernel does (that is, older version are not wiped)? Maybe I'm missing the obvious, but this seems to me like being drunk while still having the barrel full :) Cheers, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Gnome-shell workspaces
Il giorno dom, 10/02/2013 alle 14.47 +0100, Olav Vitters ha scritto: > On Sun, Feb 10, 2013 at 01:28:54PM +0100, Trond Hasle Amundsen wrote: > > Christopher Meng writes: > > > > > Somewhat funny that many users even don't know this tweak tool and ask > > > everywhere about this.. > > > > I always found it odd that gnome-tweak-tool even exists.. some > > functionality are found in the system settings, some in > > gnome-tweak-tool. If you ask me, gnome-tweak-tool should be part of the > > standard system settings. Call it "advanced shell options" or > > something. It would be easier for users to find, provide a more > > consistent GNOME experience, and ultimately happier users. > > This has been addressed various times. In brief: Advanced buttons do not > work. They'll be clicked every time. Tweak tool provides a different > guarantee of stability. For instance: if you change an option in System > Settings and it results in a bug it must be fixed asap. This argument is foo bar. If advanced buttons would be clicked any time... then it means users *want* to tweak those features, they should be integrated in the core preferences. Why should I ever need to install a separate tool to fix my font settings or to add back buttons to the otherwise useless and space wasting window bar? Gnome 3 is not an experimental desktop anymore, it's been around for some time and it's the default desktop in Fedora... it's about time to fix it [1]. Cheers, Mario [1] This is my opinion, at least. And note, this is not to flame. I do like *some* features of Gnome 3 more than any other desktop, it has great potential, I just think it's greatly unexpressed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell workspaces
Il giorno lun, 11/02/2013 alle 11.12 +0100, Olav Vitters ha scritto: > On Sun, Feb 10, 2013 at 03:03:44PM +0100, Kevin Kofler wrote: > > Having a separate "tweak tool" is a lame workaround for lack of settings in > > the official tools. The only reason such "tweak tools" exist on proprietary > > operating systems is because the proprietary companies don't want to > > officially support some functionality, so you need a third-party tool to > > enable the hidden settings. Having an "official tweak tool" is really > > really > > silly. > > I don't get why you reply to me. It seems anything people do is just > bad. > > No tweak tool: bad > A tweak tool: bad > > If the only thing you can do is complain about the work that other > people do, find another hobby or something. This argument doesn't really work, either. Cheers, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On Tue, 2012-07-10 at 10:38 -0700, Toshio Kuratomi wrote: > kcoloredit I think I've missed some mails, but this is a very useful application, is there any alternative? Cheers, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On Thu, 2012-06-07 at 14:34 -0500, Chris Adams wrote: > that would not allow custom kernel and such. Don't support the locked > down platform; the answer to "Fedora on ARM" is "don't buy a Win8 ARM > system and expect to run Fedora". One should be very, very careful with sentences like this one. With more and more machines turning to ARM, simply dismiss it as a "don't buy a Win8 ARM" *may* possibly work right now, but it will turn against us in the future. You don't need to be an Oracle to see where all of this is going. Cheers, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need git repository for approved package
Il giorno gio, 03/05/2012 alle 08.17 -0500, Jon Ciesla ha scritto: > On Thu, May 3, 2012 at 7:55 AM, Daniel P. Berrange > wrote: > > On Thu, May 03, 2012 at 02:41:55PM +0200, Mario Torre wrote: > >> Hello all! > >> > >> I need to close this bug report asap: > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=816926 > >> > >> Since I have few more packages in the pipe and the process takes usually > >> quite some time, and I'm already waiting since yesterday, can someone > >> please look at it? > >> > >> I'm very sorry to put pressure, I'm sure everybody is uber busy for the > >> release, so forgive me for this, but I'm afraid we won't get the other > >> packages in in time (me and my team have 6 more in the loop, and they > >> depend on each other, and time is ticking fast). > > > > The admins run a script to process pending requests with fedora-cvs=? set > > at least once a day, so I expect your BZ should get processed pretty soon. > > Done. > > I usually do it several times a day, Monday through Friday, and > usually once or twice on weekends. There are several of us who do, so > it usually doesn't take long. It's not a task that can be fully > automated. > > -J Hi Jon, Daniel, Thanks a lot! Cheers, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Need git repository for approved package
Hello all! I need to close this bug report asap: https://bugzilla.redhat.com/show_bug.cgi?id=816926 Since I have few more packages in the pipe and the process takes usually quite some time, and I'm already waiting since yesterday, can someone please look at it? I'm very sorry to put pressure, I'm sure everybody is uber busy for the release, so forgive me for this, but I'm afraid we won't get the other packages in in time (me and my team have 6 more in the loop, and they depend on each other, and time is ticking fast). Thanks a lot! Cheers, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fest Swing: Package review and sponsoring required. Was: Self Introduction
Il giorno mer, 25/04/2012 alle 18.36 +0200, Mario Torre ha scritto: > Hello all! > > I'm trying to package Fest for Fedora, and I need a sponsor for this > first package: > > https://bugzilla.redhat.com/show_bug.cgi?id=816264 > > This is my first package, but I'm not new to Fedora, I recently joined > Red Hat, after many year of Free Software work with other companies, > I've been using Fedora since Fedora Core 1, and before that I was a Red > Hat Linux user (since 6.0!). > > During the years, I've contribute some fixes here and there in Fedora > packages (although mostly upstream), but this is my first attempt at > packaging a full rpm set of packages. > > Cheers, > Mario Hello all! I added few more packages, they are all needed for Fest Swing: https://bugzilla.redhat.com/show_bug.cgi?id=816264 https://bugzilla.redhat.com/show_bug.cgi?id=816926 https://bugzilla.redhat.com/show_bug.cgi?id=816927 https://bugzilla.redhat.com/show_bug.cgi?id=816957 https://bugzilla.redhat.com/show_bug.cgi?id=816962 https://bugzilla.redhat.com/show_bug.cgi?id=816967 Can somebody please give a look at them? Thanks, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hello all! I'm trying to package Fest for Fedora, and I need a sponsor for this first package: https://bugzilla.redhat.com/show_bug.cgi?id=816264 This is my first package, but I'm not new to Fedora, I recently joined Red Hat, after many year of Free Software work with other companies, I've been using Fedora since Fedora Core 1, and before that I was a Red Hat Linux user (since 6.0!). During the years, I've contribute some fixes here and there in Fedora packages (although mostly upstream), but this is my first attempt at packaging a full rpm set of packages. Cheers, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
