Hi,
On 9/11/20 6:08 PM, Fabio Valentini wrote:
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?
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
_______________________________________________
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
