On Thursday, 10 September 2020 at 14:50, Joe Orton wrote:
[...]
1. The team has two missions in Fedora:
a) We deliver, maintain and support Ant and Maven in Fedora. Our aim
is to provide developers with the most popular Java build systems
which are reviewed, tested, and updated through the release
lifecycle.
b) We design, develop and document tooling that enables anyone to
package Java software with a simple, efficient and scalable process.
We are also active members of Java SIG, collaborating on complex
changes and guiding new contributors.
2. We are committed to maintaining the Ant and Maven modules in
Fedora. We have always expected to make them available as default
streams and in the buildroot so they can be available and consumed by
non-modular packages, but we completely respect the decisions of FESCo
to disallow default streams and of other contributors to adopt and
maintain the non-modular packages. We are not going to promise to
commit time and resources to maintain the non-modular packages.
Points 1b and 2 mean that nobody can consume your packages for
maintaining non-modular Java packages, which raises the bar for
maintaining Java packages considerably.
For example, I wanted to maintain a couple of Java packages, but I
didn't have time to (learn how to) maintain modules. This effectively
means that certain software won't be packaged for Fedora (by me). I
certainly don't have the time to maintain non-modular Ant and Maven
packages in addition to what I actually wanted to maintain. I'm pretty
sure there are quite a few people in a similar position.
[...]
4. The benefit we want to preserve from modules is to maintain
packages with varying expectation of quality, specifically separating
the build-time-only vs runtime dependencies. e.g. in that case that a
web server like Eclipse Jetty is required as a dep for testing another
component during the build, we want to be able to use and build that
component, without being indefinitely on the hook for security
errata. (The build dependency tree is particularly complex for Maven
and involves many examples of packages with frequent and high severity
vulnerabilies)
On one hand, that's understandable, but you're effectively maintaining
those packages anyway. And I don't see any reason why you couldn't do
that in the traditional non-modular way, which makes it easier for
others to step in and co-maintain. I'm not sure what you mean by
"indefinitely on the hook for security errata". Can you elaborate?
Regards,
Dominik
--
Fedora
https://getfedora.org | RPM Fusion
http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan