Hi,
On 9/11/20 6:08 PM, Fabio Valentini wrote:
On Fri, Sep 11, 2020 at 1:06 PM Hans de Goede
<hdegoede(a)redhat.com> 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?
Yes that sounds great. I would be happy to pick up a few of
those to help and if a bunch of us do that hopefully we can
lighten the load a bit.
Regards,
Hans