On Thu, Sep 10, 2020 at 3:29 PM Dominik 'Rathann' Mierzejewski <dominik@xxxxxxxxxxxxxx> wrote: > > 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. Javapackages is the main project that provides Java packaging tooling. I am maintaining it both upstream [1] and in Fedora, also as ursine package [2]. > [...] > > 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? All Fedora packages shipped to users are expected to be high-quality and well maintained, which may impose a very significant burden on maintainers. But for build-only packages (packages are used only during build, not shipped to users), many of package maintainer responsibilities [3] can be reduced to almost nothing. For example "manage security issues" means triaging them and fixing only very small subset of them (since user can't install the packages, most of vulnerabilities are not exploitable), "deal with reported bugs" means closing them NOTABUG as users can't possibly install the package in a "supported" way, "track dependency issues" duty is reduced as nothing non-modular can depend on the package, and so on. [1] https://github.com/fedora-java/javapackages [2] https://src.fedoraproject.org/rpms/javapackages-tools [3] https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/ > > 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 > _______________________________________________ > 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
