Hi everybody,
Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer.
New versions and even security issues have been piling up for months (just look at the SIG's taiga board). Other people tried to step up for the "new" Java SIG (@java-maint-sig), but other than myself, nobody has been triaging new bugs in Java packages. Java package maintainers from Red Hat have been exceptionally unhelpful, and have not substantially contributed to Java packages in Fedora in years. Even the Modules that were heralded as "the solution" have stagnated. On the other hand, Mat Booth and two members of the DogTag PKI team have been really helpful, but Mat is busy fighting the Eclipse dumpster fire most of the time, and the other two have since both left Red Hat for greener pastures. And since I see no way for the situation to improve, there's only one honest thing left that I can do:
I will orphan all Java packages I am the main admin of, later today.
Since this is the majority of remaining Java software in Fedora (~180 packages), I expect at a decent amount of dependent packages will be affected. However, given the utter lack of Java package maintainers and the pitiful state of the overall language ecosystem, I would strongly urge affected maintainers to drop dependencies on Java, if at all possible.
Maybe other members of the java-maint-sig will pick up the orphaned packages, if they're still here. Or maybe it's finally time to let Java packages die. Nobody seems to care either way.
Fabio
On Mon, 26 Apr 2021 at 15:20, Fabio Valentini decathorpe@gmail.com wrote:
Hi everybody,
Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer.
Thank you for your hard efforts these last couple of years. I know what it is like to feel guilty for not being able to keep up the load but it is an impossible task to do for any length of time. In the 15 years we have tried to integrate Java into Fedora, it has been clear that this language does not meld well with our way of doing things.
Thank you also for having a detailed plan for handling this. I think it shows to others that it is ok to let things go when it is no longer fun or fulfilling.
New versions and even security issues have been piling up for months (just look at the SIG's taiga board). Other people tried to step up for the "new" Java SIG (@java-maint-sig), but other than myself, nobody has been triaging new bugs in Java packages. Java package maintainers from Red Hat have been exceptionally unhelpful, and have not substantially contributed to Java packages in Fedora in years. Even the Modules that were heralded as "the solution" have stagnated. On the other hand, Mat Booth and two members of the DogTag PKI team have been really helpful, but Mat is busy fighting the Eclipse dumpster fire most of the time, and the other two have since both left Red Hat for greener pastures. And since I see no way for the situation to improve, there's only one honest thing left that I can do:
I will orphan all Java packages I am the main admin of, later today.
Since this is the majority of remaining Java software in Fedora (~180 packages), I expect at a decent amount of dependent packages will be affected. However, given the utter lack of Java package maintainers and the pitiful state of the overall language ecosystem, I would strongly urge affected maintainers to drop dependencies on Java, if at all possible.
Maybe other members of the java-maint-sig will pick up the orphaned packages, if they're still here. Or maybe it's finally time to let Java packages die. Nobody seems to care either way.
Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Mon, Apr 26, 2021 at 3:26 PM Fabio Valentini decathorpe@gmail.com wrote:
Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer.
(snip)
I will orphan all Java packages I am the main admin of, later today.
Never feel guilty for not being able to volunteer as much as you'd like. We appreciate the time you give the project. Thank you for all of the effort you've put into the Java ecosystem in Fedora. I hope this gives you a little space to relax.
On Mon, Apr 26, 2021 at 09:19:44PM +0200, Fabio Valentini wrote:
Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer.
Oh wow. Thanks for all of your efforts around this -- but you are absolutely right if you're not having fun doing it. You absolutely shouldn't feel guilty -- find something fun to spend your time on!
On Mon, Apr 26, 2021 at 10:26 PM Fabio Valentini decathorpe@gmail.com wrote:
Hi everybody,
Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer.
New versions and even security issues have been piling up for months (just look at the SIG's taiga board). Other people tried to step up for the "new" Java SIG (@java-maint-sig), but other than myself, nobody has been triaging new bugs in Java packages. Java package maintainers from Red Hat have been exceptionally unhelpful, and have not substantially contributed to Java packages in Fedora in years. Even the Modules that were heralded as "the solution" have stagnated. On the other hand, Mat Booth and two members of the DogTag PKI team have been really helpful, but Mat is busy fighting the Eclipse dumpster fire most of the time, and the other two have since both left Red Hat for greener pastures. And since I see no way for the situation to improve, there's only one honest thing left that I can do:
I will orphan all Java packages I am the main admin of, later today.
Since this is the majority of remaining Java software in Fedora (~180 packages), I expect at a decent amount of dependent packages will be affected. However, given the utter lack of Java package maintainers and the pitiful state of the overall language ecosystem, I would strongly urge affected maintainers to drop dependencies on Java, if at all possible.
Maybe other members of the java-maint-sig will pick up the orphaned packages, if they're still here. Or maybe it's finally time to let Java packages die. Nobody seems to care either way.
Thanks for keeping up the Java ecosystem in Fedora in the last few years! This is a task that has burned out many people I know (including me) so I felt your pain.
Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Mon, 2021-04-26 at 21:19 +0200, Fabio Valentini wrote:
Hi everybody,
Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer.
New versions and even security issues have been piling up for months (just look at the SIG's taiga board). Other people tried to step up for the "new" Java SIG (@java-maint-sig), but other than myself, nobody has been triaging new bugs in Java packages. Java package maintainers from Red Hat have been exceptionally unhelpful, and have not substantially contributed to Java packages in Fedora in years. Even the Modules that were heralded as "the solution" have stagnated. On the other hand, Mat Booth and two members of the DogTag PKI team have been really helpful, but Mat is busy fighting the Eclipse dumpster fire most of the time, and the other two have since both left Red Hat for greener pastures. And since I see no way for the situation to improve, there's only one honest thing left that I can do:
I will orphan all Java packages I am the main admin of, later today.
Since this is the majority of remaining Java software in Fedora (~180 packages), I expect at a decent amount of dependent packages will be affected. However, given the utter lack of Java package maintainers and the pitiful state of the overall language ecosystem, I would strongly urge affected maintainers to drop dependencies on Java, if at all possible.
Maybe other members of the java-maint-sig will pick up the orphaned packages, if they're still here. Or maybe it's finally time to let Java packages die. Nobody seems to care either way.
you did an amazing work , thank you .
On Mon, Apr 26, 2021 21:19:44 +0200, Fabio Valentini wrote:
Hi everybody,
Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer.
Thank you so much for the work you put into these packages, and I'm really sorry I couldn't be more help.
After struggling with our Java packages for quite a bit, the neuro-sig reached a similar conclusion---that they're just too much work or just pretty much impossible to keep in Fedora. We've now accepted that documenting Java tools and asking users to install them directly from upstream is the most we can manage.
On Mon, Apr 26, 2021 at 9:26 PM Fabio Valentini decathorpe@gmail.com wrote:
I will orphan all Java packages I am the main admin of, later today.
I've adopted the majority of Java packages that were orphaned by Fabio, primarily those that are related to Maven or Ant.
I've been maintaining numerous Java packages in Fedora for more than 9 years. As modularity was developed, I saw it as an opportunity to make my life as a package maintainer easier. Initially I tried to make Maven and Ant available as default streams and in the buildroot so they could be available and consumed by non-modular packages. In the end that did not and I completely respect the decisions of FESCo to disallow default streams to then to disallow modules except for alternative versions. That means I'll be maintaining Maven and Ant with their runtime and build dependencies as non-modular packages.
My plans for the upcoming months regarding adopted packages include:
1) triaging all open bugs and reviewing all open pull requests,
2) closing the gap between Fedora and CentOS, by merging dist-git contents of appropriate components in Fedora Rawhide and CentOS Stream 9,
3) unretiring some of Maven and Ant dependencies,
4) improving testing automation, especially implementing package-specific tests for use in gating,
5) automating the process of bootstrapping Maven and Ant with related components, so that new versions can be imported and built reproducibly and with consistent quality.
6) restoring Maven compatibility with OpenJDK 8, so that users who are stuck with older JDKs have an ability to keep using their build tools with JDK of their preference.
-- Mikolaj Izdebski
Hi Mikolaj,
Mikolaj Izdebski mizdebsk@redhat.com writes:
- automating the process of bootstrapping Maven and Ant with related components, so that new versions can be imported and built reproducibly and with consistent quality.
You might want to take a look at openSUSE's maven package: https://build.opensuse.org/package/show/Java:packages/maven
It builds itself using ant and not using maven. You'll probably recognize a good chunk of the spec, because it originally came from Fedora (I'm also pretty certain that Fridrich, the package maintainer, would not object to a cross distribution collaboration).
Cheers,
Dan
On Tue, Apr 27, 2021 at 5:18 PM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Hi Mikolaj,
Mikolaj Izdebski mizdebsk@redhat.com writes:
- automating the process of bootstrapping Maven and Ant with related components, so that new versions can be imported and built reproducibly and with consistent quality.
You might want to take a look at openSUSE's maven package: https://build.opensuse.org/package/show/Java:packages/maven
It builds itself using ant and not using maven. You'll probably recognize a good chunk of the spec, because it originally came from Fedora (I'm also pretty certain that Fridrich, the package maintainer, would not object to a cross distribution collaboration).
Thanks for the suggestion, but IMO Maven in Fedora should be built the same way as upstream builds it, that is with Maven. That minimizes the possibility of deviating from upstream and introducing unnoticed bugs. Instead a custom project was created that is used to build from scratch a minimal environment that contains Maven and that can be used to build Maven package. Then Maven can be used to rebuild itself as many times as needed.
-- Mikolaj Izdebski
Cheers,
Dan
Mikolaj Izdebski wrote:
Thanks for the suggestion, but IMO Maven in Fedora should be built the same way as upstream builds it, that is with Maven. That minimizes the possibility of deviating from upstream and introducing unnoticed bugs. Instead a custom project was created that is used to build from scratch a minimal environment that contains Maven and that can be used to build Maven package. Then Maven can be used to rebuild itself as many times as needed.
Well, the thing is, this sort of circular build dependency may be very attractive to build tool upstreams, because this "dogfooding" provides a way to continuously test the build tool "for free", but for us distributors, it just makes things a pain.
That said, if the OpenSUSE approach means to have to maintain a downstream ant build.xml in parallel to the upstream Maven one, this means extra work that may be actually more effort than the bootstrapping.
I really wish compiler developers would stop writing (almost) every compiler in its own programming language, build systems would stop using themselves to build, etc. Sadly, it is not going to happen.
Kevin Kofler
On 27. 04. 21 16:49, Mikolaj Izdebski wrote:
On Mon, Apr 26, 2021 at 9:26 PM Fabio Valentini decathorpe@gmail.com wrote:
I will orphan all Java packages I am the main admin of, later today.
I've adopted the majority of Java packages that were orphaned by Fabio, primarily those that are related to Maven or Ant.
I've been maintaining numerous Java packages in Fedora for more than 9 years. As modularity was developed, I saw it as an opportunity to make my life as a package maintainer easier. Initially I tried to make Maven and Ant available as default streams and in the buildroot so they could be available and consumed by non-modular packages. In the end that did not and I completely respect the decisions of FESCo to disallow default streams to then to disallow modules except for alternative versions. That means I'll be maintaining Maven and Ant with their runtime and build dependencies as non-modular packages.
...snip...
Thank You!
Hi Mikolaj,
On 4/27/21 4:49 PM, Mikolaj Izdebski wrote:
On Mon, Apr 26, 2021 at 9:26 PM Fabio Valentini decathorpe@gmail.com wrote:
I will orphan all Java packages I am the main admin of, later today.
I've adopted the majority of Java packages that were orphaned by Fabio, primarily those that are related to Maven or Ant.
I've been maintaining numerous Java packages in Fedora for more than 9 years. As modularity was developed, I saw it as an opportunity to make my life as a package maintainer easier. Initially I tried to make Maven and Ant available as default streams and in the buildroot so they could be available and consumed by non-modular packages. In the end that did not and I completely respect the decisions of FESCo to disallow default streams to then to disallow modules except for alternative versions. That means I'll be maintaining Maven and Ant with their runtime and build dependencies as non-modular packages.
My plans for the upcoming months regarding adopted packages include:
triaging all open bugs and reviewing all open pull requests,
closing the gap between Fedora and CentOS, by merging dist-git contents of appropriate components in Fedora Rawhide and CentOS Stream 9,
unretiring some of Maven and Ant dependencies,
improving testing automation, especially implementing package-specific tests for use in gating,
automating the process of bootstrapping Maven and Ant with related components, so that new versions can be imported and built reproducibly and with consistent quality.
restoring Maven compatibility with OpenJDK 8, so that users who are stuck with older JDKs have an ability to keep using their build tools with JDK of their preference.
Thank you for doing this!
Also I hope it is ok if I pick your brain a bit on a java packaging issue which I've been having.
I maintain a couple of java leave packages (games) + some deps which AFAIK are only used by these games.
One of these deps (dom4j) has been FTBFS since F34: https://bugzilla.redhat.com/show_bug.cgi?id=1923601
I've been looking into this and the actual problem seems to be with Java 9 now including what once was the org.relaxng.datatype except they did not just bundle it, they also changed where it sits in the namespace to com.sun.tools.rngdatatype <sigh>
Just doing a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ got me a bit further, but it seems that msv, which is a dep of dom4j needs to be rebuild first with the same search-replace done on it and the FTBFS bug of msv is stuck because of one of its deps getting orphaned+retired : https://bugzilla.redhat.com/show_bug.cgi?id=1923446
So I think I can fix this by:
1. Unorphaning jvnet-parent, which is the missing msv dep 2. Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in msv, rebuild 3. Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in dom4j, rebuild
And then either do this only for rawhide, or push all 3 modified packages to F34 in a single bodhi update.
Mikolaj, does this sounds like a reasonable plan to you; or should I approach this differently?
Also if yes this is a reasonable plan any advice on also pushing the fixed packages to F34, or not ?
Regards,
Hans
Hi Hans,
On Wed, Apr 28, 2021 at 3:47 PM Hans de Goede hdegoede@redhat.com wrote:
Also I hope it is ok if I pick your brain a bit on a java packaging issue which I've been having.
I maintain a couple of java leave packages (games) + some deps which AFAIK are only used by these games.
One of these deps (dom4j) has been FTBFS since F34: https://bugzilla.redhat.com/show_bug.cgi?id=1923601
I've been looking into this and the actual problem seems to be with Java 9 now including what once was the org.relaxng.datatype except they did not just bundle it, they also changed where it sits in the namespace to com.sun.tools.rngdatatype <sigh>
Just doing a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ got me a bit further, but it seems that msv, which is a dep of dom4j needs to be rebuild first with the same search-replace done on it and the FTBFS bug of msv is stuck because of one of its deps getting orphaned+retired : https://bugzilla.redhat.com/show_bug.cgi?id=1923446
So I think I can fix this by:
- Unorphaning jvnet-parent, which is the missing msv dep
You can unorphan/unretire it, but removing dependency on jvnet-parent is another choice. Probably better choice as jvnet-parent is no longer developed or maintained by upstream.
- Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in msv, rebuild
- Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in dom4j, rebuild
relaxngDatatype was retired in Fedora. A replacement is jaxb-relaxng-datatype package (built from jaxb source package), but it uses a different namespace. Therefore steps 2 and 3 seem correct and necessary.
And then either do this only for rawhide, or push all 3 modified packages to F34 in a single bodhi update.
Mikolaj, does this sounds like a reasonable plan to you; or should I approach this differently?
Yes, that sounds good. I would also double check to see whether msv/dom4j are really needed by your packages.
Also if yes this is a reasonable plan any advice on also pushing the fixed packages to F34, or not ?
I am in favor of F34 update. Users of dom4j/msv that do not rely on relaxngDatatype-related functionality should be unaffected by the update. Users that do rely on it would get it fixed.
Regards,
Hans
Hi,
On 4/29/21 12:00 PM, Mikolaj Izdebski wrote:
Hi Hans,
On Wed, Apr 28, 2021 at 3:47 PM Hans de Goede hdegoede@redhat.com wrote:
Also I hope it is ok if I pick your brain a bit on a java packaging issue which I've been having.
I maintain a couple of java leave packages (games) + some deps which AFAIK are only used by these games.
One of these deps (dom4j) has been FTBFS since F34: https://bugzilla.redhat.com/show_bug.cgi?id=1923601
I've been looking into this and the actual problem seems to be with Java 9 now including what once was the org.relaxng.datatype except they did not just bundle it, they also changed where it sits in the namespace to com.sun.tools.rngdatatype <sigh>
Just doing a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ got me a bit further, but it seems that msv, which is a dep of dom4j needs to be rebuild first with the same search-replace done on it and the FTBFS bug of msv is stuck because of one of its deps getting orphaned+retired : https://bugzilla.redhat.com/show_bug.cgi?id=1923446
So I think I can fix this by:
- Unorphaning jvnet-parent, which is the missing msv dep
You can unorphan/unretire it, but removing dependency on jvnet-parent is another choice. Probably better choice as jvnet-parent is no longer developed or maintained by upstream.
- Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in msv, rebuild
- Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in dom4j, rebuild
relaxngDatatype was retired in Fedora. A replacement is jaxb-relaxng-datatype package (built from jaxb source package), but it uses a different namespace. Therefore steps 2 and 3 seem correct and necessary.
And then either do this only for rawhide, or push all 3 modified packages to F34 in a single bodhi update.
Mikolaj, does this sounds like a reasonable plan to you; or should I approach this differently?
Yes, that sounds good. I would also double check to see whether msv/dom4j are really needed by your packages.
Thank you for this hint. dom4j is still used by 4 packages, but "dnf repoquery --whatrequires msv-<subpkg>" returns nothing but msv for all msv packages. So it seems that nothing is using this at runtime. As such I've just removed the classes from dom4j which depend on msv as those seem to be unused.
I've only pushed this to rawhide for now and I've asked the maintainers of the other 3 packages to test them with the new dom4j build.
I'll also add a comment to the msv FTBFS bug that it might be best to just orphan msv as it has been deprecated upstream and not seen a new release since 2013 it seems.
Also if yes this is a reasonable plan any advice on also pushing the fixed packages to F34, or not ?
I am in favor of F34 update. Users of dom4j/msv that do not rely on relaxngDatatype-related functionality should be unaffected by the update. Users that do rely on it would get it fixed.
Ok, I'll update dom4j once I've positive testing feedback from the maintainers of the other pkgs depending on it.
Regards,
Hans
On Mon, Apr 26, 2021 at 1:20 PM Fabio Valentini decathorpe@gmail.com wrote:
Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer.
As I recall, you made it clear when you started that your involvement with Java packaging was going to be temporary. Thank you for all the work you did. It really did benefit a lot of people. Regards,
On Mon, 26 Apr 2021 at 20:20, Fabio Valentini decathorpe@gmail.com wrote:
Hi everybody,
Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer.
New versions and even security issues have been piling up for months (just look at the SIG's taiga board). Other people tried to step up for the "new" Java SIG (@java-maint-sig), but other than myself, nobody has been triaging new bugs in Java packages. Java package maintainers from Red Hat have been exceptionally unhelpful, and have not substantially contributed to Java packages in Fedora in years. Even the Modules that were heralded as "the solution" have stagnated. On the other hand, Mat Booth and two members of the DogTag PKI team have been really helpful, but Mat is busy fighting the Eclipse dumpster fire most of the time, and the other two have since both left Red Hat for greener pastures. And since I see no way for the situation to improve, there's only one honest thing left that I can do:
I will orphan all Java packages I am the main admin of, later today.
Since this is the majority of remaining Java software in Fedora (~180 packages), I expect at a decent amount of dependent packages will be affected. However, given the utter lack of Java package maintainers and the pitiful state of the overall language ecosystem, I would strongly urge affected maintainers to drop dependencies on Java, if at all possible.
Maybe other members of the java-maint-sig will pick up the orphaned packages, if they're still here. Or maybe it's finally time to let Java packages die. Nobody seems to care either way.
Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
I want to echo everyone else's sentiments and give my thanks for being the one to step into Java packaging when you did. I wish I had more time to donate and honestly I thought modularity would help with that too, but it turned out to be a fools' errand and sapped way too much of my time and motivation.
I'm sorry I couldn't help out more, and wish you well in your other endeavours.
-- Mat Booth http://fedoraproject.org/get-fedora
Hi Fabio,
On 4/26/21 9:19 PM, Fabio Valentini wrote:
Hi everybody,
Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer.
New versions and even security issues have been piling up for months (just look at the SIG's taiga board). Other people tried to step up for the "new" Java SIG (@java-maint-sig), but other than myself, nobody has been triaging new bugs in Java packages. Java package maintainers from Red Hat have been exceptionally unhelpful, and have not substantially contributed to Java packages in Fedora in years. Even the Modules that were heralded as "the solution" have stagnated. On the other hand, Mat Booth and two members of the DogTag PKI team have been really helpful, but Mat is busy fighting the Eclipse dumpster fire most of the time, and the other two have since both left Red Hat for greener pastures. And since I see no way for the situation to improve, there's only one honest thing left that I can do:
I will orphan all Java packages I am the main admin of, later today.
As many others have already said thank you for all the time which you've put in this over the years; and please do not feel guilty about dropping these.
Regards,
Hans
On 4/26/21 10:19 PM, Fabio Valentini wrote:
Hi everybody,
Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer.
Thank you for the past work, you've done huge effort to keep java packages in Fedora.
Best wishes, Markku
Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Hello Fabio, I was one of those community members to step up, or at least attempt to. What I found was an obstacle course instead of welcome to the packagers. I feel the frustration you are expressing, and would like to help, nut apparently I don't meet the Fedora Packaging standards. Even tried the review route, which is also beset with arbitrary obstacles. I will keep trying because that is in my nature, but making joining the packaging group(s) a bit more open would go a long way to garnering more packagers IMO.
On 11/08/2021 13:37, Stephen Snow wrote:
making joining the packaging group(s) a bit more open would go a long way to garnering more packagers IMO
New contributors must know at least the Fedora packaging guidelines. This is the minimum barrier.
If someone doesn't want to read and follow the instructions, they can use COPR. Simple and easy.
Okay, So to become a packager you have to - Get someone to sponsor you as a packager - Review existing packages for others - take over an orphaned package - introduce a package to Fedora Linux that needs to get approval to be packaged - some other criteria I forgot after reading so many linked documents ....
I tried to "take" an orphaned package ... can't not a packager, so I tried to do a review, and even though I appear to be part of the group, I couldn't even access the review build because apparently I don't have the rights.
My point is yes, it is requiring effort and it should but not to the extent of stonewalling contributions, and largely because the guidelines are confusing, it is a bit like reading a hand drawn map while driving IMO.
So, back to orphaned packages, if a person from the community is signed up, signed the CA, the CoC, is a member of the appropriate groups, that person should be able to volunteer to take on orphaned packages, at least on a trila basis till they need no handholding. The deesire to contribute should be the bar to contribute is my point. If technical requirements are not being met, then they would be removed as packager and basically timed out for a specific time till they get the opportunity to try packaging again. However, if they succeed, then great for all, more contributors, less workload across the board. I understand that RPM packaging is a complex process, and creating Fedora Linux is a large task, but for new contributors how are they to learn the process, if the gate keepers are too efficient?
Regards, and still hoping to be a packager .... someday....
Stephen
On Wed, 2021-08-11 at 14:16 +0200, Vitaly Zaitsev via devel wrote:
On 11/08/2021 13:37, Stephen Snow wrote:
making joining the packaging group(s) a bit more open would go a long way to garnering more packagers IMO
New contributors must know at least the Fedora packaging guidelines. This is the minimum barrier.
use COPR. Simple and easy.
-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 11/08/2021 17:55, Stephen Snow wrote:
- Get someone to sponsor you as a packager
- Review existing packages for others
Package sponsors should make sure new contributors are familiar with RPM packaging and Fedora guidelines.
introduce a package to Fedora Linux that needs to get approval to be packaged
If you are a member of the packagers group, you can simply press a "Take ownership" button.
If the package was orphaned more than 8 weeks ago, you must open a new releng ticket.
https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_pac...
On 11. 08. 21 19:51, Vitaly Zaitsev via devel wrote:
If the package was orphaned more than 8 weeks ago, you must open a new releng ticket.
https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_pac...
Correction: If the package was *retired* more than 8 weeks ago.
I think becoming a packager is not as complicated as you’ve written. To become a packager, you must convince a packager sponsor to sponsor you. That’s all; there is no rule about how to do the convincing.
Sponsors want to be confident that you understand and are likely to follow the packaging guidelines. Submitting PR’s, submitting new packages for review (to be imported after you are sponsored), and doing unofficial package reviews are three common and suggested ways to establish a track record, but a sponsor may choose to sponsor a new packager (or not!) for any reason whatsoever.
In my opinion, rescuing orphaned packages tends to be one of the harder packaging tasks. Many packages are orphaned for lack of time, so they often have lingering obsolete practices that ought to be brought into compliance with current guidelines. Many others are orphaned because they have problems the previous packager found too difficult, time-consuming, or frustrating to fix. Working on orphaned packages can be a good way to learn quickly and a great way to contribute, but I think new packagers are likely to need more mentoring for these packages, not less.
On 8/11/21 11:55 AM, Stephen Snow wrote:
Okay, So to become a packager you have to
- Get someone to sponsor you as a packager
- Review existing packages for others
- take over an orphaned package
- introduce a package to Fedora Linux that needs to get approval to
be packaged
- some other criteria I forgot after reading so many linked documents
....
I tried to "take" an orphaned package ... can't not a packager, so I tried to do a review, and even though I appear to be part of the group, I couldn't even access the review build because apparently I don't have the rights.
My point is yes, it is requiring effort and it should but not to the extent of stonewalling contributions, and largely because the guidelines are confusing, it is a bit like reading a hand drawn map while driving IMO.
So, back to orphaned packages, if a person from the community is signed up, signed the CA, the CoC, is a member of the appropriate groups, that person should be able to volunteer to take on orphaned packages, at least on a trila basis till they need no handholding. The deesire to contribute should be the bar to contribute is my point. If technical requirements are not being met, then they would be removed as packager and basically timed out for a specific time till they get the opportunity to try packaging again. However, if they succeed, then great for all, more contributors, less workload across the board. I understand that RPM packaging is a complex process, and creating Fedora Linux is a large task, but for new contributors how are they to learn the process, if the gate keepers are too efficient?
Regards, and still hoping to be a packager .... someday....
Stephen
On Wed, 2021-08-11 at 14:16 +0200, Vitaly Zaitsev via devel wrote:
On 11/08/2021 13:37, Stephen Snow wrote:
making joining the packaging group(s) a bit more open would go a long way to garnering more packagers IMO
New contributors must know at least the Fedora packaging guidelines. This is the minimum barrier.
use COPR. Simple and easy.
-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Jack Frost wrote:
I tried to "take" an orphaned package ... can't not a packager, so I tried to do a review, and even though I appear to be part of the group, I couldn't even access the review build because apparently I don't have the rights.
[I think this is a misunderstanding. There are no private builds in Fedora infra. Anyone (even without logging in) should be able to access any build. What was the build that you couldn't access?]
My point is yes, it is requiring effort and it should but not to the extent of stonewalling contributions, and largely because the guidelines are confusing, it is a bit like reading a hand drawn map while driving IMO.
Yeah, I think the sponsorship process, with unclear and unequal rules is one of the most antiquated parts of Fedora.
So, back to orphaned packages, if a person from the community is signed up, signed the CA, the CoC, is a member of the appropriate groups, that person should be able to volunteer to take on orphaned packages, at least on a trila basis till they need no handholding. The deesire to contribute should be the bar to contribute is my point.
On Wed, Aug 11, 2021 at 01:57:15PM -0400, Ben Beasley wrote:
In my opinion, rescuing orphaned packages tends to be one of the harder packaging tasks. Many packages are orphaned for lack of time, so they often have lingering obsolete practices that ought to be brought into compliance with current guidelines. Many others are orphaned because they have problems the previous packager found too difficult, time-consuming, or frustrating to fix. Working on orphaned packages can be a good way to learn quickly and a great way to contribute, but I think new packagers are likely to need more mentoring for these packages, not less.
I think there's some idea to rescue here. I agree that adopting orphaned packages can be harder than it seems, but OTOH, it's a task that has big benefits for the community. In the past, the recommended way to become a packager, and the way that had the easiest process, was to add a new package. This made a lot of sense when the distro was smaller and there were always new things that could be reasonably added. Nowadays, we either have most upstream projects packaged, or they are very big and complex to package, or have many dependencies, or legal issues, or there just isn't that much need to have them packaged. And all other things being equal, I it's better to have one package maintained continuously, than a package maintained for some time and then dropped, and another package maintained. While we may have a constant of 1 package maintained, the second case disappoints users.
tl;dr: I think we should change the guidelines [1] to explicitly recommend opening a pull request for an orphaned package as one of the ways. Maybe even describe it first. And describe the steps that need to be done in detail, so that it's easy to unexperienced folks to follow.
[1] https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#...
Zbyszek
On Sat, 2021-08-14 at 09:04 +0000, Zbigniew Jędrzejewski-Szmek wrote:
I think there's some idea to rescue here. I agree that adopting orphaned packages can be harder than it seems, but OTOH, it's a task that has big benefits for the community. In the past, the recommended way to become a packager, and the way that had the easiest process, was to add a new package. This made a lot of sense when the distro was smaller and there were always new things that could be reasonably added. Nowadays, we either have most upstream projects packaged, or they are very big and complex to package, or have many dependencies, or legal issues, or there just isn't that much need to have them packaged. And all other things being equal, I it's better to have one package maintained continuously, than a package maintained for some time and then dropped, and another package maintained. While we may have a constant of 1 package maintained, the second case disappoints users.
tl;dr: I think we should change the guidelines [1] to explicitly recommend opening a pull request for an orphaned package as one of the ways. Maybe even describe it first. And describe the steps that need to be done in detail, so that it's easy to unexperienced folks to follow.
I can feel the pain of Stephen, as I went through something like that some years ago, and was quite frustrating.
I was at that time main developer of a small project that was on every distro, and I was a Fedora user.
I went ahead to build the rpm for fedora and got some tips about how to improve the spec but I was never able to get an sponsor, and was told the spec was not fit for Fedora.
In the meantime another user grabbed the spec and sources from project's csv and submited it as his first package for review.
He got an sponsor right away and became the maintainer of the package, without changing a line of what I had in csv.
It was really frustrating ... to the point I've never submited another package for review.
A better - or more clear - way to become a package maintaner would help.
Some of us would like to help, but can't find a clear way to do it.
On Tue, Aug 17, 2021 18:47:37 +0200, Iago Rubio wrote:
On Sat, 2021-08-14 at 09:04 +0000, Zbigniew Jędrzejewski-Szmek wrote:
I think there's some idea to rescue here. I agree that adopting orphaned packages can be harder than it seems, but OTOH, it's a task that has big benefits for the community. In the past, the recommended way to become a packager, and the way that had the easiest process, was to add a new package. This made a lot of sense when the distro was smaller and there were always new things that could be reasonably added. Nowadays, we either have most upstream projects packaged, or they are very big and complex to package, or have many dependencies, or legal issues, or there just isn't that much need to have them packaged. And all other things being equal, I it's better to have one package maintained continuously, than a package maintained for some time and then dropped, and another package maintained. While we may have a constant of 1 package maintained, the second case disappoints users.
tl;dr: I think we should change the guidelines [1] to explicitly recommend opening a pull request for an orphaned package as one of the ways. Maybe even describe it first. And describe the steps that need to be done in detail, so that it's easy to unexperienced folks to follow.
I can feel the pain of Stephen, as I went through something like that some years ago, and was quite frustrating.
I was at that time main developer of a small project that was on every distro, and I was a Fedora user.
I went ahead to build the rpm for fedora and got some tips about how to improve the spec but I was never able to get an sponsor, and was told the spec was not fit for Fedora.
In the meantime another user grabbed the spec and sources from project's csv and submited it as his first package for review.
He got an sponsor right away and became the maintainer of the package, without changing a line of what I had in csv.
That's very odd. The guidelines remain the same for all of us. So a spec that didn't pass a review the first time should not pass the review again without changes.
It was really frustrating ... to the point I've never submited another package for review.
A better - or more clear - way to become a package maintaner would help.
Some of us would like to help, but can't find a clear way to do it.
I think we're always open to suggestions. So if you have any, please do share them with us.
Sponsorship to the packager group is based on trust---trust that the candidate knows the packaging pipeline and guidelines well enough. How individual sponsors come about trusting candidates is quite a personal thing I guess, but generally submitting good packages for review and showing the understanding of guidelines by doing reviews is quite sufficient.
That is not the only way, though. Co-maintaining, pull requests, personal relationships are all ways of earning community trust, as documented here: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
This was recently developed (last few weeks!) as a centralised place to look for sponsors: https://docs.pagure.org/fedora-sponsors/
I don't think it's been added to all the necessary docs yet, but it will soon.
On Tue, 2021-08-17 at 18:26 +0100, Ankur Sinha wrote:
He got an sponsor right away and became the maintainer of the package, without changing a line of what I had in csv.
That's very odd. The guidelines remain the same for all of us. So a spec that didn't pass a review the first time should not pass the review again without changes.
Just to clarify, the main issue was the application was an UI app in gtk with plugins.
The plugins was distributed as shared library files that were dlopened (in this case using g_lib's g_module_open) and loaded on the main application.
The guy reviewing my package, pointed to me the devel package I shiped for the plugins was useless. I tried to explain him what it was for, and told him to remove both plugins and devel files, but got no response.
Pretty much all gui packages back in time implemented plugins that way, and shiped the devel package exactly as I did.
The guy that later reviewed the other contributor's submission for review, did not saw that as an issue.
https://bugzilla.redhat.com/show_bug.cgi?id=174063 this is the review request.
I am not sure there was a guideline blocking the package.
On Tue, Aug 17, 2021 22:38:19 +0200, Iago Rubio wrote:
On Tue, 2021-08-17 at 18:26 +0100, Ankur Sinha wrote:
He got an sponsor right away and became the maintainer of the package, without changing a line of what I had in csv.
That's very odd. The guidelines remain the same for all of us. So a spec that didn't pass a review the first time should not pass the review again without changes.
Just to clarify, the main issue was the application was an UI app in gtk with plugins.
The plugins was distributed as shared library files that were dlopened (in this case using g_lib's g_module_open) and loaded on the main application.
The guy reviewing my package, pointed to me the devel package I shiped for the plugins was useless.
I tried to explain him what it was for, and told him to remove both plugins and devel files, but got no response.
Pretty much all gui packages back in time implemented plugins that way, and shiped the devel package exactly as I did.
The guy that later reviewed the other contributor's submission for review, did not saw that as an issue.
https://bugzilla.redhat.com/show_bug.cgi?id=174063 this is the review request.
I am not sure there was a guideline blocking the package.
This is from 2006/2007. That's more than a decade ago :)
A lot of things have changed since then. If you're interested in package maintainership, please give it another go and let us know how it goes.
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
I will stress again that it's about getting the community to trust that one understands the Fedora packaging pipeline and guidelines well enough. So the whole exercise should be undertaken with this in mind.
On Wed, 2021-08-18 at 09:48 +0100, Ankur Sinha wrote:
This is from 2006/2007. That's more than a decade ago :)
A lot of things have changed since then. If you're interested in package maintainership, please give it another go and let us know how it goes.
I will go for it Ankur. You are right is about time to give it another go.
On Wed, Aug 18, 2021 11:54:53 +0200, Iago Rubio wrote:
On Wed, 2021-08-18 at 09:48 +0100, Ankur Sinha wrote:
This is from 2006/2007. That's more than a decade ago :)
A lot of things have changed since then. If you're interested in package maintainership, please give it another go and let us know how it goes.
I will go for it Ankur. You are right is about time to give it another go.
Thanks. Please do let us know if you run into any issues. We encourage all prospective package maintainers to speak to the community here on the -devel list so that sponsors (and the community in general) can help them wherever needed.
Dne 17. 08. 21 v 22:38 Iago Rubio napsal(a):
On Tue, 2021-08-17 at 18:26 +0100, Ankur Sinha wrote:
He got an sponsor right away and became the maintainer of the package, without changing a line of what I had in csv.
That's very odd. The guidelines remain the same for all of us. So a spec that didn't pass a review the first time should not pass the review again without changes.
Just to clarify, the main issue was the application was an UI app in gtk with plugins.
The plugins was distributed as shared library files that were dlopened (in this case using g_lib's g_module_open) and loaded on the main application.
The guy reviewing my package, pointed to me the devel package I shiped for the plugins was useless. I tried to explain him what it was for, and told him to remove both plugins and devel files, but got no response.
Pretty much all gui packages back in time implemented plugins that way, and shiped the devel package exactly as I did.
The guy that later reviewed the other contributor's submission for review, did not saw that as an issue.
https://bugzilla.redhat.com/show_bug.cgi?id=174063 this is the review request.
I am not sure there was a guideline blocking the package.
Thanks for sharing your story. If I were in your shoes (and with my experience), I would call out such review on fedora-devel for second opinion. After all, it should not about preventing something to get into Fedora, but about the best technical solution and that needs sometimes some compromise. I believe there used to be "use your best judgement" somewhere in the guidelines, can't find it on any prominent place.
I understand that this might be hard for newcomers, but I am curious now if we actually encourage call for second opinion somewhere in the "Join" documentation.
Vít
* Stephen Snow [11/08/2021 11:37] :
I feel the frustration you are expressing, and would like to help, nut apparently I don't meet the Fedora Packaging standards.
I'm curious as to what happened...
Even tried the review route, which is also beset with arbitrary obstacles.
Again, what happened? Can you point us to those reviews?
I will keep trying because that is in my nature, but making joining the packaging group(s) a bit more open would go a long way to garnering more packagers IMO.
What changes to the process would you like to see made?
Emmanuel
On Wed, 2021-08-11 at 14:20 +0200, Emmanuel Seyman wrote:
- Stephen Snow [11/08/2021 11:37] :
I feel the frustration you are expressing, and would like to help, nut apparently I don't meet the Fedora Packaging standards.
I'm curious as to what happened...
Not sure what happened really, I had asked via this email list a few times over the past to become a package maintainer of a couple of orphaned java related packages, and got no response. I couldn't use the take button as it noted I didn't have the rights to do it (still that way on Pagure for me).
Even tried the review route, which is also beset with arbitrary obstacles.
Wasn't able to download the build via the link provided.
Again, what happened? Can you point us to those reviews?
I will keep trying because that is in my nature, but making joining the packaging group(s) a bit more open would go a long way to garnering more packagers IMO.
What changes to the process would you like to see made?
Please see my repsonse to Vitaly. I think the barrier to getting into this should be far lower as regarding the following ... -New contributor asks for sponsorship, someone able to gives it -new contributor is now a packager and can "take" any orphaned package -new contributor fails as packager after one release cycle, times out for one more release cycle before allowed to try to contribute again. -or new contributor does well, with handholding, and continues the learning process - or they do great, and need no handholding, and take on more work load readily
I really would like to point to how easy it is to become an editor of Fedora Magazine as an example of the ease with which contributors should be onboarded.
As one more note from me on this, the packaging guidelines are an evolved document from years of best practices and failures. Maybe it is time to rethink the guidelines and particularly the entrance criteria to reflect today's Fedora Linux.
Regards, Stephen
Emmanuel _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
* Stephen Snow [11/08/2021 12:08] :
Even tried the review route, which is also beset with arbitrary obstacles.
Wasn't able to download the build via the link provided.
??? Building a package with mock will create the build in /var/lib/mock/... No download should be required.
Emmanuel
On Wed, 2021-08-11 at 18:44 +0200, Emmanuel Seyman wrote:
- Stephen Snow [11/08/2021 12:08] :
Even tried the review route, which is also beset with arbitrary obstacles.
Wasn't able to download the build via the link provided.
??? Building a package with mock will create the build in /var/lib/mock/... No download should be required.
Yup, my mistake, I was able to build. I'll try the process again by looking through the review's wanted list.
Thanks for responding
Stephen
Emmanuel _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Wed, 2021-08-11 at 13:26 -0400, Stephen Snow wrote:
On Wed, 2021-08-11 at 18:44 +0200, Emmanuel Seyman wrote:
- Stephen Snow [11/08/2021 12:08] :
Even tried the review route, which is also beset with arbitrary obstacles.
Wasn't able to download the build via the link provided.
??? Building a package with mock will create the build in /var/lib/mock/... No download should be required.
Yup, my mistake, I was able to build. I'll try the process again by looking through the review's wanted list.
Also you may fork some packages at https://src.fedoraproject.org/ and do pull requests to show your ability as packager maintainer
Thanks for responding
Stephen
Emmanuel _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Hi Stephen,
thank you for your interest in contributing to Fedora. I can totally understand that the current policies may seem overwhelming so that becoming a packager might be seen as some kind of "elite" status. I think I would feel the same way if I didn't become a packager ~10 years ago.
However I would like to emphasize Ben's point:
I think becoming a packager is not as complicated as you’ve written. To become a packager, you must convince a packager sponsor to sponsor you. That’s all; there is no rule about how to do the convincing.
Maybe you do 1-2 package updates or fixes (pull request via src.fedoraproject.org) and check the Fedora wiki pages for a list of sponsors. Try contacting some of them directly after you verified they are still active (mailing list/src.fedoraproject.org). Also it helps usually if these sponsors are interested in the languages/tech stack which you tried to improve.
That being said: Java in Fedora is one of the hardest areas to tackle. Several "high profile" packagers had to give up on that task (despite heroic efforts) because it is just too much for one person (or a small team).
Part of the problem is that the Java upstream "culture" does not matches the processes of a traditional Linux distribution like Fedora. Lots of bundled dependencies, "secret" build processes and on top a huge number of small packages.
I can understand that "keeping Eclipse in Fedora" is a worthy goal for sure but really a lot of work. Other areas like Python packaging are much easier as applications tend to be smaller and bundling is less common in the Python world. (Also great efforts by our Python team!)
One of the things I'd be interested in is "reprocible builds" which I think might be easier to contribute. While there is a lot of infrastructure to build (= a lot of work) you can also just fix one package at a time (probably with a few upstream commits). Even if you stop contributing to Fedora after some months or years you advanced the state of Fedora/Linux anyway.
Felix
I'd also like to plug Jakub's new sponsor page: https://docs.pagure.org/fedora-sponsors/all
There you can find all currently active sponsors by language, interest, etc.
Cheers,
Dan
On August 12, 2021 7:29:10 AM UTC, Felix Schwarz fschwarz@fedoraproject.org wrote:
Hi Stephen,
thank you for your interest in contributing to Fedora. I can totally understand that the current policies may seem overwhelming so that becoming a packager might be seen as some kind of "elite" status. I think I would feel the same way if I didn't become a packager ~10 years ago.
However I would like to emphasize Ben's point:
I think becoming a packager is not as complicated as you’ve written. To become a packager, you must convince a packager sponsor to sponsor you. That’s all; there is no rule about how to do the convincing.
Maybe you do 1-2 package updates or fixes (pull request via src.fedoraproject.org) and check the Fedora wiki pages for a list of sponsors. Try contacting some of them directly after you verified they are still active (mailing list/src.fedoraproject.org). Also it helps usually if these sponsors are interested in the languages/tech stack which you tried to improve.
That being said: Java in Fedora is one of the hardest areas to tackle. Several "high profile" packagers had to give up on that task (despite heroic efforts) because it is just too much for one person (or a small team).
Part of the problem is that the Java upstream "culture" does not matches the processes of a traditional Linux distribution like Fedora. Lots of bundled dependencies, "secret" build processes and on top a huge number of small packages.
I can understand that "keeping Eclipse in Fedora" is a worthy goal for sure but really a lot of work. Other areas like Python packaging are much easier as applications tend to be smaller and bundling is less common in the Python world. (Also great efforts by our Python team!)
One of the things I'd be interested in is "reprocible builds" which I think might be easier to contribute. While there is a lot of infrastructure to build (= a lot of work) you can also just fix one package at a time (probably with a few upstream commits). Even if you stop contributing to Fedora after some months or years you advanced the state of Fedora/Linux anyway.
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Hello Dan, Thank you for reaching out with your response. I have to admit, I was in a provocotive mood the other day. I had solved a problem for a customer that had been worked on unsuccessfully by a local competitor for three weeks. I was at that moment the master of my trade craft and in fully glory. I bought some beer to celebrate and the resulting email came out. So that is not to say I wasn't at least venting some portion of truth. Please bear with me as I have spent 6 decades walking upright, and sometimes I find laying the foundation of a conversation requires preparation. I have built RPM's and SRPM's according to RedHat specifications, I think using their tutorials. I have also built an unoffical flatpak of the IntelliJ IDE IDEA. So as for technical capability, I can read a manual as well as the next person. My thoughts were that the sponsoring, the proven packagers were supposed to be package mentors I thought originally, shouldn't happen until after sign up, and sign up is preconditioned by a basic CBT course with "build an RPM" test as final progression criteria for getting to ask for a sponsor. Not something inhibiting but just build a simple RPM to cover tha basic process. My reasoning is the process for getting onboarded should, like accepting a resume or CV from anyone at anytime, be an open door. In order to capatilize on numbers certainly but also to encourage the real potential individuals who can contribute technically, but are severely hampered by initial barriers. Even if the barriers are only perceived ones. The initial CBT I mentioned would be a way for someone like that to get a "free test". A sort of confidence boost that takes nothing but their time, and allows them to show they can do that part. Also, if they have difficulties doing a simple RPM, they could take some time to get that going and come back to try again. All of this can happen without the need for a sponsor getting involved until a minimum level of capability is ascertained, which should offload some time (for sponsors), though likely minimal I would guess. We could make it a badge.
On Thu, 2021-08-12 at 19:58 +0000, Dan Čermák wrote:
I'd also like to plug Jakub's new sponsor page: https://docs.pagure.org/fedora-sponsors/all
There you can find all currently active sponsors by language, interest, etc.
I like the work Jakub did on the sponsor page. This is a good way to present them.
Cheers,
Dan
As for Eclipse in Fedora Linux, sadly I must say I left trying to get Eclipse going on Fedora Linux (Silverblue now) some time ago, in favour of doing what I needed in my home directory, including maven and graal, and using netbeans flatpak for IDE because it works. I don't blame Fedora Linux or the related packagers, the satate of Java can be fully blamed on the corporate entities involved at the heart of java. I think the packing group is doing the work, they are the ones who put together this thing we call Fedora Linux.
As for myself, I have enjoyed the benefits of Fedora Linux for a very long time and appreciate the efforts daily. I would like to return more than appreciation to the community and that is my impetus for wanting to package. I think I will take Chris Murphy's advice and start with reviews for now, there is a rather long backlog it seems.
Regards, Stephen
On August 12, 2021 7:29:10 AM UTC, Felix Schwarz fschwarz@fedoraproject.org wrote:
Hi Stephen,
thank you for your interest in contributing to Fedora. I can totally understand that the current policies may seem overwhelming so that becoming a packager might be seen as some kind of "elite" status. I think I would feel the same way if I didn't become a packager ~10 years ago.
However I would like to emphasize Ben's point:
I think becoming a packager is not as complicated as you’ve written. To become a packager, you must convince a packager sponsor to sponsor you. That’s all; there is no rule about how to do the convincing.
Maybe you do 1-2 package updates or fixes (pull request via src.fedoraproject.org) and check the Fedora wiki pages for a list of sponsors. Try contacting some of them directly after you verified they are still active (mailing list/src.fedoraproject.org). Also it helps usually if these sponsors are interested in the languages/tech stack which you tried to improve.
That being said: Java in Fedora is one of the hardest areas to tackle. Several "high profile" packagers had to give up on that task (despite heroic efforts) because it is just too much for one person (or a small team).
Part of the problem is that the Java upstream "culture" does not matches the processes of a traditional Linux distribution like Fedora. Lots of bundled dependencies, "secret" build processes and on top a huge number of small packages.
I can understand that "keeping Eclipse in Fedora" is a worthy goal for sure but really a lot of work. Other areas like Python packaging are much easier as applications tend to be smaller and bundling is less common in the Python world. (Also great efforts by our Python team!)
One of the things I'd be interested in is "reprocible builds" which I think might be easier to contribute. While there is a lot of infrastructure to build (= a lot of work) you can also just fix one package at a time (probably with a few upstream commits). Even if you stop contributing to Fedora after some months or years you advanced the state of Fedora/Linux anyway.
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 13/08/2021 13:37, Stephen Snow wrote:
I have built RPM's and SRPM's according to RedHat specifications, I think using their tutorials.
Fedora has its own RPM packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/
Even if the barriers are only perceived ones. The initial CBT I mentioned would be a way for someone like that to get a "free test".
You can always do an informal package review or send a PR for existing package.
As for Eclipse in Fedora Linux, sadly I must say I left trying to get Eclipse going on Fedora Linux (Silverblue now) some time ago, in favour of doing what I needed in my home directory, including maven and graal, and using netbeans flatpak for IDE because it works.
Building Java apps in your home directory with Internet access is a trivial task. The official Fedora builds has no network access, so you need to unbundle all dependencies into a separate packages first. This is the main problem.
* Vitaly Zaitsev via devel:
Building Java apps in your home directory with Internet access is a trivial task. The official Fedora builds has no network access, so you need to unbundle all dependencies into a separate packages first. This is the main problem.
In the build-on-demand Java case, there is no expectation that everything (including dependencies) is built from source. There is long-term backwards compatibility with existing bytecode, so sources are not technically required.
The Go and Rust models are superficially similar, but the compiler does not provide anything comparable to bytecode stability, so everything *has* to be compiled from source using the installed compiler.
Fedora's policy is to build from source. The problem is not so much that there is no network access on the builders, but that there are no immediately usable sources to build many Java packages. If it were just network access, it would be relatively straightforward to mirror everything into RPMs (like Go and Rust do), or perhaps use some other technology. But there is no general technical solution to the lack of viable source code.
Thanks, Florian
I wonder what are the requirements for using Copr? FAS account, but is there anything else? I think that maintaining packages in Copr for a while just to gain experience/confidence could deserve better promotion.
BTW there is also Fedora Join SIG which focuses on improving of newcomers experience. However not sure how active this SIG is.
Vít
[1] https://docs.fedoraproject.org/en-US/fedora-join/
Dne 13. 08. 21 v 13:37 Stephen Snow napsal(a):
Hello Dan, Thank you for reaching out with your response. I have to admit, I was in a provocotive mood the other day. I had solved a problem for a customer that had been worked on unsuccessfully by a local competitor for three weeks. I was at that moment the master of my trade craft and in fully glory. I bought some beer to celebrate and the resulting email came out. So that is not to say I wasn't at least venting some portion of truth. Please bear with me as I have spent 6 decades walking upright, and sometimes I find laying the foundation of a conversation requires preparation. I have built RPM's and SRPM's according to RedHat specifications, I think using their tutorials. I have also built an unoffical flatpak of the IntelliJ IDE IDEA. So as for technical capability, I can read a manual as well as the next person. My thoughts were that the sponsoring, the proven packagers were supposed to be package mentors I thought originally, shouldn't happen until after sign up, and sign up is preconditioned by a basic CBT course with "build an RPM" test as final progression criteria for getting to ask for a sponsor. Not something inhibiting but just build a simple RPM to cover tha basic process. My reasoning is the process for getting onboarded should, like accepting a resume or CV from anyone at anytime, be an open door. In order to capatilize on numbers certainly but also to encourage the real potential individuals who can contribute technically, but are severely hampered by initial barriers. Even if the barriers are only perceived ones. The initial CBT I mentioned would be a way for someone like that to get a "free test". A sort of confidence boost that takes nothing but their time, and allows them to show they can do that part. Also, if they have difficulties doing a simple RPM, they could take some time to get that going and come back to try again. All of this can happen without the need for a sponsor getting involved until a minimum level of capability is ascertained, which should offload some time (for sponsors), though likely minimal I would guess. We could make it a badge.
On Thu, 2021-08-12 at 19:58 +0000, Dan Čermák wrote:
I'd also like to plug Jakub's new sponsor page: https://docs.pagure.org/fedora-sponsors/all
There you can find all currently active sponsors by language, interest, etc.
I like the work Jakub did on the sponsor page. This is a good way to present them.
Cheers,
Dan
As for Eclipse in Fedora Linux, sadly I must say I left trying to get Eclipse going on Fedora Linux (Silverblue now) some time ago, in favour of doing what I needed in my home directory, including maven and graal, and using netbeans flatpak for IDE because it works. I don't blame Fedora Linux or the related packagers, the satate of Java can be fully blamed on the corporate entities involved at the heart of java. I think the packing group is doing the work, they are the ones who put together this thing we call Fedora Linux.
As for myself, I have enjoyed the benefits of Fedora Linux for a very long time and appreciate the efforts daily. I would like to return more than appreciation to the community and that is my impetus for wanting to package. I think I will take Chris Murphy's advice and start with reviews for now, there is a rather long backlog it seems.
Regards, Stephen
On August 12, 2021 7:29:10 AM UTC, Felix Schwarz fschwarz@fedoraproject.org wrote:
Hi Stephen,
thank you for your interest in contributing to Fedora. I can totally understand that the current policies may seem overwhelming so that becoming a packager might be seen as some kind of "elite" status. I think I would feel the same way if I didn't become a packager ~10 years ago.
However I would like to emphasize Ben's point:
I think becoming a packager is not as complicated as you’ve written. To become a packager, you must convince a packager sponsor to sponsor you. That’s all; there is no rule about how to do the convincing.
Maybe you do 1-2 package updates or fixes (pull request via src.fedoraproject.org) and check the Fedora wiki pages for a list of sponsors. Try contacting some of them directly after you verified they are still active (mailing list/src.fedoraproject.org). Also it helps usually if these sponsors are interested in the languages/tech stack which you tried to improve.
That being said: Java in Fedora is one of the hardest areas to tackle. Several "high profile" packagers had to give up on that task (despite heroic efforts) because it is just too much for one person (or a small team).
Part of the problem is that the Java upstream "culture" does not matches the processes of a traditional Linux distribution like Fedora. Lots of bundled dependencies, "secret" build processes and on top a huge number of small packages.
I can understand that "keeping Eclipse in Fedora" is a worthy goal for sure but really a lot of work. Other areas like Python packaging are much easier as applications tend to be smaller and bundling is less common in the Python world. (Also great efforts by our Python team!)
One of the things I'd be interested in is "reprocible builds" which I think might be easier to contribute. While there is a lot of infrastructure to build (= a lot of work) you can also just fix one package at a time (probably with a few upstream commits). Even if you stop contributing to Fedora after some months or years you advanced the state of Fedora/Linux anyway.
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Mon, Aug 16, 2021 11:57:57 +0200, Vít Ondruch wrote:
I wonder what are the requirements for using Copr? FAS account, but is there anything else? I think that maintaining packages in Copr for a while just to gain experience/confidence could deserve better promotion.
I think an FAS is pretty much all one needs: https://docs.pagure.org/copr.copr/user_documentation.html
BTW there is also Fedora Join SIG which focuses on improving of newcomers experience. However not sure how active this SIG is.
It's very active :D I'd note that the Join SIG only provides general guidance to newcomers to help them find the right team/SIG/area to participate in. Since each team/SIG tends to have its own requirements and on-boarding/sponsorship process, the newcomer will still have to engage with the team to participate (or get sponsored in the case of the package maintainers team).
If more package maintainers (and dev folks generally) can join the Join SIG and help newcomers along, that'll be great. The idea is to get newcomers better acquainted with the existing community so that they're comfortable and confident enough to participate.
The process we have in place is noted here: https://pagure.io/fedora-join/Welcome-to-Fedora
Basically, we get folks to create a Fedora account and then we file a first "Welcome to Fedora" ticket for them where we provide them with initial information about how Fedora is organised and what our foundations are and so on. Then we help newcomers find the area/team/SIG they'd like to work in and we guide them to joining it.
To join the Join SIG, you can just say "hello!" in a ticket here and someone will add you to the Pagure and FAS groups so you get notifications on new Welcome to Fedora tickets and so on. https://pagure.io/fedora-join/Fedora-Join/new_issue
On Fri, Aug 13, 2021 at 1:38 PM Stephen Snow s40w5s@gmail.com wrote:
Hello Dan, Thank you for reaching out with your response. I have to admit, I was in a provocotive mood the other day. I had solved a problem for a customer that had been worked on unsuccessfully by a local competitor for three weeks. I was at that moment the master of my trade craft and in fully glory. I bought some beer to celebrate and the resulting email came out. So that is not to say I wasn't at least venting some portion of truth. Please bear with me as I have spent 6 decades walking upright, and sometimes I find laying the foundation of a conversation requires preparation. I have built RPM's and SRPM's according to RedHat specifications, I think using their tutorials. I have also built an unoffical flatpak of the IntelliJ IDE IDEA. So as for technical capability, I can read a manual as well as the next person. My thoughts were that the sponsoring, the proven packagers were supposed to be package mentors I thought originally, shouldn't happen until after sign up, and sign up is preconditioned by a basic CBT course with "build an RPM" test as final progression criteria for getting to ask for a sponsor. Not something inhibiting but just build a simple RPM to cover tha basic process. My reasoning is the process for getting onboarded should, like accepting a resume or CV from anyone at anytime, be an open door. In order to capatilize on numbers certainly but also to encourage the real potential individuals who can contribute technically, but are severely hampered by initial barriers. Even if the barriers are only perceived ones. The initial CBT I mentioned would be a way for someone like that to get a "free test". A sort of confidence boost that takes nothing but their time, and allows them to show they can do that part. Also, if they have difficulties doing a simple RPM, they could take some time to get that going and come back to try again. All of this can happen without the need for a sponsor getting involved until a minimum level of capability is ascertained, which should offload some time (for sponsors), though likely minimal I would guess. We could make it a badge.
Hello Stephen,
I think this situation is very unfortunate and unintended. I think you can do (or you can start doing it) what you came to do in Fedora, without the "packager status". In general when you already have some project / package in Fedora that you want to maintain, you can start to work on it straight away, as a part of gaining your packager status. That is, while receiving feedback /advice/ from sponsor. It's a way to gain the actual skill to become a packager - I don't think any robot/test can replace that. I don't think packaging is about just doing builds, in a way "it works", but rather creating a good spec file / good package that will last for years.
Doing unofficial reviews for a package you want to get into Fedora, or submitting a new package review request (if you want to get it to Fedora), or re-review request (if you want to unorphan the package). Creating PRs with an enhancement / or package upgrade. Last one you can even do anonymously:
https://fedoraproject.org/wiki/Package_maintenance_guide#Using_fedpkg_anonym...
All of the above are IMO examples of what packager does. There's no reason to do something else - you can just start straight away with what you intend to do, and get a "packager" status later. Or is there an obstacle that you packager status for, to do anything meaningful for you?
I really hope there's a path to achieve what you came to Fedora for. If not, I'd argue it needs to be created.
I don't think the idea of getting a packager status, just to get it reverted some time later, wouldn't help you to become a (better) packager. For all the best ways of collaboration (which is IMHO what Fedora is all about) you don't need the packager status for.
Regards, Pavel
On Thu, 2021-08-12 at 19:58 +0000, Dan Čermák wrote:
I'd also like to plug Jakub's new sponsor page: https://docs.pagure.org/fedora-sponsors/all
There you can find all currently active sponsors by language, interest, etc.
I like the work Jakub did on the sponsor page. This is a good way to present them.
Cheers,
Dan
As for Eclipse in Fedora Linux, sadly I must say I left trying to get Eclipse going on Fedora Linux (Silverblue now) some time ago, in favour of doing what I needed in my home directory, including maven and graal, and using netbeans flatpak for IDE because it works. I don't blame Fedora Linux or the related packagers, the satate of Java can be fully blamed on the corporate entities involved at the heart of java. I think the packing group is doing the work, they are the ones who put together this thing we call Fedora Linux.
As for myself, I have enjoyed the benefits of Fedora Linux for a very long time and appreciate the efforts daily. I would like to return more than appreciation to the community and that is my impetus for wanting to package. I think I will take Chris Murphy's advice and start with reviews for now, there is a rather long backlog it seems.
Regards, Stephen
On August 12, 2021 7:29:10 AM UTC, Felix Schwarz fschwarz@fedoraproject.org wrote:
Hi Stephen,
thank you for your interest in contributing to Fedora. I can totally understand that the current policies may seem overwhelming so that becoming a packager might be seen as some kind of "elite" status. I think I would feel the same way if I didn't become a packager ~10 years ago.
However I would like to emphasize Ben's point:
I think becoming a packager is not as complicated as you’ve written. To become a packager, you must convince a packager sponsor to sponsor you. That’s all; there is no rule about how to do the convincing.
Maybe you do 1-2 package updates or fixes (pull request via src.fedoraproject.org) and check the Fedora wiki pages for a list of sponsors. Try contacting some of them directly after you verified they are still active (mailing list/src.fedoraproject.org). Also it helps usually if these sponsors are interested in the languages/tech stack which you tried to improve.
That being said: Java in Fedora is one of the hardest areas to tackle. Several "high profile" packagers had to give up on that task (despite heroic efforts) because it is just too much for one person (or a small team).
Part of the problem is that the Java upstream "culture" does not matches the processes of a traditional Linux distribution like Fedora. Lots of bundled dependencies, "secret" build processes and on top a huge number of small packages.
I can understand that "keeping Eclipse in Fedora" is a worthy goal for sure but really a lot of work. Other areas like Python packaging are much easier as applications tend to be smaller and bundling is less common in the Python world. (Also great efforts by our Python team!)
One of the things I'd be interested in is "reprocible builds" which I think might be easier to contribute. While there is a lot of infrastructure to build (= a lot of work) you can also just fix one package at a time (probably with a few upstream commits). Even if you stop contributing to Fedora after some months or years you advanced the state of Fedora/Linux anyway.
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Hello Pavel, Thank you for your thoughts. It strikes me that perhaps what you're advising me to do, is likely what I was wanting to do in the first place. I certainly don't feel dissatisfied being a non-packager in Fedora land, and I am probably a bit guilty of exageration of the difficulties on the road to becoming a packager. Honestly, I am looking forward to setting up to do some testing for now. Thanks to everyone for taking the time to offer me the options available to become a packager, this is indeed a good part of why I enjoy being part of the community that is Fedora.
Regards, Stephen
On Mon, 2021-08-16 at 19:59 +0200, Pavel Valena wrote:
On Fri, Aug 13, 2021 at 1:38 PM Stephen Snow s40w5s@gmail.com wrote:
Hello Dan, Thank you for reaching out with your response. I have to admit, I was in a provocotive mood the other day. I had solved a problem for a customer that had been worked on unsuccessfully by a local competitor for three weeks. I was at that moment the master of my trade craft and in fully glory. I bought some beer to celebrate and the resulting email came out. So that is not to say I wasn't at least venting some portion of truth. Please bear with me as I have spent 6 decades walking upright, and sometimes I find laying the foundation of a conversation requires preparation. I have built RPM's and SRPM's according to RedHat specifications, I think using their tutorials. I have also built an unoffical flatpak of the IntelliJ IDE IDEA. So as for technical capability, I can read a manual as well as the next person. My thoughts were that the sponsoring, the proven packagers were supposed to be package mentors I thought originally, shouldn't happen until after sign up, and sign up is preconditioned by a basic CBT course with "build an RPM" test as final progression criteria for getting to ask for a sponsor. Not something inhibiting but just build a simple RPM to cover tha basic process. My reasoning is the process for getting onboarded should, like accepting a resume or CV from anyone at anytime, be an open door. In order to capatilize on numbers certainly but also to encourage the real potential individuals who can contribute technically, but are severely hampered by initial barriers. Even if the barriers are only perceived ones. The initial CBT I mentioned would be a way for someone like that to get a "free test". A sort of confidence boost that takes nothing but their time, and allows them to show they can do that part. Also, if they have difficulties doing a simple RPM, they could take some time to get that going and come back to try again. All of this can happen without the need for a sponsor getting involved until a minimum level of capability is ascertained, which should offload some time (for sponsors), though likely minimal I would guess. We could make it a badge.
Hello Stephen,
I think this situation is very unfortunate and unintended. I think you can do (or you can start doing it) what you came to do in Fedora, without the "packager status". In general when you already have some project / package in Fedora that you want to maintain, you can start to work on it straight away, as a part of gaining your packager status. That is, while receiving feedback /advice/ from sponsor. It's a way to gain the actual skill to become a packager - I don't think any robot/test can replace that. I don't think packaging is about just doing builds, in a way "it works", but rather creating a good spec file / good package that will last for years.
Doing unofficial reviews for a package you want to get into Fedora, or submitting a new package review request (if you want to get it to Fedora), or re-review request (if you want to unorphan the package). Creating PRs with an enhancement / or package upgrade. Last one you can even do anonymously:
https://fedoraproject.org/wiki/Package_maintenance_guide#Using_fedpkg_anonym...
All of the above are IMO examples of what packager does. There's no reason to do something else - you can just start straight away with what you intend to do, and get a "packager" status later. Or is there an obstacle that you packager status for, to do anything meaningful for you?
I really hope there's a path to achieve what you came to Fedora for. If not, I'd argue it needs to be created.
I don't think the idea of getting a packager status, just to get it reverted some time later, wouldn't help you to become a (better) packager. For all the best ways of collaboration (which is IMHO what Fedora is all about) you don't need the packager status for.
Regards, Pavel
On Thu, 2021-08-12 at 19:58 +0000, Dan Čermák wrote:
I'd also like to plug Jakub's new sponsor page: https://docs.pagure.org/fedora-sponsors/all
There you can find all currently active sponsors by language, interest, etc.
I like the work Jakub did on the sponsor page. This is a good way to present them.
Cheers,
Dan
As for Eclipse in Fedora Linux, sadly I must say I left trying to get Eclipse going on Fedora Linux (Silverblue now) some time ago, in favour of doing what I needed in my home directory, including maven and graal, and using netbeans flatpak for IDE because it works. I don't blame Fedora Linux or the related packagers, the satate of Java can be fully blamed on the corporate entities involved at the heart of java. I think the packing group is doing the work, they are the ones who put together this thing we call Fedora Linux.
As for myself, I have enjoyed the benefits of Fedora Linux for a very long time and appreciate the efforts daily. I would like to return more than appreciation to the community and that is my impetus for wanting to package. I think I will take Chris Murphy's advice and start with reviews for now, there is a rather long backlog it seems.
Regards, Stephen
On August 12, 2021 7:29:10 AM UTC, Felix Schwarz fschwarz@fedoraproject.org wrote:
Hi Stephen,
thank you for your interest in contributing to Fedora. I can totally understand that the current policies may seem overwhelming so that
becoming a
packager might be seen as some kind of "elite" status. I think I would feel the same way if I didn't become a packager
~10
years ago.
However I would like to emphasize Ben's point:
I think becoming a packager is not as complicated as you’ve written. To become a packager, you must convince a packager sponsor to sponsor you. That’s all; there is no rule about how to do the convincing.
Maybe you do 1-2 package updates or fixes (pull request via src.fedoraproject.org) and check the Fedora wiki pages for a
list
of sponsors. Try contacting some of them directly after you verified they
are
still active (mailing list/src.fedoraproject.org). Also it helps usually if these sponsors are interested in the languages/tech stack which you tried to improve.
That being said: Java in Fedora is one of the hardest areas to tackle. Several "high profile" packagers had to give up on that task (despite heroic efforts) because it is just too much for one person (or a small team).
Part of the problem is that the Java upstream "culture" does
not
matches the processes of a traditional Linux distribution like Fedora. Lots
of
bundled dependencies, "secret" build processes and on top a huge number
of
small packages.
I can understand that "keeping Eclipse in Fedora" is a worthy
goal
for sure but really a lot of work. Other areas like Python packaging are
much
easier as applications tend to be smaller and bundling is less common in
the
Python world. (Also great efforts by our Python team!)
One of the things I'd be interested in is "reprocible builds"
which
I think might be easier to contribute. While there is a lot of infrastructure to build (= a lot of work) you can also just fix one package at a time (probably with a few upstream commits). Even if you stop contributing to Fedora after some months or years you advanced the state of Fedora/Linux anyway.
Felix _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to
devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
-
Aleksandar Kurtakov -
Ankur Sinha -
Ben Beasley -
Ben Cotton -
Dan Čermák -
Dan Čermák -
Emmanuel Seyman -
Fabio Valentini -
Felix Schwarz -
Florian Weimer -
Hans de Goede -
Iago Rubio -
Jerry James -
Kevin Kofler -
Markku Korkeala -
Mat Booth -
Matthew Miller -
Mikolaj Izdebski -
Miro Hrončok -
Pavel Valena -
Stephen John Smoogen -
Stephen Snow -
Sérgio Basto -
Vitaly Zaitsev -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek