Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux