The Death of Java (packages)

[Fabio Valentini]

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

[Stephen John Smoogen]

On Mon, 26 Apr 2021 at 15:20, Fabio Valentini <decathorpe(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  

-- 
Stephen J Smoogen.

[Ben Cotton]

On Mon, Apr 26, 2021 at 3:26 PM Fabio Valentini <decathorpe(a)gmail.com&gt; 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.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Matthew Miller]

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!


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Aleksandar Kurtakov]

On Mon, Apr 26, 2021 at 10:26 PM Fabio Valentini <decathorpe(a)gmail.com&gt;
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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team

[Sérgio Basto]

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 . 

-- 
Sérgio M. B.

[Ankur Sinha]

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.

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

[Emmanuel Seyman]

* Fabio Valentini [26/04/2021 21:19] :
>                                                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. 
Thank you for all the work you've done, Fabio.

Emmanuel

[Mikolaj Izdebski]

On Mon, Apr 26, 2021 at 9:26 PM Fabio Valentini <decathorpe(a)gmail.com&gt; 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

[Dan Čermák]

Hi Mikolaj,

Mikolaj Izdebski <mizdebsk(a)redhat.com&gt; writes:

>   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. 
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

[Mikolaj Izdebski]

On Tue, Apr 27, 2021 at 5:18 PM Dan Čermák
<dan.cermak(a)cgc-instruments.com&gt; wrote:
>  Hi Mikolaj,
>
>  Mikolaj Izdebski <mizdebsk(a)redhat.com&gt; writes:
>
>  >  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.
>
>  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

[Kevin Kofler]

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

[Miro Hrončok]

On 27. 04. 21 16:49, Mikolaj Izdebski wrote:
>  On Mon, Apr 26, 2021 at 9:26 PM Fabio Valentini
> <decathorpe(a)gmail.com&gt; 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!

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Hans de Goede]

Hi Mikolaj,

On 4/27/21 4:49 PM, Mikolaj Izdebski wrote:
>  On Mon, Apr 26, 2021 at 9:26 PM Fabio Valentini
> <decathorpe(a)gmail.com&gt; 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. 
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

[Mikolaj Izdebski]

Hi Hans,

On Wed, Apr 28, 2021 at 3:47 PM Hans de Goede <hdegoede(a)redhat.com&gt; 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:
>
>  1. 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.

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

[Hans de Goede]

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(a)redhat.com&gt; 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:
> >
> > 1. 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.
>  
> > 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
>  
>  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

[Jerry James]

On Mon, Apr 26, 2021 at 1:20 PM Fabio Valentini <decathorpe(a)gmail.com&gt; 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,
-- 
Jerry James
http://www.jamezone.org/

[Mat Booth]

On Mon, 26 Apr 2021 at 20:20, Fabio Valentini <decathorpe(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  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

[Hans de Goede]

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

[Markku Korkeala]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Stephen Snow]

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.

[Vitaly Zaitsev]

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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Stephen Snow]

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(a)easycoding.org)
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure

[Vitaly Zaitsev]

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_...

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Miro Hrončok]

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_...
Correction: If the package was *retired* more than 8 weeks ago.

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Ben Beasley]

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(a)easycoding.org)
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
> 
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Zbigniew Jędrzejewski-Szmek]

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_gro...

Zbyszek

[Iago Rubio]

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.

[Ankur Sinha]

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.

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

[Iago Rubio]

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.

[Ankur Sinha]

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.

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

[Iago Rubio]

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.

[Ankur Sinha]

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.

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

[Vít Ondruch]

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

[Emmanuel Seyman]

* 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

[Stephen Snow]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure

[Emmanuel Seyman]

* 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

[Stephen Snow]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure

[Sérgio Basto]

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(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  > Do not reply to spam on the list, report it:
>  > https://pagure.io/fedora-infrastructure
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: 
>  https://pagure.io/fedora-infrastructure 
-- 
Sérgio M. B.

[Felix Schwarz]

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

[Dan Čermák]

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(a)fedoraproject.org&gt;
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(a)lists.fedoraproject.org
>To unsubscribe send an email to devel-leave(a)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/[e-mail]
>Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Stephen Snow]

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(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  > Do not reply to spam on the list, report it:
>  > https://pagure.io/fedora-infrastructure

[Vitaly Zaitsev]

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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Florian Weimer]

* 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

[Vít Ondruch]

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(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
> >> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >> Do not reply to spam on the list, report it:
> >> https://pagure.io/fedora-infrastructure
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Ankur Sinha]

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

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

[Pavel Valena]

On Fri, Aug 13, 2021 at 1:38 PM Stephen Snow <s40w5s(a)gmail.com&gt; 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_ano...

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(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
>  > > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  > > Do not reply to spam on the list, report it:
>  > > https://pagure.io/fedora-infrastructure
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Stephen Snow]

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(a)gmail.com&gt;
>  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_ano...
>  
>  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(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
>  > > > To unsubscribe send an email to
>  > devel-leave(a)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/[e-mail]
>  > > > Do not reply to spam on the list, report it:
>  > > > https://pagure.io/fedora-infrastructure
>  > 
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  > Do not reply to spam on the list, report it:
>  > https://pagure.io/fedora-infrastructure