On Fri, Sep 11, 2020 at 1:06 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > Hi, > > On 9/11/20 12:47 PM, Vít Ondruch wrote: > > > > Dne 11. 09. 20 v 11:03 Hans de Goede napsal(a): > >> > >> > >> On 9/11/20 10:16 AM, Mikolaj Izdebski wrote: > >> > >>> Another, more concrete example: core Ant doesn't have any dependencies > >>> beyond JDK. It is easy to build and maintain, yet very functional. On > >>> the other hand, full Ant with all the optional tasks depends on more > >>> than 200 Java packages. For the purpose of building all packages that > >>> I am interested in, core Ant with JUnit tasks (total of 3 packages) is > >>> sufficient. Functionalities of Ant like sending emails or image > >>> processing are obviously not needed in this case. If building other > >>> packages is the only use of Ant then it can be maintained much more > >>> easily (3 instead of ~250 packages). But when Ant is ursine package in > >>> Fedora then it should be the full Ant - we can't claim to deliver Ant > >>> to users while it is just part of it. Eclipse in Fedora requires full > >>> Ant too. > >> > >> So if you say that you only need the minimal Ant, and I guess many > >> packages only need the minimal Ant to build, then why not have > >> an ant-minimal package, like we have a vim-minimal ? > >> > >> Now I guess that vim-minimal and "proper" vim are both build from the > >> same source-rpm; and normally we never allow 2 srpms with the same > >> upstream sources in them. But I think that in this case we could make > >> an exemption where there is a separate pkg-git and srpm for an > >> ant-minimal > >> which you would maintain. > >> > >> And then the community / java-sig can maintain the full Ant as I believe > >> is already happening since we do have an ant packaged in Fedora 33 atm. > > > > > > How this reduce the workload? > > It doesn't the purpose of my email was to look for ways to get > the modular ant/maven repos work moved back into ursine without > increasing the workload for the maintainers of those modular > repos. > > So the way to look at this, is does it increase workload, > and AFAICT it does not increase workload, while it would allow > us to fold the work being done in the modular repos back > into the ursine repo (for the ant example at least). > > Alternatively if we fold that work back into the ursine repos, > then the modular builds could start relying on the full-blown > ant build maintained by the java-SIG in the ursine repos and > drop their own ant-minimal, at which point it would reduce the > workload for the maintainers of the modular repos. > > My idea behind having a separate ant-minimal is that they > then can ensure that that is new enough and otherwise matches > their needs without relying on the full-blown version, but > actually somply switching to the full-blown java-SIG maintained > version might be better. > > Regards, > > Hans (snip) > p.s. > > I would not mind picking up maintenance of 1 or 2 of the > less frequently changing java packages (*) if that helps. > I wonder how much more people there are like me who care > enough about java to be willing to put some work in > (but not lots of work) ? > > Perhaps it would be a good idea for the java-SIG to make > a list of easy to maintain (for an experienced packager) > pkgs which could use a new primary maintainer. I realize > maintaining the entire stack is a team effort, so the rest of > the java-SIG will of course be/stay a co-maintainer of these. > But having things like rebasing to latest upstream, or just > addressing bugzillas taken care of mostly by a new > primary maintainer who is willing to pick up some packages > might help reduce the load ? > > The idea here is for someone (e.g.) me to NOT jump in now, > do a bunch of work to help out and then disappear again. > Instead I would invest say 1-2 hours every 2 weeks, which > may not seem much but over time adds up and if we can > get more people to do this, then maybe we can spread the > load of the java packages in the ursine repos better ? That would be great, any help is appreciated. I can try to come up with a list of often-used-but-simple-to-maintain Java packages? Side note: I just checked, and the *whole* Java stack that was previously maintained by the Stewardship SIG and was now moved into a dedicated Java SIG group - @java-maint-sig - has only 2 (in words: TWO) open CVE bugs associated with it. One was filed against log4j12 (which we're actively trying to get rid of), and the other was filed against resteasy, where a fix is blocked by getting the package updated to a newer version (with lots of new dependencies). So I have no idea where that "big burden of fixing CVE issues" is for Java packages actually is ... 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
