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? -- 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
