Re: Re-Launching the Java SIG

[Jhordy Caceres]

Excellent!

This is what I needed, I was thinking of starting as a Java packager, specially 
for the apache-rat package. I'd like to know your opinion on the package or 
some (other) recommendation.
___
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: Re-Launching the Java SIG

[Jhordy Caceres]

Very Thank You!

Of course, You can count on me for anything. I'll try to help where I can.
___
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: Re-Launching the Java SIG

[Didik Supriadi]

On 9/13/21 8:41 PM, Jhordy M. Caceres Guerra wrote:


Hello!

Hi!

I'm new here, but I would like to be part of this group, I have a little 
knowledge of Java and I think I can be helpful for the group's goals.


That would be very helpful considering the states of java (packages) in 
Fedora!


I'm a java packager and I think I can offer you with some guides to 
begin with your journey, if you want to be a packager, that is.


Feel free to contact me via email or IRC: didiksupriadi41 :)


Note: I know this thread is old, but I didn't know how to join this group, 
because this group has no sponsors.


See [1].

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4EHBACT4I263R4QF75HB3DUJWWANGHAS/


--
Regards,
Didik Supriadi (he/him)



OpenPGP_0x9DF1FD914CDC3F3B.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Re-Launching the Java SIG

[Peter Boy]

> Am 13.09.2021 um 15:41 schrieb Jhordy M. Caceres Guerra 
> :
> 
> Hello!
> 
> I'm new here, but I would like to be part of this group, I have a little 
> knowledge of Java and I think I can be helpful for the group's goals.
> 
> Note: I know this thread is old, but I didn't know how to join this group, 
> because this group has no sponsors.


I very much appreciate your initiative. It inspired me to try to ignite a 
discussion about Empowering Fedora Java on the Java list. Maybe you could 
contribute. ___
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: Re-Launching the Java SIG

[Jhordy M. Caceres Guerra]

Hello!

I'm new here, but I would like to be part of this group, I have a little 
knowledge of Java and I think I can be helpful for the group's goals.

Note: I know this thread is old, but I didn't know how to join this group, 
because this group has no sponsors.
___
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] Re: Re-Launching the Java SIG thread

[Fabio Valentini]

On Tue, May 19, 2020 at 11:19 AM Ankur Sinha  wrote:
>
> On Tue, May 19, 2020 10:44:05 +0200, Fabio Valentini wrote:
> > 
> >
> > Good Morning!
> >
> > We were planning to discuss this from the Stewardship SIG point of
> > view during today's meeting, and I didn't want to announce any plans
> > before that.
> >
> > However, my suggestion would be to do the following things:
> >
> > 1. determine a core set of packages that's required for a functional
> > java → RPM toolchain
> >
> > This will include ant, maven, some core maven plugins,
> > javapackages-tools, xmvn, and all the dependencies of those packages.
> >
> > 2. start moving those packages into the @java-maint-sig
> >
> > I'd like to do some basic sanity checks when doing that, for example
> > checking upstream release history, unnecessary dependencies,
> > possiblitiies to drop unused functionality, etc. Most packages that
> > are required for building RPMs from Java projects (maven, maven
> > plugins, plexus-foo, apache-commons-bar, etc.) should already be in
> > pretty good shape and mostly up-to-date.
> >
> > 3. once that basic set of packages has been moved to the SIG, we can
> > start looking at which things share Java packages as dependencies
> > (e.g. glassfish-jaxb is required by both the DogTag PKI team and the
> > Neuro SIG), and move those to the Java SIG as well, if all parties
> > want to do that.
> >
> > ---
> >
> > I'll try coming up with a roadmap for which packages to move first.
> > I'd like to do this right, so it won't be fast, but I hope we can
> > improve the Java stack in the process.
>
> Thanks, that sounds great. I look forward to the plan. You're right:
> there's no need to hurry. Much better to do it right :)
>
> Unfortunately, I have a work meeting that clashes with the stewardship
> SIG meeting, so I won't make it there today. If the work meeting
> finishes early, I will pop by to check if the stewardship meeting is
> still on.

That would be great. We'll talk about that topic last, then :)

Fabio

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

Re: [fedora-java] Re: Re-Launching the Java SIG thread

[Ankur Sinha]

On Tue, May 19, 2020 10:44:05 +0200, Fabio Valentini wrote:
> 
> 
> Good Morning!
> 
> We were planning to discuss this from the Stewardship SIG point of
> view during today's meeting, and I didn't want to announce any plans
> before that.
> 
> However, my suggestion would be to do the following things:
> 
> 1. determine a core set of packages that's required for a functional
> java → RPM toolchain
> 
> This will include ant, maven, some core maven plugins,
> javapackages-tools, xmvn, and all the dependencies of those packages.
> 
> 2. start moving those packages into the @java-maint-sig
> 
> I'd like to do some basic sanity checks when doing that, for example
> checking upstream release history, unnecessary dependencies,
> possiblitiies to drop unused functionality, etc. Most packages that
> are required for building RPMs from Java projects (maven, maven
> plugins, plexus-foo, apache-commons-bar, etc.) should already be in
> pretty good shape and mostly up-to-date.
> 
> 3. once that basic set of packages has been moved to the SIG, we can
> start looking at which things share Java packages as dependencies
> (e.g. glassfish-jaxb is required by both the DogTag PKI team and the
> Neuro SIG), and move those to the Java SIG as well, if all parties
> want to do that.
> 
> ---
> 
> I'll try coming up with a roadmap for which packages to move first.
> I'd like to do this right, so it won't be fast, but I hope we can
> improve the Java stack in the process.

Thanks, that sounds great. I look forward to the plan. You're right:
there's no need to hurry. Much better to do it right :)

Unfortunately, I have a work meeting that clashes with the stewardship
SIG meeting, so I won't make it there today. If the work meeting
finishes early, I will pop by to check if the stewardship meeting is
still on.

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


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: [fedora-java] Re: Re-Launching the Java SIG thread

[Fabio Valentini]

On Tue, May 19, 2020 at 10:13 AM Ankur Sinha  wrote:
>
> On Tue, May 12, 2020 18:45:12 +0200, Fabio Valentini wrote:
> > On Tue, May 12, 2020 at 6:17 PM Igor Raits
> >  wrote:
> > > Count me in! I don't think I can help much, but at least can give some
> > > suggestions.
> > >
> > > > Let's make this happen.
> > >
> > > Good luck, Fabio!
> >
> > Thanks! Every bit of help counts.
> > You should now be all set with FAS group / pagure project / mailing
> > list subscription.
>
> I've picked a suitable point to fork the thread back to a Java SIG
> related conversation (added "thread" at the end of the subject to help
> people differentiate).
>
> Fabio,
>
> Is there a TODO list somewhere so we new members can take up tasks from
> to help you out? This ticket perhaps? It's filed at the Stewardship
> SIG's pagure project, so I wasn't sure if the Java SIG folks are aware
> of it yet:
>
> https://pagure.io/stewardship-sig/issue/89

Good Morning!

We were planning to discuss this from the Stewardship SIG point of
view during today's meeting, and I didn't want to announce any plans
before that.

However, my suggestion would be to do the following things:

1. determine a core set of packages that's required for a functional
java → RPM toolchain

This will include ant, maven, some core maven plugins,
javapackages-tools, xmvn, and all the dependencies of those packages.

2. start moving those packages into the @java-maint-sig

I'd like to do some basic sanity checks when doing that, for example
checking upstream release history, unnecessary dependencies,
possiblitiies to drop unused functionality, etc. Most packages that
are required for building RPMs from Java projects (maven, maven
plugins, plexus-foo, apache-commons-bar, etc.) should already be in
pretty good shape and mostly up-to-date.

3. once that basic set of packages has been moved to the SIG, we can
start looking at which things share Java packages as dependencies
(e.g. glassfish-jaxb is required by both the DogTag PKI team and the
Neuro SIG), and move those to the Java SIG as well, if all parties
want to do that.

---

I'll try coming up with a roadmap for which packages to move first.
I'd like to do this right, so it won't be fast, but I hope we can
improve the Java stack in the process.

Fabio

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

Re: [fedora-java] Re: Re-Launching the Java SIG thread

[Ankur Sinha]

On Tue, May 12, 2020 18:45:12 +0200, Fabio Valentini wrote:
> On Tue, May 12, 2020 at 6:17 PM Igor Raits
>  wrote:
> > Count me in! I don't think I can help much, but at least can give some
> > suggestions.
> >
> > > Let's make this happen.
> >
> > Good luck, Fabio!
> 
> Thanks! Every bit of help counts.
> You should now be all set with FAS group / pagure project / mailing
> list subscription.

I've picked a suitable point to fork the thread back to a Java SIG
related conversation (added "thread" at the end of the subject to help
people differentiate).

Fabio,

Is there a TODO list somewhere so we new members can take up tasks from
to help you out? This ticket perhaps? It's filed at the Stewardship
SIG's pagure project, so I wasn't sure if the Java SIG folks are aware
of it yet:

https://pagure.io/stewardship-sig/issue/89

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


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: Re-Launching the Java SIG

[Samuel Sieb]

On 5/18/20 5:54 PM, Ty Young wrote:
I'm not advocating for in-kernel drivers. AMD with their drivers has 
proven proven what a bad idea that is. I, for the most part, like where 
I'm at and the way Nvidia does things. If I'm against it, I don't see 
why I would be the one to do it.


This comment doesn't make any sense.  NVidia's driver is just as much 
"in-kernel" as AMD's.  It's just supplied separately and has to play 
catch-up every time some internal kernel interface changes.

___
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: Re-Launching the Java SIG

[Solomon Peachy]

On Mon, May 18, 2020 at 07:54:42PM -0500, Ty Young wrote:
> Surely it is the responsibility of those who want such a change to 
> make sure that everything that existed before can continue to exist? I 
> realize this requires that such arguments are being made in good faith 
> and consider the perspectives and needs of everyone, which they 
> aren't.

Yes, exactly, it requires arguments being made in good faith, and 
considering the needs and perspectives of others.

...You would do well to practice what you preach.

I might add that even when your needs and perspectives are duly 
considered, it does not follow that the outcome will be something you 
are necessarily satisfied with.  Engineering is all about balancing 
tradeoffs, after all.

Meanwhile, "everything before" continues to exist and works as well as 
the day it was released.  Nobody here is forcing you to use anything 
more recent; you're free to adapt that older source code to your needs, 
or pay someone else to do it for you.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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: Re-Launching the Java SIG

[Neal Gompa]

On Mon, May 18, 2020 at 10:18 PM Ty Young  wrote:
>
>
> On 5/18/20 8:24 PM, Michael Catanzaro wrote:
> >
> > Dude, chill out. We're not going to go back to running X as root. The
> > Nvidia overclocking tool is just not important at all (seriously, who
> > cares?). If you're upset their proprietary software doesn't work
> > anymore, you can ask them nicely to fix it please... or ask for the
> > source code, and see how far that gets you. ;)
>
>
> I'm well aware Fedora has no interest in correcting its breakage of
> backwards compatibility. If you'd actually read all the messages you'd
> realize it was all in the name of explaining why distros can't be
> trusted to package software and shouldn't do it, including Java
> applications. It went down this path naturally, as discussions tend to
> do and have on this very mailing list without my involvement.
>

For what it's worth, this is not a change unique to Fedora. Arch,
Debian, and other distributions run Xorg in a user session when GDM is
the display manager.  Some distributions may have elected to change
GDM's behavior to the legacy behavior, but none I'm aware of today
do so aside from Ubuntu (and that's only when the proprietary drivers are
installed). That said, if you are using a display manager that does
not support rootless Xorg, you'll get the legacy behavior.

However, the writing is on the wall for both Xorg as root and Xorg as
a whole. Fedora in this regard is a trailblazer and other
distributions *will* follow. Several distributions have finally
shipped GNOME with Wayland by default and removed their "hold-back"
patches that reverted GDM and GNOME to legacy behaviors by default.
Other desktop display managers are working on supporting running Xorg
in the user session as well, and will likely drop support for running
Xorg as root once they do. Your app will break everywhere, I can
guarantee it.

And to be quite honest, I'm tired of seeing you complain on this list
without being even singularly helpful at all. You have provided
virtually no constructive feedback and continue to attack the Fedora
Project and its members. I do not know why you are even here, given
that you seem to hate everything we do.



--
真実はいつも一つ！/ 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: Re-Launching the Java SIG

[Ty Young]

On 5/18/20 8:24 PM, Michael Catanzaro wrote:


Dude, chill out. We're not going to go back to running X as root. The 
Nvidia overclocking tool is just not important at all (seriously, who 
cares?). If you're upset their proprietary software doesn't work 
anymore, you can ask them nicely to fix it please... or ask for the 
source code, and see how far that gets you. ;)



I'm well aware Fedora has no interest in correcting its breakage of 
backwards compatibility. If you'd actually read all the messages you'd 
realize it was all in the name of explaining why distros can't be 
trusted to package software and shouldn't do it, including Java 
applications. It went down this path naturally, as discussions tend to 
do and have on this very mailing list without my involvement.



(someone tried changing the subject line, but as I pointed out, I was 
just trying to explain why, as objectively as possible, it wasn't as 
perfect of a solution as they claim)



Of course, instead of reading everything, you decided to make a snide, 
unfriendly remark that probably violates the CoC. Given you have a Gnome 
email address I guess I can't say I'm surprised you take the position 
that you do. Afterall, Gnome has angered many great, talented, and 
independent extension developers including, IIRC, the developer of one 
of those most widely used tray icon extensions at the time who later 
quit out of frustration because Gnome kept breaking things. Indeed, 
people in general complain about Gnome not playing nice with others.



I'd love to see CoC enforcement on this, but I feel like I'd die of old 
age before that ever happens.



>Ugh, I just noticed the subject of this thread is Java SIG. Amazing 
how thoroughly this conversation has been derailed



Maybe people shouldn't make claims that amount to "packaging software 
for each distro is the only way to do things" despite plenty of evidence 
to the contrary.





The kernel gets rebased continuously throughout the life of a Fedora 
release. mesa updates are also possible when required, especially at 
the beginning of a release's lifetime. If there are bugs, you can work 
with the package maintainers



The issues being talked about aren't specific to Fedora. Fedora does do 
a better job than average on these sort of things.





___
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: Re-Launching the Java SIG

[John M. Harris Jr]

