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
