On Tue, Sep 10, 2019 at 12:23 PM Dridi Boukelmoune <dridi.boukelmoune@xxxxxxxxx> wrote:
On Sun, Sep 8, 2019 at 6:51 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
>
> Hello packagers,
>
> The Stewardship SIG is currently providing only bare-minimum
> maintenance for some Java packages, and none of our packages depend on
> them anymore.
> So, we're looking for someone to take better care of them, preferably
> someone who actively uses these packages or maintains a package that
> depends on them.
>
> The packages are:
>
> - java-base64
> - jboss-jstl-1.2-api
> - jetty-version-maven-plugin
> - stringtemplate4
> - tagsoup
>
> Directly dependent packages of java-base64:
> - Java-WebSocket
> - elasticsearch
> - gherkin2-java
> - java-vash
> - java-xmlbuilder
> - jets3t
> - rescu
> - smack
> - sshj
Doesn't Java have a Base64 class in its standard library since Java 8?
Apologies if I remember wrong since I'm not doing any Java anymore and
haven't for years now, but the java-base64 could go away if dependent
upstreams used the built-in codec. My understanding is that it would
be the package maintainers' responsibility to bring this up, potentially
with patches, but it is also my understanding that we are dearly missing
maintainers in this area...
Absolutely correct. Unfortunately Java ecosystem is full with tons of archaic deps lingering around and not many people trying to clear things. Many of us who did packaging found out that it's more beneficial to devote all energy to bringing some sanity in upstreams which left the whole in the packaging world we are seeing now.
My 2 cents
> Directly dependent packages of jboss-jstl-1.2-api:
> - jboss-jsf-2.1-api
> - jboss-jsf-2.2-api
>
> Directly dependent packages of jetty-version-maven-plugin:
> - jetty8
>
> Directly dependent packages of stringtemplate4:
> - antlr3
> - antlr4
> - eclipselink
> - gs-collections
>
> Directly dependent packages of tagsoup:
> - icedtea-web
> - javadocofflinesearch
> - tika
> - xom
>
>
> If you received this email directly, you're a (co-)maintainer of one
> of these packages, and would probably be best qualified to take care
> of the package in question.
>
> If you want to take one, some, or all of them off our hands, just fill
> out the "package_adoption_request" template here, and we will transfer
> the package to you. https://www.pagure.io/stewardship-sig/new_issue
>
> If nobody claims the packages within the next two weeks, we will
> orphan them again, setting them on their course towards retirement in
> about two months.
>
> Thanks,
> Fabio (decathorpe), for the Stewardship SIG
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
--
Alexander Kurtakov
Red Hat Eclipse Team_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