On Monday, May 18, 2020 4:03:16 PM MST Ty Young wrote:
> On 5/18/20 2:51 PM, Samuel Sieb wrote:
> 
> > On 5/18/20 7:27 AM, Ty Young wrote:
> > 
> >> The application was an Nvidia GPU overclocking utility written in 
> >> Java. When Fedora decided to disable running X. Org as root, it 
> >> resulted in the application no longer being able to adjust GPU/Memory 
> >> clocks, among possible other things. The software worked perfectly 
> >> fine on the latest versions of Ubuntu and Arch(and still does), but 
> >> not Fedora simply because of this.
> >
> >
> >
> > I figured it had to be something to do with NVidia because that's the 
> > only thing that would break due to that change.  If you insist on 
> > using proprietary software (NVidia driver), then you take the risk of 
> > having problems like this.  If NVidia would do the right thing and 
> > open their driver, then this could work. 
> 
> 
> 
> I completely obliterated this nonsensical argument last time this was 
> said in the thread Red Hat censored. Allow me to do so again.
> 
> 
> There are a great many outstanding bugs, some of which have existed for 
> years, in the kernel, its Open Source drivers and in mesa as well as in 
> other projects like Gnome. No one has fixed those despite being Open 
> Source, and in some cases they even have pull requests but the 
> maintainers won't, for whatever reason, accept them. Linux distros 
> refuse to ship or backport the latest versions of the kernel or mesa, so 
> even if it was Open Source and in the kernel it'd take years for 
> everyone to get the fix, if ever.
> 
> 
> You are arguing on theoretical nonsense that has no real basis in 
> reality, fueled by purely ideological hatred.
> 
> 
> If it was Open Source and we were having this discussion, people like 
> yourself would just move the goalpost by saying something like "Why 
> don't you contribute?" like you always do. You don't care about fixing 
> the problem, you just want the drivers to be Open Source and in the 
> kernel. The issue itself be damned, you don't care whether it *ACTUALLY* 
> gets fixed or not.
> 
> 
> Things like graphics drivers shouldn't be apart of the kernel, because 
> as Linux distros have proven, they can't be trusted to keep things 
> up-to-date or not to taint them... and the kernel moves wy too slow 
> for hardware releases anyway. AMD GPU owners who have the latest and 
> greatest have to wait many months for AMD to add support, and even then 
> there tends to be bugs. Nvidia? Every new GPU release support is 
> impressively rock solid that I've seen.
> 
> 
> X. Org as root is **STILL** the standard and Fedora broke it. This is 
> why no one wants to support Linux: you constantly break your own 
> platform and then cry wolf when people who don't care about your 
> ideological nonsense refuse to fix their software that was working 
> perfectly fine before. No one has time to check on every new Linux 
> distro release to see what you broke and clearly, if the number of 
> unmaintained Fedora packages is any indicator, no one has time or 
> interest to package and properly maintain the Open Source software that 
> is available either.
> 
> 
> All of this is completely ignoring the fact that an Open Source Nvidia 
> driver would most likely mean OC support exposed by system files like it 
> is with AMD instead of a nice C API. *Screw that*. Most of the AMD GPU 
> overclocking utilities have broken GPU support because of this, IIRC. 
> With Nvidia I have a nice stable APIs(Stable APIs in Linux? Impossible.) 
> I can use and support nearly everything at once.
> 
> 
> Unless you're going to personally volunteer to making a new, stable, 
> drop-in replacement C API if they do Open Source their driver or make a 
> new one and integrate it with the kernel?
> 
> 
> Willing to bet you or anyone else here won't.

What does this rant against Linux and Fedora have to do with the Java SIG? 
Please take this to another thread, preferably at supp...@nvidia.com.

-- 
John M. Harris, Jr.

___
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: Re-Launching the Java SIG

[Michael Catanzaro]

On Mon, May 18, 2020 at 8:24 pm, Michael Catanzaro 
 wrote:

Dude, chill out. We're not going to go back to running X as root.


Ugh, I just noticed the subject of this thread is Java SIG. Amazing how 
thoroughly this conversation has been derailed


___
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: Re-Launching the Java SIG

[Michael Catanzaro]

Dude, chill out. We're not going to go back to running X as root. The 
Nvidia overclocking tool is just not important at all (seriously, who 
cares?). If you're upset their proprietary software doesn't work 
anymore, you can ask them nicely to fix it please... or ask for the 
source code, and see how far that gets you. ;)


The kernel gets rebased continuously throughout the life of a Fedora 
release. mesa updates are also possible when required, especially at 
the beginning of a release's lifetime. If there are bugs, you can work 
with the package maintainers


___
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: Re-Launching the Java SIG

[Ty Young]

On 5/18/20 7:08 PM, Solomon Peachy wrote:

On Mon, May 18, 2020 at 06:03:16PM -0500, Ty Young wrote:

Willing to bet you or anyone else here won't.

FYI, this applies to you as well.



You just proved my point:


>If it was Open Source and we were having this discussion, people like 
yourself would just move the goalpost by saying something like "Why 
don't you contribute?" like you always do. You don't care about fixing 
the problem, you >just want the drivers to be Open Source and in the 
kernel. The issue itself be damned, you don't care whether it *ACTUALLY* 
gets fixed or not.



You create these problems by refusing to play nice and then attempt to 
use it as leverage in order to attack people/organizations that don't 
bend the knee. In actuality the issue itself is just a stepping stone 
that isn't really cared about.



A Gnome foundation member did this this exact same thing on Reddit 
recently, where graphical glitches would appear *only* on GTK windows 
that use the unified headerbar and were maxamized/de-maximized. The 
headerbar only part wasn't originally mentioned, and since the user 
bringing up the bug was using Nvidia, Nvidia was the one to get blamed 
for it. Once the unified headerbar only part was mentioned did the 
foundation member back track. It's why I don't believe for a second that 
issues like the Gnome 3 memory leaks while running Nvidia is Nvidia's 
fault. People point fingers based on who they like and agree with, not 
on technical facts.



Crying wolves if there ever was any.


(Yes, I know there are very real situations where Nvidia isn't playing 
nice themselves, but this isn't the case here)



I'm not advocating for in-kernel drivers. AMD with their drivers has 
proven proven what a bad idea that is. I, for the most part, like where 
I'm at and the way Nvidia does things. If I'm against it, I don't see 
why I would be the one to do it.



Surely it is the responsibility of those who want such a change to make 
sure that everything that existed before can continue to exist? I 
realize this requires that such arguments are being made in good faith 
and consider the perspectives and needs of everyone, which they aren't.






  - Solomon

___
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: Re-Launching the Java SIG

[Gerald Henriksen]

On Mon, 18 May 2020 18:03:16 -0500, you wrote:

>X. Org as root is **STILL** the standard and Fedora broke it. This is 
>why no one wants to support Linux: you constantly break your own 
>platform and then cry wolf when people who don't care about your 
>ideological nonsense refuse to fix their software that was working 
>perfectly fine before.

X.org running as root likely is a security risk, and as such it is
long past the point where somebody should have fixed it.

And with time the other distros will probably also change X.org to run
as a user instead of root (ie. once all the bugs are worked out).

So not a very good arguement.
___
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: Re-Launching the Java SIG

[Solomon Peachy]

On Mon, May 18, 2020 at 06:03:16PM -0500, Ty Young wrote:
> Willing to bet you or anyone else here won't.

FYI, this applies to you as well.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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: Re-Launching the Java SIG

[Nico Kadel-Garcia]

On Mon, May 18, 2020 at 9:34 AM Ty Young  wrote:

> The "toolchain" isn't broken, other than Gradle developers not caring
> about backwards compatibility but... It works for them, just as

A toolchain with broken links scattered through it is not toolchain.
Building up the .jar files as a hierarchy from source is not well
supported, and has been vulnerable to many fractions. It's inherent to
object oriented approaches where paying any notice outside your own
momentgary layer of abstraction is considered a violation of your
objectives and an anti-pattern. Many "autobuild as needed tools have
had this problem, including CPAN, pip, ant, maven, and gradle.

I dealt with a lot of this bundling tools for JPackage years ago, and
still deal with it with other tools today, most recently with the
rubygems dependencies for R10K. It's a problem.

> The only thing I remember Gradle downloading when I built it locally is
> a previous beta build in order to build the end final release. Maybe
> there were a few other things I'm forgetting, someone else can correct me.

Build them in "mock", which cuts off network access to the chroot cage
building the software. I suspect you'll be unpleasantly surprised: it
tends to show build-time downloads for rubygems, pip, and maven based
software builds.

> Yeah, no.
>
>
> My software didn't magically break just for Fedora because of some bug
> in my software. It broke because Fedora decided they wanted to do
> something nearly no Linux distro does... something that has been the
> defacto standard for many years.


> ...and there are plenty of Open Source projects that don't have packages
> yet people contribute to them. This isn't the early 2000 when barely
> anyone has internet and sites like Github didn't exist. Sure, a distro
> package increases visibility still, but it isn't all that matters. Heck,
> the Windows 10 calculator app is sitting at over 1100 contributors right
> now on Github.

Inability or unwillingneds to follow deployment standards is one of
the signs of software that should be avoided. If the authors follow

> The point here is not that upstream should be blindly trusted, but
> rather that downstream's poo **does*** stink and affect other people,
> even those that don't specifically package for your distro.

Well, yes.

Gradle was highly applauded by some developers of my acquaintance. I'm
curious what you find beneficial about it, because I've found it to be
destabilizing.
___
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: Re-Launching the Java SIG

[Ty Young]

On 5/18/20 2:51 PM, Samuel Sieb wrote:

On 5/18/20 7:27 AM, Ty Young wrote:
The application was an Nvidia GPU overclocking utility written in 
Java. When Fedora decided to disable running X. Org as root, it 
resulted in the application no longer being able to adjust GPU/Memory 
clocks, among possible other things. The software worked perfectly 
fine on the latest versions of Ubuntu and Arch(and still does), but 
not Fedora simply because of this.


I figured it had to be something to do with NVidia because that's the 
only thing that would break due to that change.  If you insist on 
using proprietary software (NVidia driver), then you take the risk of 
having problems like this.  If NVidia would do the right thing and 
open their driver, then this could work. 



I completely obliterated this nonsensical argument last time this was 
said in the thread Red Hat censored. Allow me to do so again.



There are a great many outstanding bugs, some of which have existed for 
years, in the kernel, its Open Source drivers and in mesa as well as in 
other projects like Gnome. No one has fixed those despite being Open 
Source, and in some cases they even have pull requests but the 
maintainers won't, for whatever reason, accept them. Linux distros 
refuse to ship or backport the latest versions of the kernel or mesa, so 
even if it was Open Source and in the kernel it'd take years for 
everyone to get the fix, if ever.



You are arguing on theoretical nonsense that has no real basis in 
reality, fueled by purely ideological hatred.



If it was Open Source and we were having this discussion, people like 
yourself would just move the goalpost by saying something like "Why 
don't you contribute?" like you always do. You don't care about fixing 
the problem, you just want the drivers to be Open Source and in the 
kernel. The issue itself be damned, you don't care whether it *ACTUALLY* 
gets fixed or not.



Things like graphics drivers shouldn't be apart of the kernel, because 
as Linux distros have proven, they can't be trusted to keep things 
up-to-date or not to taint them... and the kernel moves wy too slow 
for hardware releases anyway. AMD GPU owners who have the latest and 
greatest have to wait many months for AMD to add support, and even then 
there tends to be bugs. Nvidia? Every new GPU release support is 
impressively rock solid that I've seen.



X. Org as root is **STILL** the standard and Fedora broke it. This is 
why no one wants to support Linux: you constantly break your own 
platform and then cry wolf when people who don't care about your 
ideological nonsense refuse to fix their software that was working 
perfectly fine before. No one has time to check on every new Linux 
distro release to see what you broke and clearly, if the number of 
unmaintained Fedora packages is any indicator, no one has time or 
interest to package and properly maintain the Open Source software that 
is available either.



All of this is completely ignoring the fact that an Open Source Nvidia 
driver would most likely mean OC support exposed by system files like it 
is with AMD instead of a nice C API. *Screw that*. Most of the AMD GPU 
overclocking utilities have broken GPU support because of this, IIRC. 
With Nvidia I have a nice stable APIs(Stable APIs in Linux? Impossible.) 
I can use and support nearly everything at once.



Unless you're going to personally volunteer to making a new, stable, 
drop-in replacement C API if they do Open Source their driver or make a 
new one and integrate it with the kernel?



Willing to bet you or anyone else here won'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

___
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: Re-Launching the Java SIG

[Samuel Sieb]

On 5/18/20 7:27 AM, Ty Young wrote:
The application was an Nvidia GPU overclocking utility written in Java. 
When Fedora decided to disable running X. Org as root, it resulted in 
the application no longer being able to adjust GPU/Memory clocks, among 
possible other things. The software worked perfectly fine on the latest 
versions of Ubuntu and Arch(and still does), but not Fedora simply 
because of this.


I figured it had to be something to do with NVidia because that's the 
only thing that would break due to that change.  If you insist on using 
proprietary software (NVidia driver), then you take the risk of having 
problems like this.  If NVidia would do the right thing and open their 
driver, then this could work.

___
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: Re-Launching the Java SIG

[Ty Young]

On 5/18/20 9:14 AM, Fabio Valentini wrote:

On Mon, May 18, 2020 at 3:34 PM Ty Young  wrote:

On 5/18/20 7:35 AM, Nicolas Mailhot via devel wrote:
My software didn't magically break just for Fedora because of some bug
in my software. It broke because Fedora decided they wanted to do
something nearly no Linux distro does... something that has been the
defacto standard for many years.

those comments are just spreading FUD without adding anything
worthwhile to the discussion.
Please, either provide those details - so we can do better in the
future - or stop.



Fair enough.


The application was an Nvidia GPU overclocking utility written in Java. 
When Fedora decided to disable running X. Org as root, it resulted in 
the application no longer being able to adjust GPU/Memory clocks, among 
possible other things. The software worked perfectly fine on the latest 
versions of Ubuntu and Arch(and still does), but not Fedora simply 
because of this.





Thanks,
Fabio
___
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: Re-Launching the Java SIG

[Fabio Valentini]

On Mon, May 18, 2020 at 3:34 PM Ty Young  wrote:
> On 5/18/20 7:35 AM, Nicolas Mailhot via devel wrote:
> My software didn't magically break just for Fedora because of some bug
> in my software. It broke because Fedora decided they wanted to do
> something nearly no Linux distro does... something that has been the
> defacto standard for many years.

Ty,

You continue telling us that "Fedora" (sic!) broke your software, but
without actually telling us

- which broken program it is that you're talking about, and
- which packages / changes in fedora caused the breakage,

those comments are just spreading FUD without adding anything
worthwhile to the discussion.
Please, either provide those details - so we can do better in the
future - or stop.

Thanks,
Fabio
___
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: Re-Launching the Java SIG

[Nicolas Mailhot via devel]

Le lundi 18 mai 2020 à 08:34 -0500, Ty Young a écrit :
> 
> The "toolchain" isn't broken, other than Gradle developers not
> caring about backwards compatibility but... It works for them, just
> as constantly breaking internal kernel APIs works for the Linux
> kernel 

The difference, is that you can build a new kernel, while running an
old kernel. the kernel is not constantly breaking external kernel APIs
like gradle breaks the external gradle APIs a new gradle needs to be
built (when building gradle with gradle, the new build is a consumer of
external gradle APIS)

-- 
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: Re-Launching the Java SIG

[Ty Young]

On 5/18/20 8:34 AM, Ty Young wrote:



...and there are plenty of Open Source projects that don't have 
packages yet people contribute to them. This isn't the early 2000 when 
barely anyone has internet and sites like Github didn't exist. Sure, a 
distro package increases visibility still, but it isn't all that 
matters. Heck, the Windows 10 calculator app is sitting at over 1100 
contributors right now on Github.



I meant VSCode, not the calculator app... although that probably has a 
fair bit of contributors too.

___
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: Re-Launching the Java SIG

[Ty Young]

On 5/18/20 7:35 AM, Nicolas Mailhot via devel wrote:

Le lundi 18 mai 2020 à 14:12 +0200, Michal Srb a écrit :

Hello,

On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel <
devel@lists.fedoraproject.org> wrote:

Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :

On Fri, 15 May 2020 08:02:34 +0200
Michal Srb  wrote:

An aside, just to clarify for myself.  That means that all Java

apps

are
the equivalent of statically linked, right?  And are related to
things
like flatpaks and modules?

No, that’s similar to venv everywhere. The language has bytecode-
sharing objects. Java upstreams just got used not to share those
executable objects between projects, not to version them properly,
not
to manage their ABI breaks, and to change things in the local copy
instead of contributing changes to the original project.

Well... Java upstreams share their JARs by uploading them to a public
Maven repository (Maven Central most of the time). And in the vast
majority of cases there are also "source-JARs" (containing source
code) uploaded alongside the bytecode JARs. I am simplifying things
here a bit, but basically when Java open source projects want to ship
their apps, they fetch pre-built dependencies from Maven Central,
compile their apps, and bundle everything (app bytecode + pre-built
deps) in a tarball. And that's what they ship.

If Java finally left the stone age, there should be no problem building
the same artefacts in rpm, installing them in a central place like
%{_datadir}/java or %{_libdir}/java, and making it a package other java
software can buildrequire. We managed it in Go, and we did not even
have a language versionning infra to build upon.


That’s non-free software open source to its extreme. The code is
available for a dev to copy and resell at his next work, but
everything is organised (at the human not technical level) so it’s
not possible to reuse the bytecode directly without paying someone
to copy and fork the original code that this bytecode was generated
from in the next project.

I'd like to know more about this if you don't mind. This is
definitely not how open source Java apps are developed.

Free software is end user not dev oriented. Stallman wanted his printer
driver to work. The GPL gives rights to the recipient. As long as the
toolchain is broken enouth even huge downstreams like distros are
unable to rebuild the source easily, you have something that may be
open source, but does not function as effective free software.



The "toolchain" isn't broken, other than Gradle developers not caring 
about backwards compatibility but... It works for them, just as 
constantly breaking internal kernel APIs works for the Linux kernel or 
running X. Org as user does for Fedora. No-one involved with the Linux 
kernel or the distros has a right to complain, y'all do it to other 
people all the time.



The only thing I remember Gradle downloading when I built it locally is 
a previous beta build in order to build the end final release. Maybe 
there were a few other things I'm forgetting, someone else can correct me.





And when downstreaming is broken upstreaming is broken too (who will
bother contributing to an upstream when things do not flow the other
way?).



Yeah, no.


My software didn't magically break just for Fedora because of some bug 
in my software. It broke because Fedora decided they wanted to do 
something nearly no Linux distro does... something that has been the 
defacto standard for many years.



Willing to bet money Gnome has received a great many bug reports because 
of extensions Linux distros ship by default as well.



...and there are plenty of Open Source projects that don't have packages 
yet people contribute to them. This isn't the early 2000 when barely 
anyone has internet and sites like Github didn't exist. Sure, a distro 
package increases visibility still, but it isn't all that matters. Heck, 
the Windows 10 calculator app is sitting at over 1100 contributors right 
now on Github.



The point here is not that upstream should be blindly trusted, but 
rather that downstream's poo **does*** stink and affect other people, 
even those that don't specifically package for your distro.




As spot wrote a long time ago, the only useful form of open source for
Fedora (and a lot of other entities) is free software.


___
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: Re-Launching the Java SIG

[Nicolas Mailhot via devel]

Le lundi 18 mai 2020 à 14:12 +0200, Michal Srb a écrit :
> Hello,
> 
> On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel <
> devel@lists.fedoraproject.org> wrote:
> > Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
> > > On Fri, 15 May 2020 08:02:34 +0200
> > > Michal Srb  wrote:
> > > 
> > > An aside, just to clarify for myself.  That means that all Java
> > apps
> > > are
> > > the equivalent of statically linked, right?  And are related to
> > > things
> > > like flatpaks and modules?
> > 
> > No, that’s similar to venv everywhere. The language has bytecode-
> > sharing objects. Java upstreams just got used not to share those
> > executable objects between projects, not to version them properly,
> > not
> > to manage their ABI breaks, and to change things in the local copy
> > instead of contributing changes to the original project.
> 
> Well... Java upstreams share their JARs by uploading them to a public
> Maven repository (Maven Central most of the time). And in the vast
> majority of cases there are also "source-JARs" (containing source
> code) uploaded alongside the bytecode JARs. I am simplifying things
> here a bit, but basically when Java open source projects want to ship
> their apps, they fetch pre-built dependencies from Maven Central,
> compile their apps, and bundle everything (app bytecode + pre-built
> deps) in a tarball. And that's what they ship.

If Java finally left the stone age, there should be no problem building
the same artefacts in rpm, installing them in a central place like
%{_datadir}/java or %{_libdir}/java, and making it a package other java
software can buildrequire. We managed it in Go, and we did not even
have a language versionning infra to build upon.

> > That’s non-free software open source to its extreme. The code is
> > available for a dev to copy and resell at his next work, but
> > everything is organised (at the human not technical level) so it’s
> > not possible to reuse the bytecode directly without paying someone
> > to copy and fork the original code that this bytecode was generated
> > from in the next project.
> 
> I'd like to know more about this if you don't mind. This is
> definitely not how open source Java apps are developed.

Free software is end user not dev oriented. Stallman wanted his printer
driver to work. The GPL gives rights to the recipient. As long as the
toolchain is broken enouth even huge downstreams like distros are
unable to rebuild the source easily, you have something that may be
open source, but does not function as effective free software.

And when downstreaming is broken upstreaming is broken too (who will
bother contributing to an upstream when things do not flow the other
way?).

As spot wrote a long time ago, the only useful form of open source for
Fedora (and a lot of other entities) is free software.

-- 
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: Re-Launching the Java SIG

[Michal Srb]

Hello,

On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel <
devel@lists.fedoraproject.org> wrote:

> Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
> > On Fri, 15 May 2020 08:02:34 +0200
> > Michal Srb  wrote:
> >
> > An aside, just to clarify for myself.  That means that all Java apps
> > are
> > the equivalent of statically linked, right?  And are related to
> > things
> > like flatpaks and modules?
>
> No, that’s similar to venv everywhere. The language has bytecode-
> sharing objects. Java upstreams just got used not to share those
> executable objects between projects, not to version them properly, not
> to manage their ABI breaks, and to change things in the local copy
> instead of contributing changes to the original project.
>

Well... Java upstreams share their JARs by uploading them to a public Maven
repository (Maven Central most of the time). And in the vast majority of
cases there are also "source-JARs" (containing source code) uploaded
alongside the bytecode JARs. I am simplifying things here a bit, but
basically when Java open source projects want to ship their apps, they
fetch pre-built dependencies from Maven Central, compile their apps, and
bundle everything (app bytecode + pre-built deps) in a tarball. And that's
what they ship.
JARs in Maven Central are always versioned, and people who want to use them
pick specific versions, so no version ranges... (although technically
possible of course) And JARs in Maven Central are immutable, so if you want
to use such pre-built JAR, you pick a specific version for your app and it
will never change.

What you're describing sounds like the 2005-ish way of developing Java
applications :) The Java open source world has evolved since then.


