On Tue, Oct 5, 2021 at 1:27 PM Peter Boy <p...@uni-bremen.de> wrote:
>
>
>
> > Am 04.10.2021 um 15:29 schrieb Mikolaj Izdebski <mizde...@redhat.com>:
> >
> > On Mon, Oct 4, 2021 at 2:08 PM Peter Boy <p...@uni-bremen.de> wrote:
> >> However, we lack concepts on how to proceed after removing java-maint-sig.
> >> What consequences do we draw from the analyses?
> >
> > β¦ If you want
> > to improve docs, just do it. And so on. ...
> > ... or to plan editing the wiki. Whoever wants to clean up some wiki
> > pages can simply do so, without asking.
>
> Itβs not as easy as you think of. That way you will end with the docs as
> Stephen Smoogen described 4 posts back, just chaos and misinformation. You
> need collaboration and agreement (shared plan) from participants in all
> affected areas - including you as the (main) developer of a core package (not
> writing text, but e.g check the concept, check technical correctness and
> completeness). It simply doesnβt work the way you are proposing.
Sure, some major changes may indeed require planning or cooperation.
That's what we have the SIG and its communication channels for. For
example, if I wanted to rewrite Java documentation and move it from
the wiki to docs.fedoraproject.org at the same time, I would start
with sending a proposal to java-devel mailing list and ask for
feedback. We would discuss what should and what should not be
documented, who wants to document what and so on. Depending on how the
discussion goes there, I might propose an IRC meeting to ease the
discussion process.
>
>
> >> I posted on the java list some ideas some time ago ('Empowering Fedora
> >> Javaβ). Any comments on those?
> >
> > These were about java-maint-sig, IIRC, which basically does not exist
> > any longer.
>
> No! It was about:
> > The biggest success is that with all the adversities in java packaging we
> > have a stabilized Fedora Java core platform.
I'll re-read it then and try to reply.
> >
> > The next urgent step, in my opinion, is to update and improve information
> > materials and documentation, followed by a community building process based
> > on it.
> >
> >
> > I can offer to do the writing. β¦
> followed by tentative ideas about details of documentation.
>
> You wrote:
> > Java SIG has resources in form
> > of communication channels that can be used by members to help each
> > other. There is a mailing list and an IRC channel.
> So much for the theory, yes. I would have appreciated even a tiny bit of it.
I don't understand. These communication channels exist and are
functional. The most active Java packagers I know of are subscribed to
the mailing list and are present in the IRC channel. The fact that
there is not much ongoing communication is a different problem - I
find that people very often approach me directly or through other
channels, and many times I ask them to use public Java SIG channels
because that allows others to benefit from the conversation.
> You are one of the developers without whose contributions the Fedora Java
> stack would probably collapse in a short time. I would really be interested
> in the same question as to Mat: With java-paint-sig removed, are you really
> completely content with the Fedora Java world? No change? No improvement
> anywhere?
I'm happy with how Java SIG works in general - as an informal group
that does not limit packagers freedom, like by enforcing agile
processes, or mandating code review for every change. I like that Java
SIG doesn't have any authority to make any decisions - there can be
discussion, but ultimately each package owner makes decisions
regarding their own packages, within boundaries defined by Fedora
policies. The Fedora change process can be used when required - anyone
can propose a change, and once approved by FESCo, the package owner
must obey. I like that unmaintained packages are being removed from
distribution - with decreasing manpower in Java SIG I think it's
better to focus on fewer important packages.
For sure we should clean outdated Java SIG wiki pages - that's
relatively simple and I can do that myself. We should pay better
attention to announcing important changes that can affect others. We
can try regular IRC meetings instead of ad-hoc meetings. We could try
to come up with common goals for the SIG, but I'm not sure if that
will help. Right now I don't have any other ideas regarding improving
Java SIG organization.
Regarding Java content in Fedora Linux, there is a lot to improve, and
I have many ideas. I started writing them down as they come to my mind
and for each of them I'll start separate threads on java-devel list.
I also promise to document ongoing or planned projects that I am or
would like to be working on. Then anyone interested will be able to
more easily see what is going on, and possibly help with these
projects. Some of the projects that I have in mind:
Ongoing:
- MBI (Maven Bootstrap Initiative, an ability to build Maven and XMvn
fully from source from scratch, without reliance on pre-existing
binaries),
- Maven JDK bindings (ability to choose version of JDK used by Maven
at installation time),
- XMvn toolchains (ability to switch JDK used to build packages by
changing a single line of BuildRequires),
- embedded metadata for security scanners inside JARs (to reduce the
number of false-positives the scanners report),
- downstream patch tracking (similar to Debian DEP-3),
- updating Java packaging docs and moving them to docs.fedoraproject.org.
Planned or considered:
- redesign of auto-requires on JRE packages (bug 1993879),
- adding simple functional tests (smoke tests) for various packages,
- running upstream tests as gating tests (that allows running tests
that can't be ran during rpmbuild due to unpackaged dependencies),
- making use of gating and CI infrastructure to run generic Java tests
(that enforce packaging guidelines and bytecode version),
- browsable API documentation (javadocs extracted from RPMs and served
on a website),
- bringing back java-deptools (search engine for Java classes within
RPM packages that I used to host),
- updating Java Packaging HOWTO (writing missing sections, removing or
rewriting outdated parts).
> And just in case you see some preferable improvement anywhere, what do you
> think should be done to promote and achieve this?
I have no idea, other than doing the work myself and communicating
what I'm doing and why, hoping others will join the effort. I'm not
the best person to ask about promotion or community building.
--
Mikolaj Izdebski
>
>
>
> Best
> Peter
>
>
>
>
> _______________________________________________
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
_______________________________________________
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
