On Fri, 11 Sep 2020 at 07:27, Mario Torre <neug...@redhat.com> wrote:
> On Fri, Sep 11, 2020 at 11:04 AM Hans de Goede <hdego...@redhat.com> > wrote: > > > So for this tomcat needed for testing problem, I'm thinking that we > > might solve this in a very non Fedora way. Why not bundle the old > > tomcat-sources with the sources which need it for their test-suite > > (and build it before running the tests). > > To be honest, when I look at this example, I think we shouldn't have > that library/application packaged at all. > > If something can't even run the tests without requiring a 12+ year old > obsoleted code/infrastructure, what chances are that it's maintained > correctly? > > The issue is that like https://xkcd.com/2347/ you need that software for a couple dozen other things which may have no obvious relation to it. You start pulling a large number of packages and people start screaming that you are killing their need for using Fedora. that then puts pressure on someone else to try a herculian task of keeping that package in. Or you find out that this java package is getting pulled in for say a test suite in rust and you have to pull the browser, mail client and dozen other things out because of that. You might say "well I will maintain it until that test gets pulled out" and then you find out a dozen other software tools now need it because they saw Mozilla used it so it must be ok. As the back of the bottle says "rinse, lather, repeat". The bigger problem is that the software we ship has gotten more complicated and interdependent over the last decade while the number of packagers who can deal with that complexity has not grown. You can't bring in a newbie to take over part of some of these stacks because it reverberates through a hundred other packages without knowing it. Personally I think the real problem are we are constantly trying to square the circle. 1. we insist on trying to keep everything in one repository and hope that some patched up depsolver can 'theoretically fix it for us' so we never have an Extras/Core debacle again. 2. we put incredible pressure on maintainers and the project as a whole to have ALL the software and not dropping anything even when it is clear it doesn't work in a bundled with the OS format. 3. Never admitting that we messed up in the past but keep pushing through assuming that by god our mighty brains can eventually solve these conundrums. This may sound like a dig about modularity but it is much more about admitting that the Java maintainer complaints in 2006-> 2009? about treating Java like C in packaging was going to lead to no one maintaining it and it falling apart. The same problem is running through the Node community, the Erlang community, etc etc. In the end we have a bunch of rules to try and make a camel like a horse and then wonder why we keep getting spat on by our 'horses'. > Cheers, > Mario > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH <https://www.redhat.com> > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Stephen J Smoogen.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