> That’s non-free software open source to its extreme. The code is
> available for a dev to copy and resell at his next work, but everything
> is organised (at the human not technical level) so it’s not possible to
> reuse the bytecode directly without paying someone to copy and fork the
> original code that this bytecode was generated from in the next
> project.
>

I'd like to know more about this if you don't mind. This is definitely not
how open source Java apps are developed.

Thanks,
Michal


>
> The practical effect is technical stagnation and market capture by deep
> pocket companies.
>

> --
> 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
>
___
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: Re-Launching the Java SIG

[stan via devel]

On Sat, 16 May 2020 11:23:03 +0200
Nicolas Mailhot  wrote:

> Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
> > On Fri, 15 May 2020 08:02:34 +0200
> > Michal Srb  wrote:
> > 
> > An aside, just to clarify for myself.  That means that all Java apps
> > are
> > the equivalent of statically linked, right?  And are related to
> > things
> > like flatpaks and modules?  
> 
> No, that’s similar to venv everywhere. The language has bytecode-
> sharing objects. Java upstreams just got used not to share those
> executable objects between projects, not to version them properly, not
> to manage their ABI breaks, and to change things in the local copy
> instead of contributing changes to the original project.
> 
> That’s non-free software open source to its extreme. The code is
> available for a dev to copy and resell at his next work, but
> everything is organised (at the human not technical level) so it’s
> not possible to reuse the bytecode directly without paying someone to
> copy and fork the original code that this bytecode was generated from
> in the next project.
> 
> The practical effect is technical stagnation and market capture by
> deep pocket companies.

Thanks for the explanation.
___
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: Re-Launching the Java SIG

[Nicolas Mailhot via devel]

Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
> On Fri, 15 May 2020 08:02:34 +0200
> Michal Srb  wrote:
> 
> An aside, just to clarify for myself.  That means that all Java apps
> are
> the equivalent of statically linked, right?  And are related to
> things
> like flatpaks and modules?

No, that’s similar to venv everywhere. The language has bytecode-
sharing objects. Java upstreams just got used not to share those
executable objects between projects, not to version them properly, not
to manage their ABI breaks, and to change things in the local copy
instead of contributing changes to the original project.

That’s non-free software open source to its extreme. The code is
available for a dev to copy and resell at his next work, but everything
is organised (at the human not technical level) so it’s not possible to
reuse the bytecode directly without paying someone to copy and fork the
original code that this bytecode was generated from in the next
project.

The practical effect is technical stagnation and market capture by deep
pocket companies.

-- 
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: Re-Launching the Java SIG

[Gerald Henriksen]

On Thu, 14 May 2020 06:33:47 -0500, you wrote:

>* Game developers largely refuse to support Linux, and the some of the 
>few that have have or are currently pulling support citing 
>fragmentation(support) issues.

Game developers refuse to support Linux because there is no userbase -
even Steam, who moved to Linux for strategic rather than financial
reasons, consistently reports a neglible installed base of Linux
gamers.

The fragmentation may not help, but it isn't the driving force (if
Linux gaming was a $10billion a year business they would find a way to
deal with the issues).

>* Hardware support for AMD GPUs is all over the place and even if 
>technically supported, can be too buggy to use. This is largely because 
>kernel/mesa versions are all over the place.

Surprise, writing drivers and the associated code for modern GPU's is
hard - even for the in house development teams providing binary only
drivers, as anyone who follows GPU issues on Windows is aware.

>* You often need to install third-party repos to get up-to-date software 
>since packages are way too slow, or the distros just choose to use very 
>old software(Debian).

Part of choosing a distro is choosing new vs well tested.

Anyone choosing the released versions of Debian is doing so on the
basis they want well tested releases and new versions aren't a
priority.

If you want new version, you choose a different distro.

>* Bugs fixed in newer versions of Gnome shell aren't backported to older 
>versions. It looks like they have extended support, but I doubt it's for 
>the same amount of time Ubuntu supports an LTS. Even if it did, only 
>newer Gnome shell versions are supported for that long. 18.04 probably 
>has shell bugs right now that are fixed in newer Gnome versions.

Not a Gnome problem (says a person who doesn't even like Gnome
anymore).

When Ubuntu/Red Hat/CentOS/etc release whatever their variation of a
distro with a long support lifetime is they take on the burden of
supporting the software for the duration of that release, not the
upstream.

So in your complaint, it is not up to Gnome to continue supporting
that version of Gnome, it is up to Ubuntu to backport/create fixes as
necessary - that is after all the whole point of offering a LTS
release that people pay Ubuntu to provide support on.
___
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: Re-Launching the Java SIG

[Gerald Henriksen]

On Thu, 14 May 2020 06:59:47 -0500, you wrote:

>What i'm saying is: Distros like Fedora actively hurt the very people 
>who are directly or indirectly helping them. There are single-person run 
>projects, like mine, out there that can't possibly do all the work 
>needed to have a dozen packages for each distro. It's just not possible 
>or, in the case of Java based projects, not even needed to begin with.

1) nobody is forcing upstream developers to package their projects -
that's what the packagers in the various distrobutions do.

2) the fact that people want to package the Java packages, and that
other people want to install those packages, indicates that there is a
need.

>That is to say nothing of those distros doing things like Fedora now 
>does like running X as user which break otherwise perfectly running 
>applications. 

Running X as a user would be a change done to decrease the security
risk of running applications using X, or X itself.

