On Thu, Sep 10, 2020 at 4:23 PM Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> wrote: > > 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. You deliver Ant and Maven to nobody. The modules are essentially unused and / or useless. > > > 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. I don't know which Java SIG you're talking about, because in the past two years, I've seen none of this. > > > 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. So, you respect FESCo decisions but you choose to ignore the consequences? m'kay. > > 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]. It's also the *only* non-modular package you still maintain. However, the only changes you made in the past two years were 1) enabling xmvn-javadoc upon my request and 2) switching the default Java to OpenJDK 11 opon Jiri Vanek's request ... > > [...] > > > 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) This is one of the *worst* aspects of Modularity - being able to "hide" implementation details from re-use by others. I would not see this as a benefit, but as a big issue when it comes to the bigger distribution and collaboration context. > > 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. Well, I can't even tell where (or if) you've been working on this stuff at all for the past 10 months. I find no commits in the modules/javapackages-tools module, nor in javapackages-tools-201902 branches, nor in the maven-3.6 branches more recently than 10 months ago. The most recent builds I can find for you and mkoncek are still in 2019 (!). So please tell me, am I imagining things, or have you actually not contributed anything to fedora packages in the last 10 months? Fabio _______________________________________________ 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