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 Fri, Sep 11, 2020 at 2:02 PM Adam Williamson
<adamwill@xxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, 2020-09-11 at 12:44 +0300, Aleksandar Kurtakov wrote:
> > On Fri, Sep 11, 2020 at 11:54 AM Tomasz Torcz <tomek@xxxxxxxxxxxxxx> wrote:
> >
> > > On Fri, Sep 11, 2020 at 10:16:02AM +0200, Mikolaj Izdebski wrote:
> > > > You get a side tag in Koji where you can have private build-only
> > > > dependencies that are discarded (filtered) once they are no longer
> > > > needed, after module build is done. For build-only packages most of
> > > > security vulnerabilities are not exploitable easily, or at all,
> > > > therefore are low-severity, which greatly limits maintenance work
> > > > required to address them. For example, if upstream tests are ran on an
> > > > obsolete, 12-years old version of Tomcat, I don't need to skip tests,
> > > > but I can package old Tomcat and run the tests.
> > >
> > >   Whoha! Let's step back for a minute and look at this example.
> > > What are the reasons to run tests?  To make sure the package will run
> > > correctly..
> > > Why run tests on 12-years old version instead of on current one?
> > > Probably because tests fail on current version?
> > >
> > >   Will the end user run the package on obsolete Tomcat or on the current
> > > one?
> > > Of course on the current one. The one on which tests fail.
> > > Tests in this case are worthless, they are not testing the real
> > > situation. Disabling tests is no worse than testing on obsolete version.
> > > Relying on such tests is a disservice for the end user.
> > >
> > >   The point of testing is to validate code in real situation.
> > > Crafting special, unrealistic environment (12 years old Tomcat) just to
> > > have
> > > test pass is missing the point of tests.
> > >
> >
> > Well, you do realize how much not feasible it is for the Fedora maintainer
> > of hundred packages to go out and not only fix the builds, bugs, CVEs and
> > etc. but even the tests for all these packages. The unrealistic
> > expectations for what package maintainer should do is really not helping
> > growing that number.
>
> I've been struggling with how to make this point without sounding
> cynical, but hey, let's just lay it out there:
>
> If one of the issues here can be stated as "we want buildroot-only
> packages because we don't want to maintain those packages to a high
> standard", it is demonstrably a viable choice within Fedora to just
> *not maintain those packages to a high standard*. Maybe we wish it
> wasn't the case, but this is a thing that happens all the time. We have
> lots of packages that are, by any reasonable standard, rather badly
> maintained. It would be lovely if all Fedora packages had all their
> bugs aggressively addressed and had great test suites and had CVE
> issues jumped on immediately. But, well, the evidence suggests quite
> strongly that this is not the case. For e.g., I did a very sloppy
> search yesterday for Fedora bugs with "CVE" in the topic which were
> opened before June 2 and are still open:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=__open__&chfield=%5BBug%20creation%5D&chfieldto=2020-06-01&classification=Fedora&list_id=11345766&query_format=advanced&short_desc=CVE&short_desc_type=allwordssubstr
>
> it is capped at 1000 results. Which, you know, doesn't *scream* that
> all our packages are being diligently maintained from a CVE point of
> view, which implies at least some of them aren't being diligently
> maintained from any point of view. Even if some or many of those CVEs
> happen to have been fixed by version updates and it's just that the
> bugs weren't closed - the very fact that the bugs aren't being handled
> is a maintenance issue.
>
> So here is my cynical point: if you want to have poorly-maintained
> packages, isn't it still better that they be poorly-maintained distro
> packages where at least everyone understands how the process works and
> proven packagers can fix stuff up if they are inclined to, than that
> they be hidden buildroot-only poorly maintained packages?

Thank you for making these points. These are my thoughts *exactly*. As
a newcomer to packaging, I was willing to start helping out with those
packages that I depended on, to bring them up to speed, and it was
relatively easy to take on a few, because everything was out in the
open. But once things started getting retired (at a pace I couldn't
keep up with), even though they were still technically maintained in
some hidden world that I didn't understand, I was completely turned
off from helping out with more of the dependencies that my Java
projects required and had to retire my Java packages as well.

I would go further to suggest that poorly-maintained libs like these
are perfect opportunities for mentoring new people and community
growth.
FWIW, every year in October, for the past several years, Digital Ocean
and GitHub have teamed up to sponsor "Hacktoberfest" (I've
participated, but am not affiliated with either of them at all).
Projects label their issues with a "Hacktoberfest" or "Good first
issue" or "Help Wanted" label, and people from all over the world
contribute to projects with such labels... projects they've never
contributed to before... it's a great outreach program for open
source. I understand the reasons against using GitHub for our package
sources, but imagine if we took our poorly-maintained projects, and
instead of retiring them, we used them for such opportunities? Imagine
how much more awesome Fedora could be! I'd much rather have a bunch of
outdated Java libs laying around in a world where such opportunities
existed with a low bar to entry, than to have a smaller set of
up-to-date packages with fewer such opportunities, and a higher bar to
entry.

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> _______________________________________________
> 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




[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