It is the type of change that anyone should expect a distribution to
make, and the type of change even Apple and Microsoft make (anyone who
used Windows in the past will recall the applications that insisted on
being run as an Administrator for no valid reason, and eventually
Microsoft learned the hard way and cracked down - I am sure just like
you seem to be a lot of Windows developers made the same false claim
that MS was breaking otherwise perfectly running applications.

>I can't check in every 6 months to make sure y'all didn't 
>break something.

Then perhaps you need to look for a different hobby/career?

The software development field is full of constant change that
developers need to be aware of regardless of OS or environment.
___
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: Re-Launching the Java SIG

[stan via devel]

On Fri, 15 May 2020 08:02:34 +0200
Michal Srb  wrote:

> > I realize that this is technically possible to achieve, but that is
> > not how people use it. If you want to distribute your Java app, you
> > just bundle it with all its dependencies into a beefy tarball and
> > ship it. And if Java apps never share dependencies, then developers
> > are not really forced to keep up with latest versions of libraries.
> > Nobody can update the non-existent system-wide Java library that
> > would break their application. They are in control.

An aside, just to clarify for myself.  That means that all Java apps are
the equivalent of statically linked, right?  And are related to things
like flatpaks and modules?
___
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: Re-Launching the Java SIG

[Michal Srb]

On Thu, May 14, 2020 at 2:42 PM Vít Ondruch  wrote:

>
> Dne 14. 05. 20 v 11:53 Michal Srb napsal(a):
>
> Hello,
>
> On Tue, May 12, 2020 at 12:57 PM Felix Schwarz 
> wrote:
>
>>
>> Am 12.05.20 um 12:32 schrieb Ty Young:
>> > Right, I figured it was some Fedora policy and not up to you. I suppose
>> I
>> > should have been more clear there. Sorry for any confusion, it was
>> aimed at
>> > the Fedora project as a whole as this is a Fedora issue.
>>
>> This is not a Fedora issue but a consequence of Fedora's core values. You
>> not
>> agree with it but "building from source" is so fundamental that it does
>> not
>> make sense to even start a discussion about it on fedora-devel.
>>
>> I suggest you read up on the rationale behind that policy (which is why I
>> linked the policy document in the first place).
>>
>
> I agree that building from sources is the right thing to do. However, let
> me play devil's advocate here :)
>
> What makes Java apps different from other language ecosystems is that Java
> apps never share dependencies. There is no concept of "system-wide"
> 3rd-party Java libraries that would be automatically added to classpath
> when JVM starts.
>
>
> And now how is this different to different language ecosystems? All
> languages I have ever worked with has this attitude, more or less. The
> Linux distributions are fighting against this but with various success.
> With Java, Fedora is failing ATM.
>

Since Java apps always ship their dependencies in tarballs, it's like
upstream is pinning down dependencies to specific versions. There is no
room for any version ranges like for example "as long as you have
java-lib>=2.3 on your system, the dependency will be satisfied". Installing
(well, "unpacking") other Java application that requires java-lib>=3.0 will
never break the first app.

Then Fedora comes in and tries not only to run both Java App #1 and Java
App #2 on the same system, ideally with the single version of
java-lib(latest), but also to build both the apps on the same system (the
build system being the 3rd Java app).
I am not saying this is something bad, it's just something completely
unnatural for the Java App ecosystem.
Java developers ship their tested self-contained tarballs which work on
Linux, Mac and Windows. And Linux distributions take those apps and try to
run them with a completely different set of dependencies. I kinda
understand why upstream projects are not always happy about that...

Although you're right that there are plenty of Python projects out there
that straight up tell you to isolate their applications in a virtual
environment when you're pip-installing them from PyPI. It's not all though.
There are still plenty of projects that tell you that as long as you have
python-lib>=2.3 on your machine, you will be fine. This makes Python
packaging so much easier, at least in my opinion. Such Python apps are not
in full control of their dependency chains, they realize that newer
python-lib could introduce some breaking changes and if you open a pull
request with a patch, they are not surprised, they know what the problem is
and why the pull request should be merged. That's what they signed up for
by saying that python-lib>=2.3 is fine.

Thanks,
Michal


> And if the bundling is not happening on language level, then we are back
> to bundling in containers and flatpacks and what not.
>
>
> Vít
>
>
> I realize that this is technically possible to achieve, but that is not
> how people use it. If you want to distribute your Java app, you just bundle
> it with all its dependencies into a beefy tarball and ship it.
> And if Java apps never share dependencies, then developers are not really
> forced to keep up with latest versions of libraries. Nobody can update the
> non-existent system-wide Java library that would break their application.
> They are in control.
>
> Since there is no standard place for shared Java libraries on your laptop,
> how can you use the packaged Java libraries and develop software against
> them? Sure, you can hack it and make it work on your Fedora 32 machine, but
> your custom Makefile is not guaranteed to work on Fedora 31 or later on 33.
> And your colleague that is on CentOS is out of luck of course. And so are
> all your potential external contributors on their MacBooks and Ubuntus.
> What I am trying to say in this paragraph is that shipping (in RPMs) and
> maintaining individual build-only Java libraries is, at least in my
> opinion, questionable.
>
> Fedora and other linux distributions are trying to do the right thing, but
> things like Java apps simply don't fit in. What Java app developers are
> doing may not be the best thing, but it's been like that for ~20 years, and
> it seems to be "good enough" for the majority of people involved (well,
> developers at least).
> Fedora alone is too insignificant to change it I am afraid.
>
> However, with all that being said. I do like "dnf install my-java-app"
> better than unpacking some tarballs 

Re: Why distributions package software (was: Re: Re-Launching the Java SIG)

[Jerry James]

On Thu, May 14, 2020 at 6:38 AM Igor Raits
 wrote:
> On Thu, 2020-05-14 at 06:33 -0500, Ty Young wrote:
> > Nonsense spewing with no proof.
>
> Well, you have started this. Can you provide some statistics how many
> bugs were introduced by distributions versus upstream bugs.

My experience has been that when a packager actively maintains a
package, the number of bugs fixed due to packager activity far
outweighs the number of bugs introduced.  We do not just blindly
consume upstream.  The work of a distribution is integration work,
which few upstreams even think about.  In the process of doing that
integration work, we discover problems with upstream code, upstream
build systems, upstream interactions with other components, and feed
bug reports and patches back upstream.  Many packages are in better
shape *for everyone* because they were packaged for Fedora.

Of course, if you've got a packager who isn't paying attention, things
can deteriorate.  That's why we have mechanisms for finding and
orphaning packages that don't appear to be maintained.
-- 
Jerry James
http://www.jamezone.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: Re-Launching the Java SIG

[Mamoru TASAKA]

Well, as just I saw "xscreensaver" word here:

Ty Young wrote on 2020/05/14 20:33:


On 5/13/20 4:58 PM, Solomon Peachy wrote:

On Wed, May 13, 2020 at 04:04:50PM -0500, Ty Young wrote:

Anyway, I'm just asking that Fedora not repeat what Debian did. While
I find it to be a bit paranoid, I understand the concerns regarding
someone sneaking in malware into pre-build binaries. I'm just asking
Fedora not package the software at all in that case, or any software
that depends on that software if possible. People who want to support
Linux by writing software shouldn't be bothered with bug reports from
issues they never created to begin with.

"Fedora" doesn't package software; individuals do.  Those individuals
are free to package whatever they like, and Fedora will distribute those
packages if they meet the well-established packaging criteria.



Whichever you choose. Large projects like Gnome and Fedora refer to themselves as one large organization one 
minute and then as individuals the next. It reminds me of how everyone says "Linux" is less 
resource hungry then Windows but "Linux" is just a kernel, as those same people will often say in 
"Linux"'s defense.


and it's those "well-established" packaging criteria are the reason people 
stopped packaging Java software for Fedora, according to many emails.



Those packagers, and Fedora, are "supporting Linux".



The amount of disdain and disrespect for third-party, and/or independent 
software developers and/or creators who don't conform to your clubhouse rules 
is palpable.




Meanwhile, for every distribution-created "bug" there are ten thousand
that created by the upstream authors.  Most upstreams are mature enough
to recognize this, and consider distribution-level packaging (and
front-line user support) efforts to be, on the whole, a net gain.



Nonsense spewing with no proof.

The Debian Xscreensaver fiasco is enough proof that contradicts your ridiculous 
claims and there are plenty more, including:


Perhaps you don't know, but me, Debian maintainer Tormod Volden and the 
upstream jwz are talking with
good relation these days.

Regards,
Mamoru




* Game developers largely refuse to support Linux, and the some of the few that 
have have or are currently pulling support citing fragmentation(support) issues.


* Hardware support for AMD GPUs is all over the place and even if technically 
supported, can be too buggy to use. This is largely because kernel/mesa 
versions are all over the place.


* Some software packaged even in large Linux distros like Ubuntu as part of 
their enabled-by-default repos don't even launch. Codeblocks in around 16.04, 
IIRC, didn't even launch once you install it. You had to use their privately 
hosted repo to install a newer version.


* You often need to install third-party repos to get up-to-date software since 
packages are way too slow, or the distros just choose to use very old 
software(Debian).


* Bugs fixed in newer versions of Gnome shell aren't backported to older 
versions. It looks like they have extended support, but I doubt it's for the 
same amount of time Ubuntu supports an LTS. Even if it did, only newer Gnome 
shell versions are supported for that long. 18.04 probably has shell bugs right 
now that are fixed in newer Gnome versions.


* There have been security bugs found in packaged software like Grub that have 
existed in years despite being one of the most widely packaged and used 
software on Linux.


* Linux distros do not resolve dependancy conflicts correctly. Ubuntu last time 
I checked still requires you manually install 32-bit libs in order to launch 
Steam instead of doing that for the user.


* Linux distro GUI package managers are generally poorly designed and buggy. That 
screenshot of Fedora's cinnamon spin's packager manager GUI I posted here showed that 
plenty. Other distros aren't much better. Manjaro/Arch Linux's "Pamac" GUI had 
a bug where it sees itself as a running package manager instance and refused to upgrade 
or install software on a failed AUR software build/install.


* Linux distros "taint" software they package and install by, for example, 
enabling shell extensions in Gnome by default. This more likely than not results in false 
bug reports. Fedora even does this!


I could literally go on and on. The "my-shit-don't-stink" attitude is so 
terrible it's borderline sad.




  - Solomon


___
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: Re-Launching the Java SIG

[Vít Ondruch]

Dne 14. 05. 20 v 11:53 Michal Srb napsal(a):
> Hello,
>
> On Tue, May 12, 2020 at 12:57 PM Felix Schwarz
> mailto:fschw...@fedoraproject.org>> wrote:
>
>
> Am 12.05.20 um 12:32 schrieb Ty Young:
> > Right, I figured it was some Fedora policy and not up to you. I
> suppose I
> > should have been more clear there. Sorry for any confusion, it
> was aimed at
> > the Fedora project as a whole as this is a Fedora issue.
>
> This is not a Fedora issue but a consequence of Fedora's core
> values. You not
> agree with it but "building from source" is so fundamental that it
> does not
> make sense to even start a discussion about it on fedora-devel.
>
> I suggest you read up on the rationale behind that policy (which
> is why I
> linked the policy document in the first place).
>
>
> I agree that building from sources is the right thing to do. However,
> let me play devil's advocate here :)
>
> What makes Java apps different from other language ecosystems is that
> Java apps never share dependencies. There is no concept of
> "system-wide" 3rd-party Java libraries that would be automatically
> added to classpath when JVM starts.


And now how is this different to different language ecosystems? All
languages I have ever worked with has this attitude, more or less. The
Linux distributions are fighting against this but with various success.
With Java, Fedora is failing ATM.

And if the bundling is not happening on language level, then we are back
to bundling in containers and flatpacks and what not.


Vít


> I realize that this is technically possible to achieve, but that is
> not how people use it. If you want to distribute your Java app, you
> just bundle it with all its dependencies into a beefy tarball and ship it.
> And if Java apps never share dependencies, then developers are not
> really forced to keep up with latest versions of libraries. Nobody can
> update the non-existent system-wide Java library that would break
> their application. They are in control.
>
> Since there is no standard place for shared Java libraries on your
> laptop, how can you use the packaged Java libraries and develop
> software against them? Sure, you can hack it and make it work on your
> Fedora 32 machine, but your custom Makefile is not guaranteed to work
> on Fedora 31 or later on 33. And your colleague that is on CentOS is
> out of luck of course. And so are all your potential external
> contributors on their MacBooks and Ubuntus.
> What I am trying to say in this paragraph is that shipping (in RPMs)
> and maintaining individual build-only Java libraries is, at least in
> my opinion, questionable.
>
> Fedora and other linux distributions are trying to do the right thing,
> but things like Java apps simply don't fit in. What Java app
> developers are doing may not be the best thing, but it's been like
> that for ~20 years, and it seems to be "good enough" for the majority
> of people involved (well, developers at least).
> Fedora alone is too insignificant to change it I am afraid.
>
> However, with all that being said. I do like "dnf install my-java-app"
> better than unpacking some tarballs somewhere.
>
> And finally, here comes the "devil's advocate" part of my email.
>
> * building Java libraries and apps from sources?
>   * +1, no doubt about this
> * building Java libraries and apps from sources in a controlled and
> reproducible environment?
>   * yes, please
> * building Java libraries and apps from sources from SRPMs?
>   * do we really need the RPM overhead here?
> * shipping (in RPMs) and maintaining Java libraries that are not
> runtime dependencies of Java applications that we want to have in Fedora?
>   * nope, why? build such build-only dependencies from sources, make
> sure they are OK license-wise, but do not ship them to users (as
> explained above, they are not very useful for developers anyway)
>
> We can do license reviews, we can build from sources, but we don't
> necessarily have to do all this in RPMs.
> We can do all the right things, store (our binary) results in a
> language-native way, which would be a Maven repository controlled by
> Fedora in this case, and then simply wrap our good binary JARs into
> RPMs, without rebuilding them all the time.
>
> Note having such language-native repository full of good and reviewed
> Java libraries would mean that developers that care about such things
> could actually start using it instead of the official Maven
> repository. And they wouldn't be tied to a specific version of Fedora
> or Linux.
>
> I don't think this would go against the current packaging policy, it
> just would be *a ton" of work :)
>
> This email turned out to be way longer than I expected it to be, but
> Java packaging is a complicated topic.
>
> Thanks,
> Michal
>  
>
>
> I understand that missing components/features due to the source
> requirement
> are annoying but Fedora (and other distros) decided to take the
> "high 

Why distributions package software (was: Re: Re-Launching the Java SIG)

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I wanted to avoid replying to this thread, but this message forced me
to do so since it is spreading misinformation.

On Thu, 2020-05-14 at 06:33 -0500, Ty Young wrote:
> On 5/13/20 4:58 PM, Solomon Peachy wrote:
> > On Wed, May 13, 2020 at 04:04:50PM -0500, Ty Young wrote:
> > > Anyway, I'm just asking that Fedora not repeat what Debian did.
> > > While
> > > I find it to be a bit paranoid, I understand the concerns
> > > regarding
> > > someone sneaking in malware into pre-build binaries. I'm just
> > > asking
> > > Fedora not package the software at all in that case, or any
> > > software
> > > that depends on that software if possible. People who want to
> > > support
> > > Linux by writing software shouldn't be bothered with bug reports
> > > from
> > > issues they never created to begin with.
> > "Fedora" doesn't package software; individuals do.  Those
> > individuals
> > are free to package whatever they like, and Fedora will distribute
> > those
> > packages if they meet the well-established packaging criteria.
> 
> Whichever you choose. Large projects like Gnome and Fedora refer to 
> themselves as one large organization one minute and then as
> individuals 
> the next. It reminds me of how everyone says "Linux" is less
> resource 
> hungry then Windows but "Linux" is just a kernel, as those same
> people 
> will often say in "Linux"'s defense.
> 
> 
> and it's those "well-established" packaging criteria are the reason 
> people stopped packaging Java software for Fedora, according to many
> emails.

People did not stop packaging Java software for Fedora. Some of them
did because packaging some of Java projects is hard, because upstream
makes it hard to do so. By relying on old versions of dependencies,
bundling them, switching buildsystem to gradle (which is basically
impossible to package because of same reasons).

> 
> 
> > Those packagers, and Fedora, are "supporting Linux".
> 
> The amount of disdain and disrespect for third-party, and/or
> independent 
> software developers and/or creators who don't conform to your
> clubhouse 
> rules is palpable.
> 
> 
> > Meanwhile, for every distribution-created "bug" there are ten
> > thousand
> > that created by the upstream authors.  Most upstreams are mature
> > enough
> > to recognize this, and consider distribution-level packaging (and
> > front-line user support) efforts to be, on the whole, a net gain.
> 
> Nonsense spewing with no proof.

Well, you have started this. Can you provide some statistics how many
bugs were introduced by distributions versus upstream bugs.

> 
> The Debian Xscreensaver fiasco is enough proof that contradicts your 
> ridiculous claims and there are plenty more, including:

Well, this does not apply to Fedora as-is because we are trying to ship
latest versions of software as much as possible. That's one of key F's
of Fedora - First.

> 
> * Game developers largely refuse to support Linux, and the some of
> the 
> few that have have or are currently pulling support citing 
> fragmentation(support) issues.

Fragmentation is the issue, yes. But I think this decade we are finally
trying to converge. Flatpaks, RPM improvements and such.

> 
> * Hardware support for AMD GPUs is all over the place and even if 
> technically supported, can be too buggy to use. This is largely
> because 
> kernel/mesa versions are all over the place.

Same here, in Fedora we try to keep kernel and mesa on latest versions
as much as we can, so this does not apply to us.

> 
> * Some software packaged even in large Linux distros like Ubuntu as
> part 
> of their enabled-by-default repos don't even launch. Codeblocks in 
> around 16.04, IIRC, didn't even launch once you install it. You had
> to 
> use their privately hosted repo to install a newer version.

I agree that this is issue and bugs should be reported against such
software. This area is not really explored by distributions much, but
here at least we have quite good test suite for default Workstation
applications, so contributing tests for other software is very welcome.
Probably best place to talk about this would be test@ or ci@.

> 
> * You often need to install third-party repos to get up-to-date
> software 
> since packages are way too slow, or the distros just choose to use
> very 
> old software(Debian).

This problem was supposed to be solved by Fedora Modularity, though
from my POV it did not succeed (yet?).

> 
> * Bugs fixed in newer versions of Gnome shell aren't backported to
> older 
> versions. It looks like they have extended support, but I doubt it's
> for 
> the same amount of time Ubuntu supports an LTS. Even if it did, only 
> newer Gnome shell versions are supported for that long. 18.04
> probably 
> has shell bugs right now that are fixed in newer Gnome versions.

We do backport some of the fixes to stable Fedora versions, but it is
huge effort and we try to do best. Do not forget that packages are
maintained by 

Re: Re-Launching the Java SIG

[Ty Young]

On 5/14/20 6:42 AM, Solomon Peachy wrote:

On Thu, May 14, 2020 at 06:33:47AM -0500, Ty Young wrote:

Whichever you choose. Large projects like Gnome and Fedora refer to
themselves as one large organization one minute and then as individuals the
next. It reminds me of how everyone says "Linux" is less resource hungry
then Windows but "Linux" is just a kernel, as those same people will often
say in "Linux"'s defense.

Please don't change the subject.

The fact of the matter is that nearly nobody is actually paid to work
on, or otherwise improve, Fedora.  As opposed to, say, Windows (either
the OS itself or the greater "ecosystem" around it)



I didn't say otherwise. No one is entitled to free work. If you stand on 
a mountain and shout how much better you are, as the Linux community 
often does, then well... don't cry when people show up with pitch forks 
when they realize they've been "sold" snake oil.



What i'm saying is: Distros like Fedora actively hurt the very people 
who are directly or indirectly helping them. There are single-person run 
projects, like mine, out there that can't possibly do all the work 
needed to have a dozen packages for each distro. It's just not possible 
or, in the case of Java based projects, not even needed to begin with.



That is to say nothing of those distros doing things like Fedora now 
does like running X as user which break otherwise perfectly running 
applications. I can't check in every 6 months to make sure y'all didn't 
break something. I don't have the time nor the download cap(1TB a month, 
GO USA!) for it.





If you want to get volunteers to do something, deriding and insulting
them is highly counterproductive.  Heck, that applies even if they
aren't volunteers.  If you act like an ass, don't complain if you're
treated like one in response.



You're response, honestly, is just an echo of the general mentality many 
distro developers have that I've seen. It's not even unique or different.





I'll follow up on the mostly-unrelated remainder of your reply after I'm
back from the doctor.



It was all in response to the insulation that packaging software for 
each distro is the answer to everything you seemed to have been putting 
forth.





  - Solomon

___
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: Re-Launching the Java SIG

[Nicolas Mailhot via devel]

Le jeudi 14 mai 2020 à 06:33 -0500, Ty Young a écrit :
> 
> I could literally go on and on. The "my-shit-don't-stink" attitude is
> so terrible it's borderline sad.

And years of terminally broken build practices Java-side have finally
resulted in complete capture of all the Java big data code the ASF
wrote and people contributed to by a single ISV, Cloudera. Because it’s
the sole remaining ISV able to build the result and provide it as
secure and supported binaries.

Do you think the corps that paid a lot of the ASF devs to create the
projects that Cloudera sells today did not notice? The next generation
of corp-funded enterprise code will use another language.

Sincerely,

-- 
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: Re-Launching the Java SIG

[Solomon Peachy]

On Thu, May 14, 2020 at 06:33:47AM -0500, Ty Young wrote:
> Whichever you choose. Large projects like Gnome and Fedora refer to
> themselves as one large organization one minute and then as individuals the
> next. It reminds me of how everyone says "Linux" is less resource hungry
> then Windows but "Linux" is just a kernel, as those same people will often
> say in "Linux"'s defense.

Please don't change the subject.

The fact of the matter is that nearly nobody is actually paid to work 
on, or otherwise improve, Fedora.  As opposed to, say, Windows (either 
the OS itself or the greater "ecosystem" around it)

If you want to get volunteers to do something, deriding and insulting 
them is highly counterproductive.  Heck, that applies even if they 
aren't volunteers.  If you act like an ass, don't complain if you're 
treated like one in response.

I'll follow up on the mostly-unrelated remainder of your reply after I'm 
back from the doctor.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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: Re-Launching the Java SIG

[Ty Young]

On 5/13/20 4:58 PM, Solomon Peachy wrote:

On Wed, May 13, 2020 at 04:04:50PM -0500, Ty Young wrote:

Anyway, I'm just asking that Fedora not repeat what Debian did. While
I find it to be a bit paranoid, I understand the concerns regarding
someone sneaking in malware into pre-build binaries. I'm just asking
Fedora not package the software at all in that case, or any software
that depends on that software if possible. People who want to support
Linux by writing software shouldn't be bothered with bug reports from
issues they never created to begin with.

"Fedora" doesn't package software; individuals do.  Those individuals
are free to package whatever they like, and Fedora will distribute those
packages if they meet the well-established packaging criteria.



Whichever you choose. Large projects like Gnome and Fedora refer to 
themselves as one large organization one minute and then as individuals 
the next. It reminds me of how everyone says "Linux" is less resource 
hungry then Windows but "Linux" is just a kernel, as those same people 
will often say in "Linux"'s defense.



and it's those "well-established" packaging criteria are the reason 
people stopped packaging Java software for Fedora, according to many emails.




Those packagers, and Fedora, are "supporting Linux".



The amount of disdain and disrespect for third-party, and/or independent 
software developers and/or creators who don't conform to your clubhouse 
rules is palpable.





Meanwhile, for every distribution-created "bug" there are ten thousand
that created by the upstream authors.  Most upstreams are mature enough
to recognize this, and consider distribution-level packaging (and
front-line user support) efforts to be, on the whole, a net gain.



Nonsense spewing with no proof.


The Debian Xscreensaver fiasco is enough proof that contradicts your 
ridiculous claims and there are plenty more, including:



* Game developers largely refuse to support Linux, and the some of the 
few that have have or are currently pulling support citing 
fragmentation(support) issues.



* Hardware support for AMD GPUs is all over the place and even if 
technically supported, can be too buggy to use. This is largely because 
kernel/mesa versions are all over the place.



* Some software packaged even in large Linux distros like Ubuntu as part 
of their enabled-by-default repos don't even launch. Codeblocks in 
around 16.04, IIRC, didn't even launch once you install it. You had to 
use their privately hosted repo to install a newer version.



* You often need to install third-party repos to get up-to-date software 
since packages are way too slow, or the distros just choose to use very 
old software(Debian).



* Bugs fixed in newer versions of Gnome shell aren't backported to older 
versions. It looks like they have extended support, but I doubt it's for 
the same amount of time Ubuntu supports an LTS. Even if it did, only 
newer Gnome shell versions are supported for that long. 18.04 probably 
has shell bugs right now that are fixed in newer Gnome versions.



* There have been security bugs found in packaged software like Grub 
that have existed in years despite being one of the most widely packaged 
and used software on Linux.



* Linux distros do not resolve dependancy conflicts correctly. Ubuntu 
last time I checked still requires you manually install 32-bit libs in 
order to launch Steam instead of doing that for the user.



* Linux distro GUI package managers are generally poorly designed and 
buggy. That screenshot of Fedora's cinnamon spin's packager manager GUI 
I posted here showed that plenty. Other distros aren't much better. 
Manjaro/Arch Linux's "Pamac" GUI had a bug where it sees itself as a 
running package manager instance and refused to upgrade or install 
software on a failed AUR software build/install.



* Linux distros "taint" software they package and install by, for 
example, enabling shell extensions in Gnome by default. This more likely 
than not results in false bug reports. Fedora even does this!



I could literally go on and on. The "my-shit-don't-stink" attitude is so 
terrible it's borderline sad.





  - Solomon

___
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: 

Re: Re-Launching the Java SIG

[Nicolas Mailhot via devel]

Le jeudi 14 mai 2020 à 11:53 +0200, Michal Srb a écrit :
> 
> Since there is no standard place for shared Java libraries on your
> laptop,

Of course there is one /usr/share/java, which has been defined and used
by Linux distributions since jpackage times (circa ~2000).

Java is not special from a technical POW, its tooling is poor sure but
tooling reflects the values of the community creating and using the
tools, not the reverse.

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: Re-Launching the Java SIG

[Ty Young]

On 5/14/20 4:53 AM, Michal Srb wrote:

Hello,

On Tue, May 12, 2020 at 12:57 PM Felix Schwarz 
mailto:fschw...@fedoraproject.org>> wrote:



Am 12.05.20 um 12:32 schrieb Ty Young:
> Right, I figured it was some Fedora policy and not up to you. I
suppose I
> should have been more clear there. Sorry for any confusion, it
was aimed at
> the Fedora project as a whole as this is a Fedora issue.

This is not a Fedora issue but a consequence of Fedora's core
values. You not
agree with it but "building from source" is so fundamental that it
does not
make sense to even start a discussion about it on fedora-devel.

I suggest you read up on the rationale behind that policy (which
is why I
linked the policy document in the first place).


I agree that building from sources is the right thing to do. However, 
let me play devil's advocate here :)


What makes Java apps different from other language ecosystems is that 
Java apps never share dependencies. There is no concept of 
"system-wide" 3rd-party Java libraries that would be automatically 
added to classpath when JVM starts. I realize that this is technically 
possible to achieve, but that is not how people use it. If you want to 
distribute your Java app, you just bundle it with all its dependencies 
into a beefy tarball and ship it.
And if Java apps never share dependencies, then developers are not 
really forced to keep up with latest versions of libraries. Nobody can 
update the non-existent system-wide Java library that would break 
their application. They are in control.




For the records, Java is going to get a shiny new "Foreign Memory 
Access" API, part of Project Panama, (hopefully) in a few years. With it 
there will be Java applications that have both Java requirements and 
native library requirements.



Anyone who wants to uses it to create Linux software is going to have to 
deal with Linux distros breaking their stuff, no matter what they do, 
just as Fedora broke mine.


___
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: Re-Launching the Java SIG

[Aleksandar Kurtakov]

On Thu, May 14, 2020 at 12:55 PM Michal Srb  wrote:

> Hello,
>
> On Tue, May 12, 2020 at 12:57 PM Felix Schwarz 
> wrote:
>
>>
>> Am 12.05.20 um 12:32 schrieb Ty Young:
>> > Right, I figured it was some Fedora policy and not up to you. I suppose
>> I
>> > should have been more clear there. Sorry for any confusion, it was
>> aimed at
>> > the Fedora project as a whole as this is a Fedora issue.
>>
>> This is not a Fedora issue but a consequence of Fedora's core values. You
>> not
>> agree with it but "building from source" is so fundamental that it does
>> not
>> make sense to even start a discussion about it on fedora-devel.
>>
>> I suggest you read up on the rationale behind that policy (which is why I
>> linked the policy document in the first place).
>>
>
> I agree that building from sources is the right thing to do. However, let
> me play devil's advocate here :)
>
> What makes Java apps different from other language ecosystems is that Java
> apps never share dependencies. There is no concept of "system-wide"
> 3rd-party Java libraries that would be automatically added to classpath
> when JVM starts. I realize that this is technically possible to achieve,
> but that is not how people use it. If you want to distribute your Java app,
> you just bundle it with all its dependencies into a beefy tarball and ship
> it.
> And if Java apps never share dependencies, then developers are not really
> forced to keep up with latest versions of libraries. Nobody can update the
> non-existent system-wide Java library that would break their application.
> They are in control.
>

Long story short - IT world liked so much Java way of doing things so
containers popped up so the same effect can be achieved for any language :P
.


>
> Since there is no standard place for shared Java libraries on your laptop,
> how can you use the packaged Java libraries and develop software against
> them? Sure, you can hack it and make it work on your Fedora 32 machine, but
> your custom Makefile is not guaranteed to work on Fedora 31 or later on 33.
> And your colleague that is on CentOS is out of luck of course. And so are
> all your potential external contributors on their MacBooks and Ubuntus.
> What I am trying to say in this paragraph is that shipping (in RPMs) and
> maintaining individual build-only Java libraries is, at least in my
> opinion, questionable.
>
> Fedora and other linux distributions are trying to do the right thing, but
> things like Java apps simply don't fit in. What Java app developers are
> doing may not be the best thing, but it's been like that for ~20 years, and
> it seems to be "good enough" for the majority of people involved (well,
> developers at least).
> Fedora alone is too insignificant to change it I am afraid.
>
> However, with all that being said. I do like "dnf install my-java-app"
> better than unpacking some tarballs somewhere.
>
> And finally, here comes the "devil's advocate" part of my email.
>
> * building Java libraries and apps from sources?
>   * +1, no doubt about this
> * building Java libraries and apps from sources in a controlled and
> reproducible environment?
>   * yes, please
> * building Java libraries and apps from sources from SRPMs?
>   * do we really need the RPM overhead here?
> * shipping (in RPMs) and maintaining Java libraries that are not runtime
> dependencies of Java applications that we want to have in Fedora?
>   * nope, why? build such build-only dependencies from sources, make sure
> they are OK license-wise, but do not ship them to users (as explained
> above, they are not very useful for developers anyway)
>
> We can do license reviews, we can build from sources, but we don't
> necessarily have to do all this in RPMs.
> We can do all the right things, store (our binary) results in a
> language-native way, which would be a Maven repository controlled by Fedora
> in this case, and then simply wrap our good binary JARs into RPMs, without
> rebuilding them all the time.
>
> Note having such language-native repository full of good and reviewed Java
> libraries would mean that developers that care about such things could
> actually start using it instead of the official Maven repository. And they
> wouldn't be tied to a specific version of Fedora or Linux.
>
> I don't think this would go against the current packaging policy, it just
> would be *a ton" of work :)
>
> This email turned out to be way longer than I expected it to be, but Java
> packaging is a complicated topic.
>
> Thanks,
> Michal
>
>
>>
>> I understand that missing components/features due to the source
>> requirement
>> are annoying but Fedora (and other distros) decided to take the "high
>> road"
>> here and actually fix stuff instead of shipping whatever upstream came up
>> with.
>>
>> Felix
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> 

Re: Re-Launching the Java SIG

[Michal Srb]

Hello,

On Tue, May 12, 2020 at 12:57 PM Felix Schwarz 
wrote:

>
> Am 12.05.20 um 12:32 schrieb Ty Young:
> > Right, I figured it was some Fedora policy and not up to you. I suppose I
> > should have been more clear there. Sorry for any confusion, it was aimed
> at
> > the Fedora project as a whole as this is a Fedora issue.
>
> This is not a Fedora issue but a consequence of Fedora's core values. You
> not
> agree with it but "building from source" is so fundamental that it does not
> make sense to even start a discussion about it on fedora-devel.
>
> I suggest you read up on the rationale behind that policy (which is why I
> linked the policy document in the first place).
>

I agree that building from sources is the right thing to do. However, let
me play devil's advocate here :)

What makes Java apps different from other language ecosystems is that Java
apps never share dependencies. There is no concept of "system-wide"
3rd-party Java libraries that would be automatically added to classpath
when JVM starts. I realize that this is technically possible to achieve,
but that is not how people use it. If you want to distribute your Java app,
you just bundle it with all its dependencies into a beefy tarball and ship
it.
And if Java apps never share dependencies, then developers are not really
forced to keep up with latest versions of libraries. Nobody can update the
non-existent system-wide Java library that would break their application.
They are in control.

Since there is no standard place for shared Java libraries on your laptop,
how can you use the packaged Java libraries and develop software against
them? Sure, you can hack it and make it work on your Fedora 32 machine, but
your custom Makefile is not guaranteed to work on Fedora 31 or later on 33.
And your colleague that is on CentOS is out of luck of course. And so are
all your potential external contributors on their MacBooks and Ubuntus.
What I am trying to say in this paragraph is that shipping (in RPMs) and
maintaining individual build-only Java libraries is, at least in my
opinion, questionable.

Fedora and other linux distributions are trying to do the right thing, but
things like Java apps simply don't fit in. What Java app developers are
doing may not be the best thing, but it's been like that for ~20 years, and
it seems to be "good enough" for the majority of people involved (well,
developers at least).
Fedora alone is too insignificant to change it I am afraid.

However, with all that being said. I do like "dnf install my-java-app"
better than unpacking some tarballs somewhere.

And finally, here comes the "devil's advocate" part of my email.

* building Java libraries and apps from sources?
  * +1, no doubt about this
* building Java libraries and apps from sources in a controlled and
reproducible environment?
  * yes, please
* building Java libraries and apps from sources from SRPMs?
  * do we really need the RPM overhead here?
* shipping (in RPMs) and maintaining Java libraries that are not runtime
dependencies of Java applications that we want to have in Fedora?
  * nope, why? build such build-only dependencies from sources, make sure
they are OK license-wise, but do not ship them to users (as explained
above, they are not very useful for developers anyway)

We can do license reviews, we can build from sources, but we don't
necessarily have to do all this in RPMs.
We can do all the right things, store (our binary) results in a
language-native way, which would be a Maven repository controlled by Fedora
in this case, and then simply wrap our good binary JARs into RPMs, without
rebuilding them all the time.

Note having such language-native repository full of good and reviewed Java
libraries would mean that developers that care about such things could
actually start using it instead of the official Maven repository. And they
wouldn't be tied to a specific version of Fedora or Linux.

I don't think this would go against the current packaging policy, it just
would be *a ton" of work :)

This email turned out to be way longer than I expected it to be, but Java
packaging is a complicated topic.

Thanks,
Michal


>
> I understand that missing components/features due to the source requirement
> are annoying but Fedora (and other distros) decided to take the "high road"
> here and actually fix stuff instead of shipping whatever upstream came up
> with.
>
> 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 

Re: Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 10:59 PM Ty Young  wrote:
> As someone who has been burned due to Fedora's goody little two shoes
> policies, I'd kindly ask that Fedora take a hike and not package the
> software at all.

I find it kind of ironic that this is exactly what happened, but you
seem not to be aware of it - despite the whole sub-thread having
started because of this?
gradle was no longer maintainable as an RPM package, so it - and most
packages that require it - were removed from fedora. end of story.
Isn't this what you're arguing for here?

Fabio
___
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: Re-Launching the Java SIG

[Fabio Valentini]

On Wed, May 13, 2020 at 10:38 PM Jerry James  wrote:
>
> On Mon, May 11, 2020 at 1:46 PM Fabio Valentini  wrote:
> > So, if you're interested, please consider joining this group effort.
> > I'll get new members set up with the FAS group / pagure project / mailing 
> > list.
>
> Like some others who have responded, I probably won't be much help due
> to lack of time, but since I maintain a handful of Java packages, sign
> me up too.  Thanks for spearheading this!

Thanks for joining us!
I pushed all the necessary buttons for your group memberships to get set :)

Fabio

> --
> Jerry James
> http://www.jamezone.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
___
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: Re-Launching the Java SIG

[Ty Young]

On 5/13/20 4:16 PM, James Cassell wrote:

On Wed, May 13, 2020, at 5:04 PM, Ty Young wrote:

On 5/13/20 12:04 PM, Robbie Harwood wrote:

Ty Young  writes:


On 5/12/20 5:55 AM, Felix Schwarz wrote:

Am 12.05.20 um 12:32 schrieb Ty Young:


Right, I figured it was some Fedora policy and not up to you. I
suppose I should have been more clear there. Sorry for any
confusion, it was aimed at the Fedora project as a whole as this is
a Fedora issue.

This is not a Fedora issue but a consequence of Fedora's core
values. You not agree with it but "building from source" is so
fundamental that it does not make sense to even start a discussion
about it on fedora-devel.

I suggest you read up on the rationale behind that policy (which is
why I linked the policy document in the first place).

I understand that missing components/features due to the source
requirement are annoying but Fedora (and other distros) decided to
take the "high road" here and actually fix stuff instead of shipping
whatever upstream came up with.

As someone who has been burned due to Fedora's goody little two shoes
policies, I'd kindly ask that Fedora take a hike and not package the
software at all.

This is not "being excellent to each other".  Let's keep in mind that we
are all here for the same reason (caring about Fedora), and that this
makes us colleagues - even when we disagree.


Neither was the threat and intimidation by higher ups at Red Hat or
Fedora, which very few people on this seem to care about despite
constantly bringing up the CoC. Selective enforcement probably isn't
"being excellent to each other" either.


Anyway, I'm just asking that Fedora not repeat what Debian did. While I
find it to be a bit paranoid, I understand the concerns regarding
someone sneaking in malware into pre-build binaries. I'm just asking
Fedora not package the software at all in that case, or any software
that depends on that software if possible. People who want to support
Linux by writing software shouldn't be bothered with bug reports from
issues they never created to begin with.


Is your position that Fedora should not package any software where the Upstream 
provides binaries? If so, that would seem to defeat the purpose of a Linux 
distribution, IMHO.



No. If source code is provided side-by-side with the binaries(as-is the 
case with Gradle and many other software) then it's fine as the source 
code provided is *supposed* to give you the binaries once compiled 
anyway. If it doesn't then something shady may be going on.



Although I highly doubt the security claims that people are making in 
favor of compiling from source. Does every Fedora packager *actually* 
pore over every line of code in order to make sure it doesn't do 
anything shady? I really doubt it, that would be a superhuman task in 
many cases. If you can't trust binaries coming from the horses mouth 
then I'm not so sure you can trust the side-by-side source code either...




V/r,
James Cassell
___
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: Re-Launching the Java SIG

[Solomon Peachy]

On Wed, May 13, 2020 at 04:04:50PM -0500, Ty Young wrote:
> Anyway, I'm just asking that Fedora not repeat what Debian did. While 
> I find it to be a bit paranoid, I understand the concerns regarding 
> someone sneaking in malware into pre-build binaries. I'm just asking 
> Fedora not package the software at all in that case, or any software 
> that depends on that software if possible. People who want to support 
> Linux by writing software shouldn't be bothered with bug reports from 
> issues they never created to begin with.

"Fedora" doesn't package software; individuals do.  Those individuals 
are free to package whatever they like, and Fedora will distribute those 
packages if they meet the well-established packaging criteria.

Those packagers, and Fedora, are "supporting Linux".

Meanwhile, for every distribution-created "bug" there are ten thousand 
that created by the upstream authors.  Most upstreams are mature enough 
to recognize this, and consider distribution-level packaging (and 
front-line user support) efforts to be, on the whole, a net gain.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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: Re-Launching the Java SIG

[James Cassell]

On Wed, May 13, 2020, at 5:04 PM, Ty Young wrote:
> 
> On 5/13/20 12:04 PM, Robbie Harwood wrote:
> > Ty Young  writes:
> >
> >> On 5/12/20 5:55 AM, Felix Schwarz wrote:
> >>> Am 12.05.20 um 12:32 schrieb Ty Young:
> >>>
>  Right, I figured it was some Fedora policy and not up to you. I
>  suppose I should have been more clear there. Sorry for any
>  confusion, it was aimed at the Fedora project as a whole as this is
>  a Fedora issue.
> >>> This is not a Fedora issue but a consequence of Fedora's core
> >>> values. You not agree with it but "building from source" is so
> >>> fundamental that it does not make sense to even start a discussion
> >>> about it on fedora-devel.
> >>>
> >>> I suggest you read up on the rationale behind that policy (which is
> >>> why I linked the policy document in the first place).
> >>>
> >>> I understand that missing components/features due to the source
> >>> requirement are annoying but Fedora (and other distros) decided to
> >>> take the "high road" here and actually fix stuff instead of shipping
> >>> whatever upstream came up with.
> >> As someone who has been burned due to Fedora's goody little two shoes
> >> policies, I'd kindly ask that Fedora take a hike and not package the
> >> software at all.
> > This is not "being excellent to each other".  Let's keep in mind that we
> > are all here for the same reason (caring about Fedora), and that this
> > makes us colleagues - even when we disagree.
> 
> 
> Neither was the threat and intimidation by higher ups at Red Hat or 
> Fedora, which very few people on this seem to care about despite 
> constantly bringing up the CoC. Selective enforcement probably isn't 
> "being excellent to each other" either.
> 
> 
> Anyway, I'm just asking that Fedora not repeat what Debian did. While I 
> find it to be a bit paranoid, I understand the concerns regarding 
> someone sneaking in malware into pre-build binaries. I'm just asking 
> Fedora not package the software at all in that case, or any software 
> that depends on that software if possible. People who want to support 
> Linux by writing software shouldn't be bothered with bug reports from 
> issues they never created to begin with.
> 

Is your position that Fedora should not package any software where the Upstream 
provides binaries? If so, that would seem to defeat the purpose of a Linux 
distribution, IMHO.

V/r,
James Cassell
___
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: Re-Launching the Java SIG

[Ty Young]

On 5/13/20 12:04 PM, Robbie Harwood wrote:

Ty Young  writes:


On 5/12/20 5:55 AM, Felix Schwarz wrote:

Am 12.05.20 um 12:32 schrieb Ty Young:


Right, I figured it was some Fedora policy and not up to you. I
suppose I should have been more clear there. Sorry for any
confusion, it was aimed at the Fedora project as a whole as this is
a Fedora issue.

This is not a Fedora issue but a consequence of Fedora's core
values. You not agree with it but "building from source" is so
fundamental that it does not make sense to even start a discussion
about it on fedora-devel.

I suggest you read up on the rationale behind that policy (which is
why I linked the policy document in the first place).

I understand that missing components/features due to the source
requirement are annoying but Fedora (and other distros) decided to
take the "high road" here and actually fix stuff instead of shipping
whatever upstream came up with.

As someone who has been burned due to Fedora's goody little two shoes
policies, I'd kindly ask that Fedora take a hike and not package the
software at all.

This is not "being excellent to each other".  Let's keep in mind that we
are all here for the same reason (caring about Fedora), and that this
makes us colleagues - even when we disagree.



Neither was the threat and intimidation by higher ups at Red Hat or 
Fedora, which very few people on this seem to care about despite 
constantly bringing up the CoC. Selective enforcement probably isn't 
"being excellent to each other" either.



Anyway, I'm just asking that Fedora not repeat what Debian did. While I 
find it to be a bit paranoid, I understand the concerns regarding 
someone sneaking in malware into pre-build binaries. I'm just asking 
Fedora not package the software at all in that case, or any software 
that depends on that software if possible. People who want to support 
Linux by writing software shouldn't be bothered with bug reports from 
issues they never created to begin with.





Thanks,
--Robbie

___
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: Re-Launching the Java SIG

[Jerry James]

On Mon, May 11, 2020 at 1:46 PM Fabio Valentini  wrote:
> So, if you're interested, please consider joining this group effort.
> I'll get new members set up with the FAS group / pagure project / mailing 
> list.

Like some others who have responded, I probably won't be much help due
to lack of time, but since I maintain a handful of Java packages, sign
me up too.  Thanks for spearheading this!
-- 
Jerry James
http://www.jamezone.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: Re-Launching the Java SIG

[Robbie Harwood]

Ty Young  writes:

> On 5/12/20 5:55 AM, Felix Schwarz wrote:
>> Am 12.05.20 um 12:32 schrieb Ty Young:
>>
>>> Right, I figured it was some Fedora policy and not up to you. I
>>> suppose I should have been more clear there. Sorry for any
>>> confusion, it was aimed at the Fedora project as a whole as this is
>>> a Fedora issue.
>>
>> This is not a Fedora issue but a consequence of Fedora's core
>> values. You not agree with it but "building from source" is so
>> fundamental that it does not make sense to even start a discussion
>> about it on fedora-devel.
>>
>> I suggest you read up on the rationale behind that policy (which is
>> why I linked the policy document in the first place).
>>
>> I understand that missing components/features due to the source
>> requirement are annoying but Fedora (and other distros) decided to
>> take the "high road" here and actually fix stuff instead of shipping
>> whatever upstream came up with.
>
> As someone who has been burned due to Fedora's goody little two shoes 
> policies, I'd kindly ask that Fedora take a hike and not package the 
> software at all.

This is not "being excellent to each other".  Let's keep in mind that we
are all here for the same reason (caring about Fedora), and that this
makes us colleagues - even when we disagree.

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: Re-Launching the Java SIG

[Christopher Engelhard]

On 13.05.20 14:55, Solomon Peachy wrote:
> On Tue, May 12, 2020 at 10:57:43PM -0400, Gerald Henriksen wrote:
>> The only way to make sure that the stuff included with Fedora is open
>> source is to build it from source - simply grabbing a binary provided
>> by an upstream means upstream could slip in some closed source
>> portions or have such a complex and undocumented build system that the
>> project may as well be closed source because no one else can build it.
> 
> I've personally encountered Java stuff that, when compiled from its 
> sources, immediately crashed, whereas the "official binaries" worked.

That is just incredibly broken.

Things like this are the reason why I think the build-from-source
principle is important, regardless of the inconvience it undeniably causes.

Christopher
___
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: Re-Launching the Java SIG

[Solomon Peachy]

On Tue, May 12, 2020 at 10:57:43PM -0400, Gerald Henriksen wrote:
> The only way to make sure that the stuff included with Fedora is open
> source is to build it from source - simply grabbing a binary provided
> by an upstream means upstream could slip in some closed source
> portions or have such a complex and undocumented build system that the
> project may as well be closed source because no one else can build it.

I've personally encountered Java stuff that, when compiled from its 
sources, immediately crashed, whereas the "official binaries" worked.

Why not use the official binaries?  Because they had a showstopper bug 
in my environment, and I was trying to devise a fix.

(Even absent that bug, the official binaries had extra "features" like 
 proprietary instrumentation/etc libraries that I (and many others) consider
 unacceptable..)

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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: Re-Launching the Java SIG

[Kevin Kofler]

Gerald Henriksen wrote:
> The only way to make sure that the stuff included with Fedora is open
> source is to build it from source - simply grabbing a binary provided
> by an upstream means upstream could slip in some closed source
> portions or have such a complex and undocumented build system that the
> project may as well be closed source because no one else can build it.

And arguably that (after the "or") is exactly what Gradle is. ;-)

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

Re: Re-Launching the Java SIG

[Gerald Henriksen]

On Tue, 12 May 2020 15:58:39 -0500, you wrote:

>As someone who has been burned due to Fedora's goody little two shoes 
>policies, I'd kindly ask that Fedora take a hike and not package the 
>software at all.

The only way to make sure that the stuff included with Fedora is open
source is to build it from source - simply grabbing a binary provided
by an upstream means upstream could slip in some closed source
portions or have such a complex and undocumented build system that the
project may as well be closed source because no one else can build it.
___
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: Re-Launching the Java SIG

[Philip Rhoades]

Ty,


On 2020-05-13 06:58, Ty Young wrote:

On 5/12/20 5:55 AM, Felix Schwarz wrote:

Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I 
suppose I
should have been more clear there. Sorry for any confusion, it was 
aimed at

the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. 
You not
agree with it but "building from source" is so fundamental that it 
does not

make sense to even start a discussion about it on fedora-devel.

I suggest you read up on the rationale behind that policy (which is 
why I

linked the policy document in the first place).

I understand that missing components/features due to the source 
requirement
are annoying but Fedora (and other distros) decided to take the "high 
road"
here and actually fix stuff instead of shipping whatever upstream came 
up with.



As someone who has been burned due to Fedora's goody little two shoes
policies, I'd kindly ask that Fedora take a hike and not package the
software at all.



That should be "little goody two shoes policies" . .

P.
--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au
___
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: Re-Launching the Java SIG

[Ty Young]

On 5/12/20 5:55 AM, Felix Schwarz wrote:

Am 12.05.20 um 12:32 schrieb Ty Young:

Right, I figured it was some Fedora policy and not up to you. I suppose I
should have been more clear there. Sorry for any confusion, it was aimed at
the Fedora project as a whole as this is a Fedora issue.

This is not a Fedora issue but a consequence of Fedora's core values. You not
agree with it but "building from source" is so fundamental that it does not
make sense to even start a discussion about it on fedora-devel.

I suggest you read up on the rationale behind that policy (which is why I
linked the policy document in the first place).

I understand that missing components/features due to the source requirement
are annoying but Fedora (and other distros) decided to take the "high road"
here and actually fix stuff instead of shipping whatever upstream came up with.



As someone who has been burned due to Fedora's goody little two shoes 
policies, I'd kindly ask that Fedora take a hike and not package the 
software at all.



Other software developers SHOULD NEVER have to deal with bug reports 
from Fedora or any other distro because  they want to modify software 
instead of taking what was already made, breaking things as a result. 
This isn't the first time a Linux distro has done this either, IIRC, 
there was an issue with Debian and the developer of the Xscreensaver 
software too.



At worst all you're doing is angering people who want to support Linux 
and at best hurting yourselves. Stop it.





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: Re-Launching the Java SIG

[John W. Himpel]

On Mon, 2020-05-11 at 21:45 +0200, Fabio Valentini wrote:
> This past weekend I finally decided to jump off the cliff and attempt
> to re-launch the Java SIG. It seems there's some interest in keeping
> the Java stack maintained, it's just not focused or organized right
> now.
> 
> What we did when starting the Stewardship SIG seems to have worked
> out
> pretty well, so I'm trying to follow in those footsteps here:
> 
> - new proper FAS / pkgdb group: java-maint-sig ("java-sig" is
> occupied
> by an old, unused bot account)
> - new private mailing list: java-maint-sig (for RHBZ bugs - so,
> possibly, also CVEs - hence, private)
> - tracking project on pagure: https://pagure.io/java-maint-sig (for
> maintenance scripts, tracking tickets, awesome package dashboards,
> etc.)
> 
> There's already a public fedora mailing list for Java (java-devel),
> and and IRC channel (#fedora-java on freenode.net), which we will
> continue to use. Sadly, the existing wiki page for the Java SIG is
> hopelessly outdated, so I'm tempted to just scrap it and point
> readers
> to the pagure tracking project once it's set up beyond a basic README
> file.
> 
> Major upcoming projects for the "new" Java Package Maintainers group
> include:
> 
> - managing OpenJDK 11 / Java 11 transition for hundreds of Java
> packages in fedora 33
> - starting to transition well-maintained Java packages from the
> Stewardship SIG back into Java SIG
> - possibly porting packages from gradle to maven to fix build issues
> and broken dependencies
> - transitioning from old java.net / JavaEE projects to the new ones
> now under the eclipse-ee4j umbrella
> 
> I know that - among others - the PKI team, Neuro SIG, and Eclipse
> maintainers depend on parts of the java stack for their packages, so
> I
> hope that we can work together with them on these things, as well.
> 
> So, if you're interested, please consider joining this group effort.
> I'll get new members set up with the FAS group / pagure project /
> mailing list.
> 
> Let's make this happen.
> Fabio
> ___
> 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

I'm basically an developer of jee applications. Not sure how much I can
assist, but will do whatever I can to help.

fas account: jwhimpel

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

Re: [fedora-java] Re: Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 6:17 PM Igor Raits
 wrote:
> Count me in! I don't think I can help much, but at least can give some
> suggestions.
>
> > Let's make this happen.
>
> Good luck, Fabio!

Thanks! Every bit of help counts.
You should now be all set with FAS group / pagure project / mailing
list subscription.

Fabio
___
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: Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 5:43 PM Markku Korkeala  wrote:
> Great, really appreciate your work.

Thank you!

> Count me in! I'm relatively new to fedora and rpm packaging, but got ~20
> years of working with Java and my packages depends on the Java
> ecosystem. FAS account: korkeala.
>
> Markku.

Great! You should be all set now. Group membership should show up at
https://src.fedoraproject.org/group/java-maint-sig after logging out
and back in.

Glad to have you on board!

Fabio
___
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: Re-Launching the Java SIG

[Andrew Haley]

On 5/12/20 11:55 AM, Felix Schwarz wrote:
>
> Am 12.05.20 um 12:32 schrieb Ty Young:
>> Right, I figured it was some Fedora policy and not up to you. I suppose I
>> should have been more clear there. Sorry for any confusion, it was aimed at
>> the Fedora project as a whole as this is a Fedora issue.
>
> This is not a Fedora issue but a consequence of Fedora's core values. You not
> agree with it but "building from source" is so fundamental that it does not
> make sense to even start a discussion about it on fedora-devel.

Yes, exactly. It's not a Java thing, it's a free software thing. If
we just grab binaries how do we know that they respect the basic
freedoms?

> I suggest you read up on the rationale behind that policy (which is
> why I linked the policy document in the first place).
>
> I understand that missing components/features due to the source
> requirement are annoying but Fedora (and other distros) decided to
> take the "high road" here and actually fix stuff instead of shipping
> whatever upstream came up with.

Quite. The high road is never the easy road. Thank you.

-- 
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: Re-Launching the Java SIG

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2020-05-11 at 21:45 +0200, Fabio Valentini wrote:
> This past weekend I finally decided to jump off the cliff and attempt
> to re-launch the Java SIG. It seems there's some interest in keeping
> the Java stack maintained, it's just not focused or organized right
> now.
> 
> What we did when starting the Stewardship SIG seems to have worked
> out
> pretty well, so I'm trying to follow in those footsteps here:
> 
> - new proper FAS / pkgdb group: java-maint-sig ("java-sig" is
> occupied
> by an old, unused bot account)
> - new private mailing list: java-maint-sig (for RHBZ bugs - so,
> possibly, also CVEs - hence, private)
> - tracking project on pagure: https://pagure.io/java-maint-sig (for
> maintenance scripts, tracking tickets, awesome package dashboards,
> etc.)
> 
> There's already a public fedora mailing list for Java (java-devel),
> and and IRC channel (#fedora-java on freenode.net), which we will
> continue to use. Sadly, the existing wiki page for the Java SIG is
> hopelessly outdated, so I'm tempted to just scrap it and point
> readers
> to the pagure tracking project once it's set up beyond a basic README
> file.
> 
> Major upcoming projects for the "new" Java Package Maintainers group
> include:
> 
> - managing OpenJDK 11 / Java 11 transition for hundreds of Java
> packages in fedora 33
> - starting to transition well-maintained Java packages from the
> Stewardship SIG back into Java SIG
> - possibly porting packages from gradle to maven to fix build issues
> and broken dependencies
> - transitioning from old java.net / JavaEE projects to the new ones
> now under the eclipse-ee4j umbrella
> 
> I know that - among others - the PKI team, Neuro SIG, and Eclipse
> maintainers depend on parts of the java stack for their packages, so
> I
> hope that we can work together with them on these things, as well.
> 
> So, if you're interested, please consider joining this group effort.
> I'll get new members set up with the FAS group / pagure project /
> mailing list.

Count me in! I don't think I can help much, but at least can give some
suggestions.

> Let's make this happen.

Good luck, Fabio!

> Fabio
> ___
> 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
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl66y7cACgkQEV1auJxc
Hh43Gg/+NzTe/eeGyuWQnKkPwiImM0wgg3ZUEMftfURWLFLpK3zNYBK1jH2hNKHY
VA7d3NB4DhTtDAwQUVtFCmcfTuoLpZeKvvlaK5T8z0jIRqBEaHJx8NAqQFhnYw0q
NGjvogdsQMW1uFbnBJrxD3o2CIXwonmE4va204vOLMybF+jSw/1s6GlLVZgX6PsL
lSGIfmYWyf5UVUUwhP4zfzKZy56EEIOVjN+gq0ZdywPQyEfz+lpbKsBdCjL/Gwf7
wMJm0Y+tO/J/jyeTQ7WPnJUbwL6YHcb+iDOSZqGBvfxp8bRa7k3lFbKdgKZzV+hs
5q9xYlNatpaH+axMwpBvDch31yZ7OemFxv39Kx70LP+HZqKYokDR8MNQr80bIynt
jSa11wxzmOu5QjQJclORVdik/KsdjL/2MHCA4tFj/NFWQz2lIDX1wMCxIvmTyz3O
NsOLGT/Cc8ZfFCCMnC/i0TtUcyytNurB9t4CK8RzwNeqVT7VeeZs+q/OHjlsedA5
orooA6ovd9B+w7hajlvn/cdvWVFuAq3GYZm/DQaaklZCSxYpBZrUYxS3tJbmOqhR
4gch4aQoiLWEKUeV/G52UvRfky0B1ke7d7w3mscBB+43/Vxlsps4/PT1yt7/psNX
gwrVyfplA15ZRcoXB8HVimzCV9YownNcHAFdtNBdt3Aq3/UADpk=
=jv6E
-END 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: Re-Launching the Java SIG

[Markku Korkeala]

On 5/11/20 10:45 PM, Fabio Valentini wrote:
> This past weekend I finally decided to jump off the cliff and attempt
> to re-launch the Java SIG. It seems there's some interest in keeping
> the Java stack maintained, it's just not focused or organized right
> now
Great, really appreciate your work.

> 
> So, if you're interested, please consider joining this group effort.
> I'll get new members set up with the FAS group / pagure project / mailing 
> list.

Count me in! I'm relatively new to fedora and rpm packaging, but got ~20
years of working with Java and my packages depends on the Java
ecosystem. FAS account: korkeala.

Markku.



> Let's make this happen.
> Fabio
> ___
> 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: Re-Launching the Java SIG

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 12, 2020 at 10:53:32AM -0400, Omair Majid wrote:
> Hi,
> 
> A bit of a tangential question:
> 
> Zbigniew Jędrzejewski-Szmek  writes:
> 
> > So maybe just nuke the outdated parts (member lists, "state of affairs"
> > content), and keep the rest?
> 
> My wiki-foo sucks. Is there some way to automatically generate a list of
> members on the wiki from a FAS group?

Maybe just link to some appropriate page (src.fp.o?). I don't think we
need to duplicate this information on the wiki.

Zbyszek
___
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: Re-Launching the Java SIG

[Omair Majid]

Hi,

A bit of a tangential question:

Zbigniew Jędrzejewski-Szmek  writes:

> So maybe just nuke the outdated parts (member lists, "state of affairs"
> content), and keep the rest?

My wiki-foo sucks. Is there some way to automatically generate a list of
members on the wiki from a FAS group?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
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: Re-Launching the Java SIG

[Alex Scheel]

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, May 12, 2020 9:44:33 AM
> Subject: Re: Re-Launching the Java SIG
> 
> On Tue, May 12, 2020 at 3:34 PM Alex Scheel  wrote:
> >
> > Obviously count us in, Fabio :-)
> 
> *Us* means the three guys from the Dogtag PKI team? :)

Yeah, but mostly expect Dinesh and I :)

> 
> > Do we need a two-step bootstrap process? A first (offline) step where we
> > run
> > gradle-wrapper and fetch all the resources, put all online dependencies
> > into a
> > SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a
> > bootstrapped version which works) and then replacing _all_ assets with
> > versions
> > built using the bootstrapped gradle and finally rebuilding gradle?
> >
> > It'd be hell to set up the first time (two .specs?) and hell to make sure
> > we
> > get every package at the right version. But theoretically possible? :-)
> >
> >
> > But it might allow us to skip incremental bootstrap from a really old
> > gradle
> > version and might even get us a process which works for future bootstraps.
> 
> That's an innocent thought :) I'm afraid it won't work though.
> Do you think gradle is downloading source code for its dependencies?
> Nope, it only downloads prebuilt JARs.

Right -- I wasn't suggesting that it'd download source code. Merely that a
binary-JAR-bootstrapped Gradle could be used to (re)-build all of the
libraries it needed (from source this time!) and then re-build itself
(using those source-built libraries and building a new gradle from
source).

The internet-downloaded JARs could be put into lookaside and the SRPM
could pull them, put them in the right location, and finish the initial
Gradle build. Koji would finish the build and the resulting gradle would
be available for us to use.

IIRC the restriction on source code builds of packages can be waived for
bootstrap-only builds. So for initial build of gradle, we're fine using
the binary wrapper as long as we fully replace it with source-only builds.

Someone with a more recent understanding of packaging policy can weigh
in here though.

> 
> So the build script loads a prebuilt gradle-wraper.jar (that's shipped
> with the gradle sources) that then in turn downloads more prebuilt
> JARs from the gradle repository to satisfy gradle's build dependencies
> which are then used to actually build full gradle ...

Right :) So we'd take all of those new downloads and put them into
lookaside and ship a SPRM that finishes the build based off of those
internet-downloaded JARs. This satisifies Koji's no-internet policy
while giving us a (hopefully) useful Gradle build system as output.

> ___
> 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: Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 3:34 PM Alex Scheel  wrote:
>
> Obviously count us in, Fabio :-)

*Us* means the three guys from the Dogtag PKI team? :)

> Do we need a two-step bootstrap process? A first (offline) step where we run
> gradle-wrapper and fetch all the resources, put all online dependencies into a
> SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a
> bootstrapped version which works) and then replacing _all_ assets with 
> versions
> built using the bootstrapped gradle and finally rebuilding gradle?
>
> It'd be hell to set up the first time (two .specs?) and hell to make sure we
> get every package at the right version. But theoretically possible? :-)
>
>
> But it might allow us to skip incremental bootstrap from a really old gradle
> version and might even get us a process which works for future bootstraps.

That's an innocent thought :) I'm afraid it won't work though.
Do you think gradle is downloading source code for its dependencies?
Nope, it only downloads prebuilt JARs.

So the build script loads a prebuilt gradle-wraper.jar (that's shipped
with the gradle sources) that then in turn downloads more prebuilt
JARs from the gradle repository to satisfy gradle's build dependencies
which are then used to actually build full gradle ...
___
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: Re-Launching the Java SIG

[Alex Scheel]

Obviously count us in, Fabio :-)

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, May 12, 2020 6:39:04 AM
> Subject: Re: Re-Launching the Java SIG
> 
> On Tue, May 12, 2020 at 12:34 PM Ty Young  wrote:
> > Right, I figured it was some Fedora policy and not up to you. I suppose
> > I should have been more clear there. Sorry for any confusion, it was
> > aimed at the Fedora project as a whole as this is a Fedora issue.
> 
> I am aware that Arch is just packaging up the binary release artifacts
> published by the gradle project.
> But that's just never going to fly for fedora.
> 
> Arch is also the only distro I looked at that does this, everybody
> else (at least debian, ubuntu, OpenSUSE) is stuck at an ancient
> version, if gradle is available at all.
> 
> > FWIW, I can compile 6.4 just fine on Arch Linux using the Github source
> > code via:
> >
> >
> > ./gradlew allZip
> 
> Now try doing that offline and without using the pre-built
> gradle/wrapper/gradle-wrapper.jar :)
> You'll be surprised how much junk the build process still needs to download.

Do we need a two-step bootstrap process? A first (offline) step where we run
gradle-wrapper and fetch all the resources, put all online dependencies into a
SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a
bootstrapped version which works) and then replacing _all_ assets with versions
built using the bootstrapped gradle and finally rebuilding gradle?

It'd be hell to set up the first time (two .specs?) and hell to make sure we
get every package at the right version. But theoretically possible? :-)


But it might allow us to skip incremental bootstrap from a really old gradle
version and might even get us a process which works for future bootstraps.



- Alex

> 
> Fabio
> 
> > >
> > > 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
> ___
> 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: Re-Launching the Java SIG

[Severin Gehwolf]

On Mon, 2020-05-11 at 21:45 +0200, Fabio Valentini wrote:
> This past weekend I finally decided to jump off the cliff and attempt
> to re-launch the Java SIG. It seems there's some interest in keeping
> the Java stack maintained, it's just not focused or organized right
> now.
> 
> What we did when starting the Stewardship SIG seems to have worked
> out
> pretty well, so I'm trying to follow in those footsteps here:
> 
> - new proper FAS / pkgdb group: java-maint-sig ("java-sig" is
> occupied
> by an old, unused bot account)
> - new private mailing list: java-maint-sig (for RHBZ bugs - so,
> possibly, also CVEs - hence, private)
> - tracking project on pagure: https://pagure.io/java-maint-sig (for
> maintenance scripts, tracking tickets, awesome package dashboards,
> etc.)
> 
> There's already a public fedora mailing list for Java (java-devel),
> and and IRC channel (#fedora-java on freenode.net), which we will
> continue to use. Sadly, the existing wiki page for the Java SIG is
> hopelessly outdated, so I'm tempted to just scrap it and point
> readers
> to the pagure tracking project once it's set up beyond a basic README
> file.
> 
> Major upcoming projects for the "new" Java Package Maintainers group
> include:
> 
> - managing OpenJDK 11 / Java 11 transition for hundreds of Java
> packages in fedora 33
> - starting to transition well-maintained Java packages from the
> Stewardship SIG back into Java SIG
> - possibly porting packages from gradle to maven to fix build issues
> and broken dependencies
> - transitioning from old java.net / JavaEE projects to the new ones
> now under the eclipse-ee4j umbrella
> 
> I know that - among others - the PKI team, Neuro SIG, and Eclipse
> maintainers depend on parts of the java stack for their packages, so
> I
> hope that we can work together with them on these things, as well.
> 
> So, if you're interested, please consider joining this group effort.
> I'll get new members set up with the FAS group / pagure project /
> mailing list.
> 
> Let's make this happen.

Thanks Fabio!

I'll be happy to join and will try to liaise as we continue to look
after the OpenJDK packages themselves.

Cheers,
Severin
___
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: Re-Launching the Java SIG

[Ty Young]

On 5/12/20 5:39 AM, Fabio Valentini wrote:

On Tue, May 12, 2020 at 12:34 PM Ty Young  wrote:

Right, I figured it was some Fedora policy and not up to you. I suppose
I should have been more clear there. Sorry for any confusion, it was
aimed at the Fedora project as a whole as this is a Fedora issue.

I am aware that Arch is just packaging up the binary release artifacts
published by the gradle project.
But that's just never going to fly for fedora.


Well, guess I now know why no one wants to package software for Fedora.



Arch is also the only distro I looked at that does this, everybody
else (at least debian, ubuntu, OpenSUSE) is stuck at an ancient
version, if gradle is available at all.


Honestly? Good. Those LInux distros, including Fedora, need taken down a 
few pegs. 3rd party software developers cannot nor will they always bend 
a knee to extreme constraints that are not otherwise required to build 
on any other platform or run properly on supported platforms. Linux 
distros need to learn to play nice with other people.






FWIW, I can compile 6.4 just fine on Arch Linux using the Github source
code via:


./gradlew allZip

Now try doing that offline and without using the pre-built
gradle/wrapper/gradle-wrapper.jar :)
You'll be surprised how much junk the build process still needs to download.


Not a shocker. Gradle breaks backwards compatibility all the time, 
forcing projects to always use the wrapper. If using pre-builts isn't 
allowed Gradle will never be buildable, at least not consistently.




Fabio


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

___
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: Re-Launching the Java SIG

[Felix Schwarz]

Am 12.05.20 um 12:32 schrieb Ty Young:
> Right, I figured it was some Fedora policy and not up to you. I suppose I
> should have been more clear there. Sorry for any confusion, it was aimed at
> the Fedora project as a whole as this is a Fedora issue.

This is not a Fedora issue but a consequence of Fedora's core values. You not
agree with it but "building from source" is so fundamental that it does not
make sense to even start a discussion about it on fedora-devel.

I suggest you read up on the rationale behind that policy (which is why I
linked the policy document in the first place).

I understand that missing components/features due to the source requirement
are annoying but Fedora (and other distros) decided to take the "high road"
here and actually fix stuff instead of shipping whatever upstream came up with.

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: Re-Launching the Java SIG

[Vitaly Zaitsev via devel]

On 12.05.2020 10:35, Ty Young wrote:
> JUST PACKAGE THE PRE-COMPILED BUILDS!!!

No. Please read Fedora packaging guidelines. All packages **must** be
built from sources.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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: Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 12:34 PM Ty Young  wrote:
> Right, I figured it was some Fedora policy and not up to you. I suppose
> I should have been more clear there. Sorry for any confusion, it was
> aimed at the Fedora project as a whole as this is a Fedora issue.

I am aware that Arch is just packaging up the binary release artifacts
published by the gradle project.
But that's just never going to fly for fedora.

Arch is also the only distro I looked at that does this, everybody
else (at least debian, ubuntu, OpenSUSE) is stuck at an ancient
version, if gradle is available at all.

> FWIW, I can compile 6.4 just fine on Arch Linux using the Github source
> code via:
>
>
> ./gradlew allZip

Now try doing that offline and without using the pre-built
gradle/wrapper/gradle-wrapper.jar :)
You'll be surprised how much junk the build process still needs to download.

Fabio

> >
> > 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
___
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: Re-Launching the Java SIG

[Ty Young]

On 5/12/20 3:48 AM, Felix Schwarz wrote:

Am 12.05.20 um 10:35 schrieb Ty Young:

JUST PACKAGE THE PRE-COMPILED BUILDS!!!

Don't take me as rude but this is not possible.

This is documented in Fedora's packaging policies:
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries



Right, I figured it was some Fedora policy and not up to you. I suppose 
I should have been more clear there. Sorry for any confusion, it was 
aimed at the Fedora project as a whole as this is a Fedora issue.



FWIW, I can compile 6.4 just fine on Arch Linux using the Github source 
code via:



./gradlew allZip





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: Re-Launching the Java SIG

[Ankur Sinha]

On Tue, May 12, 2020 03:35:55 -0500, Ty Young wrote:
> 
> On 5/12/20 2:50 AM, Fabio Valentini wrote:
> > > What about packaging gradle instead? (In the cases I looked into,
> > > porting from gradle to maven would be rewriting the build system from
> > > scratch. Assuming that we have tens and will have hundreds of packages
> > > with gradle, in the long term it seems better to support gradle, even
> > > in some partial form, than to rewrite build systems of hundreds of
> > > packages...).
> > Uh. We tried. Multiple times. It just won't work, like, ever again. I
> > wrote a longer response here:
> > https://discussion.fedoraproject.org/t/re-launching-the-java-sig/19688/3
> > So, you are welcome to try, but I bet you'll end up in the long line
> > of packagers who failed to make it work.
> 
> 
> JUST PACKAGE THE PRE-COMPILED BUILDS!!!

Ty, please stop.

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


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: Re-Launching the Java SIG

[Felix Schwarz]

Hey Fabio,

thank you very much for your work.

I can't take on more Fedora work but still wanted to express my gratitude :-)

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: Re-Launching the Java SIG

[Felix Schwarz]

Am 12.05.20 um 10:35 schrieb Ty Young:
> JUST PACKAGE THE PRE-COMPILED BUILDS!!!

Don't take me as rude but this is not possible.

This is documented in Fedora's packaging policies:
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

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: Re-Launching the Java SIG

[Ty Young]

On 5/12/20 2:50 AM, Fabio Valentini wrote:

What about packaging gradle instead? (In the cases I looked into,
porting from gradle to maven would be rewriting the build system from
scratch. Assuming that we have tens and will have hundreds of packages
with gradle, in the long term it seems better to support gradle, even
in some partial form, than to rewrite build systems of hundreds of
packages...).

Uh. We tried. Multiple times. It just won't work, like, ever again. I
wrote a longer response here:
https://discussion.fedoraproject.org/t/re-launching-the-java-sig/19688/3
So, you are welcome to try, but I bet you'll end up in the long line
of packagers who failed to make it work.



JUST PACKAGE THE PRE-COMPILED BUILDS!!!



__
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: Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 10:15 AM Ankur Sinha  wrote:
>
> On Tue, May 12, 2020 09:50:30 +0200, Fabio Valentini wrote:
> > >
> > > Yep, count me in.
> >
> > Thanks. I'll get your memberships set up. :)
>
> Thank you for starting this off, and thank you for taking care of the
> Java packages in the meantime too. We really appreciate it. Please count
> me in also. :)

Good morning!

I suspected that you would be interested as well :)
You'll see your new group memberships shortly (possibly log out and
back in with src.fedoraproject.org).

Fabio

> --
> 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
___
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: Re-Launching the Java SIG

[Ankur Sinha]

On Tue, May 12, 2020 09:50:30 +0200, Fabio Valentini wrote:
> >
> > Yep, count me in.
> 
> Thanks. I'll get your memberships set up. :)

Thank you for starting this off, and thank you for taking care of the
Java packages in the meantime too. We really appreciate it. Please count
me in also. :)


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


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: Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 9:33 AM Zbigniew Jędrzejewski-Szmek
 wrote:
> The wiki is not that bad actually. The links to guidelines and package
> lists are still useful. Even the packaging wishlist is mostly up to
> date since we didn't manage to touch most of the items ;)
> So maybe just nuke the outdated parts (member lists, "state of affairs"
> content), and keep the rest?

Fair point. I'll make sure we keep the parts that are still up-to-date
and/or interesting.

> > Major upcoming projects for the "new" Java Package Maintainers group 
> > include:
> >
> > - managing OpenJDK 11 / Java 11 transition for hundreds of Java
> > packages in fedora 33
> > - starting to transition well-maintained Java packages from the
> > Stewardship SIG back into Java SIG
> > - possibly porting packages from gradle to maven to fix build issues
> > and broken dependencies
>
> What about packaging gradle instead? (In the cases I looked into,
> porting from gradle to maven would be rewriting the build system from
> scratch. Assuming that we have tens and will have hundreds of packages
> with gradle, in the long term it seems better to support gradle, even
> in some partial form, than to rewrite build systems of hundreds of
> packages...).

Uh. We tried. Multiple times. It just won't work, like, ever again. I
wrote a longer response here:
https://discussion.fedoraproject.org/t/re-launching-the-java-sig/19688/3
So, you are welcome to try, but I bet you'll end up in the long line
of packagers who failed to make it work.

> > - transitioning from old java.net / JavaEE projects to the new ones
> > now under the eclipse-ee4j umbrella
> >
> > I know that - among others - the PKI team, Neuro SIG, and Eclipse
> > maintainers depend on parts of the java stack for their packages, so I
> > hope that we can work together with them on these things, as well.
> >
> > So, if you're interested, please consider joining this group effort.
> > I'll get new members set up with the FAS group / pagure project / mailing 
> > list.
>
> Yep, count me in.

Thanks. I'll get your memberships set up. :)

Fabio

> Zbyszek
> ___
> 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: Re-Launching the Java SIG

[Zbigniew Jędrzejewski-Szmek]

On Mon, May 11, 2020 at 09:45:15PM +0200, Fabio Valentini wrote:
> This past weekend I finally decided to jump off the cliff and attempt
> to re-launch the Java SIG. It seems there's some interest in keeping
> the Java stack maintained, it's just not focused or organized right
> now.
> 
> What we did when starting the Stewardship SIG seems to have worked out
> pretty well, so I'm trying to follow in those footsteps here:
> 
> - new proper FAS / pkgdb group: java-maint-sig ("java-sig" is occupied
> by an old, unused bot account)
> - new private mailing list: java-maint-sig (for RHBZ bugs - so,
> possibly, also CVEs - hence, private)
> - tracking project on pagure: https://pagure.io/java-maint-sig (for
> maintenance scripts, tracking tickets, awesome package dashboards,
> etc.)
> 
> There's already a public fedora mailing list for Java (java-devel),
> and and IRC channel (#fedora-java on freenode.net), which we will
> continue to use. Sadly, the existing wiki page for the Java SIG is
> hopelessly outdated, so I'm tempted to just scrap it and point readers
> to the pagure tracking project once it's set up beyond a basic README
> file.

The wiki is not that bad actually. The links to guidelines and package
lists are still useful. Even the packaging wishlist is mostly up to
date since we didn't manage to touch most of the items ;)
So maybe just nuke the outdated parts (member lists, "state of affairs"
content), and keep the rest?

> Major upcoming projects for the "new" Java Package Maintainers group include:
> 
> - managing OpenJDK 11 / Java 11 transition for hundreds of Java
> packages in fedora 33
> - starting to transition well-maintained Java packages from the
> Stewardship SIG back into Java SIG
> - possibly porting packages from gradle to maven to fix build issues
> and broken dependencies

What about packaging gradle instead? (In the cases I looked into,
porting from gradle to maven would be rewriting the build system from
scratch. Assuming that we have tens and will have hundreds of packages
with gradle, in the long term it seems better to support gradle, even
in some partial form, than to rewrite build systems of hundreds of
packages...).

> - transitioning from old java.net / JavaEE projects to the new ones
> now under the eclipse-ee4j umbrella
> 
> I know that - among others - the PKI team, Neuro SIG, and Eclipse
> maintainers depend on parts of the java stack for their packages, so I
> hope that we can work together with them on these things, as well.
> 
> So, if you're interested, please consider joining this group effort.
> I'll get new members set up with the FAS group / pagure project / mailing 
> list.

Yep, count me in.

Zbyszek
___
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