12:09 p.m.
TL;DR I am planning to orphan Java packages listed below soon after
Fedora 29 GA. Let me know if you want to adopt any of them.
I'm in the process of transitioning maintenance of all software to
modules only. The reason is that module maintenance is much easier
compared to maintenance of non-modular, "ursine" packages. Starting from
Fedora 29 modules are first-class citizens, so I am finally able to
orphan ursine packages that are already available in modules.
Ideally these packages should be retired instead of orphaning them, but
these packages are build-required by a lot of other things.
Unfortunately as of today modules can't be used as build-requires of
ursine packages and I'm not aware of any plans to change that. Therefore
I will let interested parties take maintenance of orphaned packages, or
else let release engineering figure out how to retire them without
breaking the whole distro.
I decided to start with the following subset of ursine packages for
which I am listed as PoC. Until Fedora 29 GA I will be providing all
updates and fixes to these packages in all active +*release branches.
After Fedora 29 GA I will orphan these packages, but I will keep
providing important bugfixes for Fedora 27 and Fedora 28. After Fedora
28 EOL I will not maintain these packages in release (non-arbitrary)
branches at all - I will maintain only corresponding modules.
If you want to adopt any of these packages, please let me know and I
will happily transfer them to you.
Packages orphan:
ant
ant-contrib
aopalliance
apache-commons-beanutils
apache-commons-collections
apache-commons-compress
apache-commons-io
apache-commons-jxpath
apache-commons-lang
apache-commons-lang3
apache-commons-logging
apache-commons-net
apache-ivy
apache-parent
apache-resource-bundles
aqute-bnd
atinject
bcel
beust-jcommander
bsf
bsh
byaccj
cal10n
easymock
exec-maven-plugin
felix-osgi-core
felix-utils
geronimo-jms
geronimo-jpa
geronimo-parent-poms
glassfish-jsp-api
google-guice
guava20
hawtjni
httpcomponents-client
httpcomponents-core
httpcomponents-project
jakarta-commons-httpclient
jansi
jansi-native
javacc
javacc-maven-plugin
javamail
javapackages-tools
javassist
jaxen
jdepend
jdependency
jflex
jsoup
junit
jvnet-parent
maven
maven-antrun-plugin
maven-archiver
maven-artifact-resolver
maven-artifact-transfer
maven-assembly-plugin
maven-clean-plugin
maven-compiler-plugin
maven-dependency-analyzer
maven-dependency-plugin
maven-dependency-tree
maven-doxia
maven-doxia-sitetools
maven-enforcer
maven-file-management
maven-filtering
maven-invoker
maven-jar-plugin
maven-parent
maven-plugin-build-helper
maven-plugin-bundle
maven-plugins-pom
maven-plugin-testing
maven-plugin-tools
maven-reporting-api
maven-reporting-impl
maven-resolver
maven-script-interpreter
maven-shade-plugin
maven-shared-incremental
maven-shared-io
maven-shared-utils
maven-source-plugin
maven-surefire
maven-verifier
maven-wagon
modello
mojo-parent
munge-maven-plugin
objectweb-pom
osgi-compendium
osgi-core
os-maven-plugin
plexus-ant-factory
plexus-archiver
plexus-bsh-factory
plexus-classworlds
plexus-cli
plexus-compiler
plexus-component-factories-pom
plexus-components-pom
plexus-containers
plexus-i18n
plexus-interactivity
plexus-interpolation
plexus-io
plexus-languages
plexus-resources
plexus-utils
plexus-velocity
qdox
regexp
sisu
sisu-mojos
slf4j
sonatype-oss-parent
sonatype-plugins-parent
velocity
xalan-j2
xbean
xmvn
xz-java
Maintainers by package:
ant akurtakov jcapik kdaniel mizdebsk msrb
ant-contrib davidcl mizdebsk
aopalliance mizdebsk
apache-commons-beanutils fnasser mizdebsk spike
apache-commons-collections jcapik mizdebsk
apache-commons-compress mizdebsk spike
apache-commons-io mizdebsk spike
apache-commons-jxpath fnasser mizdebsk spike
apache-commons-lang mizdebsk spike
apache-commons-lang3 mizdebsk
apache-commons-logging kdaniel mizdebsk spike
apache-commons-net mizdebsk spike
apache-ivy mizdebsk
apache-parent mizdebsk
apache-resource-bundles mizdebsk
aqute-bnd jcapik mizdebsk
atinject kdaniel mizdebsk
bcel mizdebsk
beust-jcommander jcapik mizdebsk
bsf choeger mizdebsk
bsh mizdebsk
byaccj akurtakov dbhole mizdebsk
cal10n mizdebsk
easymock akurtakov ctubbsii dbhole fnasser mizdebsk
exec-maven-plugin mizdebsk
felix-osgi-core jcapik mizdebsk
felix-utils jcapik mizdebsk
geronimo-jms mizdebsk
geronimo-jpa lef mizdebsk
geronimo-parent-poms mizdebsk
glassfish-jsp-api kdaniel mizdebsk
google-guice mizdebsk
guava20 mizdebsk
hawtjni gil goldmann mizdebsk
httpcomponents-client jerboaa kdaniel mizdebsk
httpcomponents-core jerboaa kdaniel mizdebsk
httpcomponents-project mizdebsk
jakarta-commons-httpclient dbhole ke4qqq mizdebsk
jansi goldmann mizdebsk
jansi-native goldmann mizdebsk
javacc jcapik mizdebsk
javacc-maven-plugin jcapik mizdebsk
javamail mizdebsk
javapackages-tools mizdebsk msrb
javassist john5342 mizdebsk
jaxen mizdebsk
jdepend goldmann jcapik mizdebsk
jdependency mizdebsk
jflex jcapik mizdebsk
jsoup jcapik mizdebsk
junit kdaniel mizdebsk
jvnet-parent mizdebsk
maven akurtakov jamielinux mizdebsk msrb
maven-antrun-plugin mizdebsk
maven-archiver akurtakov mizdebsk
maven-artifact-resolver mizdebsk
maven-artifact-transfer mizdebsk
maven-assembly-plugin gil huwang jcapik mizdebsk
maven-clean-plugin mizdebsk
maven-compiler-plugin mizdebsk
maven-dependency-analyzer mizdebsk
maven-dependency-plugin mizdebsk
maven-dependency-tree mizdebsk
maven-doxia akurtakov mef mizdebsk
maven-doxia-sitetools akurtakov dbhole mizdebsk
maven-enforcer jcapik mizdebsk
maven-file-management mizdebsk
maven-filtering mizdebsk
maven-invoker mizdebsk
maven-jar-plugin mizdebsk
maven-parent mizdebsk
maven-plugin-build-helper mizdebsk
maven-plugin-bundle jcapik mizdebsk
maven-plugin-testing jcapik mizdebsk yyang
maven-plugin-tools jcapik mizdebsk yyang
maven-plugins-pom mizdebsk
maven-reporting-api mizdebsk
maven-reporting-impl mizdebsk
maven-resolver mizdebsk
maven-script-interpreter mizdebsk
maven-shade-plugin jcapik mizdebsk pingou
maven-shared-incremental mizdebsk
maven-shared-io mizdebsk
maven-shared-utils mizdebsk
maven-source-plugin mizdebsk
maven-surefire akurtakov jcapik mizdebsk
maven-verifier mizdebsk
maven-wagon akurtakov dbhole fnasser jcapik mizdebsk yyang
modello fnasser mizdebsk yyang
mojo-parent mizdebsk
munge-maven-plugin mizdebsk
objectweb-pom mizdebsk
os-maven-plugin ctubbsii mizdebsk
osgi-compendium mizdebsk
osgi-core mizdebsk
plexus-ant-factory mizdebsk
plexus-archiver dbhole jcapik mizdebsk
plexus-bsh-factory mizdebsk
plexus-classworlds dbhole fnasser mizdebsk
plexus-cli mizdebsk
plexus-compiler mizdebsk
plexus-component-factories-pom mizdebsk
plexus-components-pom mizdebsk
plexus-containers dbhole fnasser mizdebsk yyang
plexus-i18n dbhole jcapik mizdebsk
plexus-interactivity mizdebsk
plexus-interpolation gil jcapik mizdebsk
plexus-io jcapik mizdebsk
plexus-languages mizdebsk
plexus-resources jcapik mizdebsk
plexus-utils fnasser mizdebsk
plexus-velocity jcapik mizdebsk
qdox mizdebsk
regexp mizdebsk
sisu mizdebsk
sisu-mojos mizdebsk
slf4j mizdebsk
sonatype-oss-parent mizdebsk
sonatype-plugins-parent mizdebsk
velocity devrim mizdebsk
xalan-j2 kdaniel mizdebsk
xbean kdaniel mizdebsk
xmvn mizdebsk msrb
xz-java kdaniel mizdebsk
Packages by maintainer:
akurtakov ant byaccj easymock maven maven-archiver maven-doxia
maven-doxia-sitetools maven-surefire maven-wagon
choeger bsf
ctubbsii easymock os-maven-plugin
davidcl ant-contrib
dbhole byaccj easymock jakarta-commons-httpclient
maven-doxia-sitetools maven-wagon plexus-archiver plexus-classworlds
plexus-containers plexus-i18n
devrim velocity
fnasser apache-commons-beanutils apache-commons-jxpath easymock
maven-wagon modello plexus-classworlds plexus-containers plexus-utils
gil hawtjni maven-assembly-plugin plexus-interpolation
goldmann hawtjni jansi jansi-native jdepend
huwang maven-assembly-plugin
jamielinux maven
jcapik ant apache-commons-collections aqute-bnd beust-jcommander
felix-osgi-core felix-utils javacc javacc-maven-plugin jdepend jflex
jsoup maven-assembly-plugin maven-enforcer maven-plugin-bundle
maven-plugin-testing maven-plugin-tools maven-shade-plugin
maven-surefire maven-wagon plexus-archiver plexus-i18n
plexus-interpolation plexus-io plexus-resources plexus-velocity
jerboaa httpcomponents-client httpcomponents-core
john5342 javassist
kdaniel ant apache-commons-logging atinject glassfish-jsp-api
httpcomponents-client httpcomponents-core junit xalan-j2 xbean xz-java
ke4qqq jakarta-commons-httpclient
lef geronimo-jpa
mef maven-doxia
mizdebsk ant ant-contrib aopalliance apache-commons-beanutils
apache-commons-collections apache-commons-compress apache-commons-io
apache-commons-jxpath apache-commons-lang apache-commons-lang3
apache-commons-logging apache-commons-net apache-ivy apache-parent
apache-resource-bundles aqute-bnd atinject bcel beust-jcommander bsf bsh
byaccj cal10n easymock exec-maven-plugin felix-osgi-core felix-utils
geronimo-jms geronimo-jpa geronimo-parent-poms glassfish-jsp-api
google-guice guava20 hawtjni httpcomponents-client httpcomponents-core
httpcomponents-project jakarta-commons-httpclient jansi jansi-native
javacc javacc-maven-plugin javamail javapackages-tools javassist jaxen
jdepend jdependency jflex jsoup junit jvnet-parent maven
maven-antrun-plugin maven-archiver maven-artifact-resolver
maven-artifact-transfer maven-assembly-plugin maven-clean-plugin
maven-compiler-plugin maven-dependency-analyzer maven-dependency-plugin
maven-dependency-tree maven-doxia maven-doxia-sitetools maven-enforcer
maven-file-management maven-filtering maven-invoker maven-jar-plugin
maven-parent maven-plugin-build-helper maven-plugin-bundle
maven-plugin-testing maven-plugin-tools maven-plugins-pom
maven-reporting-api maven-reporting-impl maven-resolver
maven-script-interpreter maven-shade-plugin maven-shared-incremental
maven-shared-io maven-shared-utils maven-source-plugin maven-surefire
maven-verifier maven-wagon modello mojo-parent munge-maven-plugin
objectweb-pom os-maven-plugin osgi-compendium osgi-core
plexus-ant-factory plexus-archiver plexus-bsh-factory plexus-classworlds
plexus-cli plexus-compiler plexus-component-factories-pom
plexus-components-pom plexus-containers plexus-i18n plexus-interactivity
plexus-interpolation plexus-io plexus-languages plexus-resources
plexus-utils plexus-velocity qdox regexp sisu sisu-mojos slf4j
sonatype-oss-parent sonatype-plugins-parent velocity xalan-j2 xbean xmvn
xz-java
msrb ant javapackages-tools maven xmvn
pingou maven-shade-plugin
spike apache-commons-beanutils apache-commons-compress
apache-commons-io apache-commons-jxpath apache-commons-lang
apache-commons-logging apache-commons-net
yyang maven-plugin-testing maven-plugin-tools maven-wagon modello
plexus-containers
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
2:39 p.m.
On 09/24/2018 08:52 PM, Miro Hrončok wrote:
On 24.9.2018 19:09, Mikolaj Izdebski wrote:
> I'm in the process of transitioning maintenance of all software to
> modules only. The reason is that module maintenance is much easier
> compared to maintenance of non-modular, "ursine" packages.
>
> Ideally these packages should be retired instead of orphaning them, but
> these packages are build-required by a lot of other things.
This is an interesting situation. If more maintainers will decide to do
this, we can easily break everything and only have modules, except we
will no longer have any system to have those modules run on.
(I'm not saying you shouldn't do this; I'm just really concerned if
modularity is actually helping Fedora as a whole or if it will
eventually break it entirely.)
I was hoping for a solution like "ursa-major" described in [1], that
would allow modules to be used as build-dependencies for non-modular
packages. This would allow properly retiring non-modular packages and
maintaining only modules, which would be also used as build dependencies
for non-modular packages. But it seems that currently no one is
interested in implementing such solution.
Java SIG is dying slowly, this package set recently lost another
co-maintainer and I don't have time to maintain all these packages by
myself. Switching to module-only content is probably the best move to
keep high-quality software delivered to our users and reduce maintenance
work at the same time.
[1]
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
4:25 p.m.
On Mon, Sep 24, 2018 at 3:39 PM, Mikolaj Izdebski <mizdebsk(a)redhat.com> wrote:
On 09/24/2018 08:52 PM, Miro Hrončok wrote:
> On 24.9.2018 19:09, Mikolaj Izdebski wrote:
>> I'm in the process of transitioning maintenance of all software to
>> modules only. The reason is that module maintenance is much easier
>> compared to maintenance of non-modular, "ursine" packages.
>>
>> Ideally these packages should be retired instead of orphaning them, but
>> these packages are build-required by a lot of other things.
> This is an interesting situation. If more maintainers will decide to do
> this, we can easily break everything and only have modules, except we
> will no longer have any system to have those modules run on.
>
> (I'm not saying you shouldn't do this; I'm just really concerned if
> modularity is actually helping Fedora as a whole or if it will
> eventually break it entirely.)
I was hoping for a solution like "ursa-major" described in [1], that
would allow modules to be used as build-dependencies for non-modular
packages. This would allow properly retiring non-modular packages and
maintaining only modules, which would be also used as build dependencies
for non-modular packages. But it seems that currently no one is
interested in implementing such solution.
Java SIG is dying slowly, this package set recently lost another
co-maintainer and I don't have time to maintain all these packages by
myself. Switching to module-only content is probably the best move to
keep high-quality software delivered to our users and reduce maintenance
work at the same time.
[1]
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
This is something that worried me also when I read this message.
Are modules only intended for leaf packages at the moment? I admit
that I have not really been keeping up to date with modularity. Or is
the intended workflow that (eventually) everything's a module, and so
if something needs to depend on a module, it too must be inside a
module for this to work?
This seems like it could become a problem, because I imagine that
there are lots of leaf packages out there that aren't in modules, or
don't necessarily need to be in modules-- unless parts of the
distribution start becoming module-only.
(Maybe this discussion belongs in a new thread, but I think it's important).
Ben Rosser
9:17 p.m.
Mikolaj Izdebski wrote:
I'm in the process of transitioning maintenance of all software
to
modules only. The reason is that module maintenance is much easier
compared to maintenance of non-modular, "ursine" packages. Starting from
Fedora 29 modules are first-class citizens, so I am finally able to
orphan ursine packages that are already available in modules.
This is exactly what I feared when the modules were first proposed:
essential packages moving to modules only.
I think this is absolutely a step in the wrong direction. Things like "ant"
are essential parts of a distribution. They cannot sit in some module with
arbitrary branches that can be EOLed at any time.
Kevin Kofler
1:01 a.m.
> Mikolaj Izdebski wrote:
>
> This is exactly what I feared when the modules were first proposed:
> essential packages moving to modules only.
>
> I think this is absolutely a step in the wrong direction. Things like "ant"
> are essential parts of a distribution. They cannot sit in some module with
> arbitrary branches that can be EOLed at any time.
>
> Kevin Kofler
As far as I can understand the modules idea and while looking into those yaml files of ant
and cmake for instance, I fail see why modules should work without any spec file and
therefore also why without rpmbuild. The modules idea seems to be more about how to have a
possibility to build a bunch of packages in their own dependency tree for a custom branch
(and on which base system that branch should ever work). So in my opinion, modules can
never work without any base system built completely from without modules.
What I like about modules is that it obsoletes the need to check for the target
distribution inside of the spec file (that's now handled with a branch in git). What I
don't like is that all dependencies have to get repeated in the yaml file. What real
problem do we try to solve?
Please calm down and just my 5ct.
8:57 a.m.
On 24.9.2018 19:09, Mikolaj Izdebski wrote:
I'm in the process of transitioning maintenance of all software
to
modules only. The reason is that module maintenance is much easier
compared to maintenance of non-modular, "ursine" packages.
Ideally these packages should be retired instead of orphaning them, but
these packages are build-required by a lot of other things.
This is an interesting
situation. If more maintainers will decide to do
this, we can easily break everything and only have modules, except we
will no longer have any system to have those modules run on.
(I'm not saying you shouldn't do this; I'm just really concerned if
modularity is actually helping Fedora as a whole or if it will
eventually break it entirely.)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:01 a.m.
I have a question about this because I don't fully understand modularity.
If these packages are retired, how will maintainers get them installed from
their respective modules in order to build their own packages, and how will
users get the appropriate modules installed to satisfy dependencies? Or is
it the case that no F30 packages will be able to depend on them at all?
On Mon, Sep 24, 2018, 13:11 Mikolaj Izdebski <mizdebsk(a)redhat.com> wrote:
TL;DR I am planning to orphan Java packages listed below soon after
Fedora 29 GA. Let me know if you want to adopt any of them.
I'm in the process of transitioning maintenance of all software to
modules only. The reason is that module maintenance is much easier
compared to maintenance of non-modular, "ursine" packages. Starting from
Fedora 29 modules are first-class citizens, so I am finally able to
orphan ursine packages that are already available in modules.
Ideally these packages should be retired instead of orphaning them, but
these packages are build-required by a lot of other things.
Unfortunately as of today modules can't be used as build-requires of
ursine packages and I'm not aware of any plans to change that. Therefore
I will let interested parties take maintenance of orphaned packages, or
else let release engineering figure out how to retire them without
breaking the whole distro.
I decided to start with the following subset of ursine packages for
which I am listed as PoC. Until Fedora 29 GA I will be providing all
updates and fixes to these packages in all active +*release branches.
After Fedora 29 GA I will orphan these packages, but I will keep
providing important bugfixes for Fedora 27 and Fedora 28. After Fedora
28 EOL I will not maintain these packages in release (non-arbitrary)
branches at all - I will maintain only corresponding modules.
If you want to adopt any of these packages, please let me know and I
will happily transfer them to you.
Packages orphan:
ant
ant-contrib
aopalliance
apache-commons-beanutils
apache-commons-collections
apache-commons-compress
apache-commons-io
apache-commons-jxpath
apache-commons-lang
apache-commons-lang3
apache-commons-logging
apache-commons-net
apache-ivy
apache-parent
apache-resource-bundles
aqute-bnd
atinject
bcel
beust-jcommander
bsf
bsh
byaccj
cal10n
easymock
exec-maven-plugin
felix-osgi-core
felix-utils
geronimo-jms
geronimo-jpa
geronimo-parent-poms
glassfish-jsp-api
google-guice
guava20
hawtjni
httpcomponents-client
httpcomponents-core
httpcomponents-project
jakarta-commons-httpclient
jansi
jansi-native
javacc
javacc-maven-plugin
javamail
javapackages-tools
javassist
jaxen
jdepend
jdependency
jflex
jsoup
junit
jvnet-parent
maven
maven-antrun-plugin
maven-archiver
maven-artifact-resolver
maven-artifact-transfer
maven-assembly-plugin
maven-clean-plugin
maven-compiler-plugin
maven-dependency-analyzer
maven-dependency-plugin
maven-dependency-tree
maven-doxia
maven-doxia-sitetools
maven-enforcer
maven-file-management
maven-filtering
maven-invoker
maven-jar-plugin
maven-parent
maven-plugin-build-helper
maven-plugin-bundle
maven-plugins-pom
maven-plugin-testing
maven-plugin-tools
maven-reporting-api
maven-reporting-impl
maven-resolver
maven-script-interpreter
maven-shade-plugin
maven-shared-incremental
maven-shared-io
maven-shared-utils
maven-source-plugin
maven-surefire
maven-verifier
maven-wagon
modello
mojo-parent
munge-maven-plugin
objectweb-pom
osgi-compendium
osgi-core
os-maven-plugin
plexus-ant-factory
plexus-archiver
plexus-bsh-factory
plexus-classworlds
plexus-cli
plexus-compiler
plexus-component-factories-pom
plexus-components-pom
plexus-containers
plexus-i18n
plexus-interactivity
plexus-interpolation
plexus-io
plexus-languages
plexus-resources
plexus-utils
plexus-velocity
qdox
regexp
sisu
sisu-mojos
slf4j
sonatype-oss-parent
sonatype-plugins-parent
velocity
xalan-j2
xbean
xmvn
xz-java
Maintainers by package:
ant akurtakov jcapik kdaniel mizdebsk msrb
ant-contrib davidcl mizdebsk
aopalliance mizdebsk
apache-commons-beanutils fnasser mizdebsk spike
apache-commons-collections jcapik mizdebsk
apache-commons-compress mizdebsk spike
apache-commons-io mizdebsk spike
apache-commons-jxpath fnasser mizdebsk spike
apache-commons-lang mizdebsk spike
apache-commons-lang3 mizdebsk
apache-commons-logging kdaniel mizdebsk spike
apache-commons-net mizdebsk spike
apache-ivy mizdebsk
apache-parent mizdebsk
apache-resource-bundles mizdebsk
aqute-bnd jcapik mizdebsk
atinject kdaniel mizdebsk
bcel mizdebsk
beust-jcommander jcapik mizdebsk
bsf choeger mizdebsk
bsh mizdebsk
byaccj akurtakov dbhole mizdebsk
cal10n mizdebsk
easymock akurtakov ctubbsii dbhole fnasser mizdebsk
exec-maven-plugin mizdebsk
felix-osgi-core jcapik mizdebsk
felix-utils jcapik mizdebsk
geronimo-jms mizdebsk
geronimo-jpa lef mizdebsk
geronimo-parent-poms mizdebsk
glassfish-jsp-api kdaniel mizdebsk
google-guice mizdebsk
guava20 mizdebsk
hawtjni gil goldmann mizdebsk
httpcomponents-client jerboaa kdaniel mizdebsk
httpcomponents-core jerboaa kdaniel mizdebsk
httpcomponents-project mizdebsk
jakarta-commons-httpclient dbhole ke4qqq mizdebsk
jansi goldmann mizdebsk
jansi-native goldmann mizdebsk
javacc jcapik mizdebsk
javacc-maven-plugin jcapik mizdebsk
javamail mizdebsk
javapackages-tools mizdebsk msrb
javassist john5342 mizdebsk
jaxen mizdebsk
jdepend goldmann jcapik mizdebsk
jdependency mizdebsk
jflex jcapik mizdebsk
jsoup jcapik mizdebsk
junit kdaniel mizdebsk
jvnet-parent mizdebsk
maven akurtakov jamielinux mizdebsk msrb
maven-antrun-plugin mizdebsk
maven-archiver akurtakov mizdebsk
maven-artifact-resolver mizdebsk
maven-artifact-transfer mizdebsk
maven-assembly-plugin gil huwang jcapik mizdebsk
maven-clean-plugin mizdebsk
maven-compiler-plugin mizdebsk
maven-dependency-analyzer mizdebsk
maven-dependency-plugin mizdebsk
maven-dependency-tree mizdebsk
maven-doxia akurtakov mef mizdebsk
maven-doxia-sitetools akurtakov dbhole mizdebsk
maven-enforcer jcapik mizdebsk
maven-file-management mizdebsk
maven-filtering mizdebsk
maven-invoker mizdebsk
maven-jar-plugin mizdebsk
maven-parent mizdebsk
maven-plugin-build-helper mizdebsk
maven-plugin-bundle jcapik mizdebsk
maven-plugin-testing jcapik mizdebsk yyang
maven-plugin-tools jcapik mizdebsk yyang
maven-plugins-pom mizdebsk
maven-reporting-api mizdebsk
maven-reporting-impl mizdebsk
maven-resolver mizdebsk
maven-script-interpreter mizdebsk
maven-shade-plugin jcapik mizdebsk pingou
maven-shared-incremental mizdebsk
maven-shared-io mizdebsk
maven-shared-utils mizdebsk
maven-source-plugin mizdebsk
maven-surefire akurtakov jcapik mizdebsk
maven-verifier mizdebsk
maven-wagon akurtakov dbhole fnasser jcapik mizdebsk yyang
modello fnasser mizdebsk yyang
mojo-parent mizdebsk
munge-maven-plugin mizdebsk
objectweb-pom mizdebsk
os-maven-plugin ctubbsii mizdebsk
osgi-compendium mizdebsk
osgi-core mizdebsk
plexus-ant-factory mizdebsk
plexus-archiver dbhole jcapik mizdebsk
plexus-bsh-factory mizdebsk
plexus-classworlds dbhole fnasser mizdebsk
plexus-cli mizdebsk
plexus-compiler mizdebsk
plexus-component-factories-pom mizdebsk
plexus-components-pom mizdebsk
plexus-containers dbhole fnasser mizdebsk yyang
plexus-i18n dbhole jcapik mizdebsk
plexus-interactivity mizdebsk
plexus-interpolation gil jcapik mizdebsk
plexus-io jcapik mizdebsk
plexus-languages mizdebsk
plexus-resources jcapik mizdebsk
plexus-utils fnasser mizdebsk
plexus-velocity jcapik mizdebsk
qdox mizdebsk
regexp mizdebsk
sisu mizdebsk
sisu-mojos mizdebsk
slf4j mizdebsk
sonatype-oss-parent mizdebsk
sonatype-plugins-parent mizdebsk
velocity devrim mizdebsk
xalan-j2 kdaniel mizdebsk
xbean kdaniel mizdebsk
xmvn mizdebsk msrb
xz-java kdaniel mizdebsk
Packages by maintainer:
akurtakov ant byaccj easymock maven maven-archiver maven-doxia
maven-doxia-sitetools maven-surefire maven-wagon
choeger bsf
ctubbsii easymock os-maven-plugin
davidcl ant-contrib
dbhole byaccj easymock jakarta-commons-httpclient
maven-doxia-sitetools maven-wagon plexus-archiver plexus-classworlds
plexus-containers plexus-i18n
devrim velocity
fnasser apache-commons-beanutils apache-commons-jxpath easymock
maven-wagon modello plexus-classworlds plexus-containers plexus-utils
gil hawtjni maven-assembly-plugin plexus-interpolation
goldmann hawtjni jansi jansi-native jdepend
huwang maven-assembly-plugin
jamielinux maven
jcapik ant apache-commons-collections aqute-bnd beust-jcommander
felix-osgi-core felix-utils javacc javacc-maven-plugin jdepend jflex
jsoup maven-assembly-plugin maven-enforcer maven-plugin-bundle
maven-plugin-testing maven-plugin-tools maven-shade-plugin
maven-surefire maven-wagon plexus-archiver plexus-i18n
plexus-interpolation plexus-io plexus-resources plexus-velocity
jerboaa httpcomponents-client httpcomponents-core
john5342 javassist
kdaniel ant apache-commons-logging atinject glassfish-jsp-api
httpcomponents-client httpcomponents-core junit xalan-j2 xbean xz-java
ke4qqq jakarta-commons-httpclient
lef geronimo-jpa
mef maven-doxia
mizdebsk ant ant-contrib aopalliance apache-commons-beanutils
apache-commons-collections apache-commons-compress apache-commons-io
apache-commons-jxpath apache-commons-lang apache-commons-lang3
apache-commons-logging apache-commons-net apache-ivy apache-parent
apache-resource-bundles aqute-bnd atinject bcel beust-jcommander bsf bsh
byaccj cal10n easymock exec-maven-plugin felix-osgi-core felix-utils
geronimo-jms geronimo-jpa geronimo-parent-poms glassfish-jsp-api
google-guice guava20 hawtjni httpcomponents-client httpcomponents-core
httpcomponents-project jakarta-commons-httpclient jansi jansi-native
javacc javacc-maven-plugin javamail javapackages-tools javassist jaxen
jdepend jdependency jflex jsoup junit jvnet-parent maven
maven-antrun-plugin maven-archiver maven-artifact-resolver
maven-artifact-transfer maven-assembly-plugin maven-clean-plugin
maven-compiler-plugin maven-dependency-analyzer maven-dependency-plugin
maven-dependency-tree maven-doxia maven-doxia-sitetools maven-enforcer
maven-file-management maven-filtering maven-invoker maven-jar-plugin
maven-parent maven-plugin-build-helper maven-plugin-bundle
maven-plugin-testing maven-plugin-tools maven-plugins-pom
maven-reporting-api maven-reporting-impl maven-resolver
maven-script-interpreter maven-shade-plugin maven-shared-incremental
maven-shared-io maven-shared-utils maven-source-plugin maven-surefire
maven-verifier maven-wagon modello mojo-parent munge-maven-plugin
objectweb-pom os-maven-plugin osgi-compendium osgi-core
plexus-ant-factory plexus-archiver plexus-bsh-factory plexus-classworlds
plexus-cli plexus-compiler plexus-component-factories-pom
plexus-components-pom plexus-containers plexus-i18n plexus-interactivity
plexus-interpolation plexus-io plexus-languages plexus-resources
plexus-utils plexus-velocity qdox regexp sisu sisu-mojos slf4j
sonatype-oss-parent sonatype-plugins-parent velocity xalan-j2 xbean xmvn
xz-java
msrb ant javapackages-tools maven xmvn
pingou maven-shade-plugin
spike apache-commons-beanutils apache-commons-compress
apache-commons-io apache-commons-jxpath apache-commons-lang
apache-commons-logging apache-commons-net
yyang maven-plugin-testing maven-plugin-tools maven-wagon modello
plexus-containers
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
9:34 a.m.
On Mon, Sep 24, 2018 at 3:39 PM Mikolaj Izdebski <mizdebsk(a)redhat.com> wrote:
Java SIG is dying slowly, this package set recently lost another
co-maintainer and I don't have time to maintain all these packages by
myself. Switching to module-only content is probably the best move to
keep high-quality software delivered to our users and reduce maintenance
work at the same time.
Have you done *anything* to try to reinvigorate the Java SIG? I've not
seen anything at all about this problem. Do Java folks in the
ecosystem who happen to use RH/Fedora ecosystem stuff know about it?
Are you doing any outreach/advocacy either across the distro ecosystem
or across the Java ecosystem to try to bring interested people in
helping with Java stack work?
With Rust, we elected to try to become part of the Rust ecosystem, and
we've also taken the tack of working with other distributions to be
able to leverage the efforts across distros to make things better. We
are in the process of reviving the Go SIG in a similar manner. There's
no reason Java couldn't too. And unlike Rust and Go, people *need*
Java for both legacy and new things! Java can be exciting and
interesting, but some effort has to be made to "get the word out".
The Python SIG also does a decent job talking about itself and showing
up at Python events to talk about how Fedora loves Python. Do we love
Java too?
--
真実はいつも一つ！/ Always, there's only one truth!
11:36 a.m.
On 09/24/2018 08:32 PM, Christopher wrote:
I have a question about this because I don't fully understand
modularity.
If these packages are retired, how will maintainers get them installed from
their respective modules in order to build their own packages, and how will
users get the appropriate modules installed to satisfy dependencies? Or is
it the case that no F30 packages will be able to depend on them at all?
There are two likely possible scenarios. Which one happens depends
mostly on whether a service like "ursa-major" [1] (or equivalent) is
implemented by release engineering.
1. Without ursa-major:
- orphaned packages won't be auto-retired by releng as too many things
still build-depend on them
- non-modular packages will rot without maintenance, with
provenpackagers occasionally fixing most serious issues
- buildroots and user systems will see different package sets (users
will get maintained packages from modules, buildroots will keep using
old, unmaintained packages)
- users will have to disable modular repos in order to be able to
install old non-modular packages that are used in buildroots
2. With ursa-major:
- packages will be retired by myself
- there will be only one package set - modular
- buildroots will use the same package sets as available to users
- users will be able to install build-dependencies from modular repos
enabled in the system by default
- module-unaware software (such as mock) will be able to use koji repos
(or new kind of buildroot compose) to install packages from
[1] https://pagure.io/releng/issue/7840
On Mon, Sep 24, 2018, 13:11 Mikolaj Izdebski <mizdebsk(a)redhat.com> wrote:
> TL;DR I am planning to orphan Java packages listed below soon after
> Fedora 29 GA. Let me know if you want to adopt any of them.
>
> I'm in the process of transitioning maintenance of all software to
> modules only. The reason is that module maintenance is much easier
> compared to maintenance of non-modular, "ursine" packages. Starting from
> Fedora 29 modules are first-class citizens, so I am finally able to
> orphan ursine packages that are already available in modules.
>
> Ideally these packages should be retired instead of orphaning them, but
> these packages are build-required by a lot of other things.
> Unfortunately as of today modules can't be used as build-requires of
> ursine packages and I'm not aware of any plans to change that. Therefore
> I will let interested parties take maintenance of orphaned packages, or
> else let release engineering figure out how to retire them without
> breaking the whole distro.
>
> I decided to start with the following subset of ursine packages for
> which I am listed as PoC. Until Fedora 29 GA I will be providing all
> updates and fixes to these packages in all active +*release branches.
> After Fedora 29 GA I will orphan these packages, but I will keep
> providing important bugfixes for Fedora 27 and Fedora 28. After Fedora
> 28 EOL I will not maintain these packages in release (non-arbitrary)
> branches at all - I will maintain only corresponding modules.
>
> If you want to adopt any of these packages, please let me know and I
> will happily transfer them to you.
>
>
> Packages orphan:
> ant
> ant-contrib
> aopalliance
> apache-commons-beanutils
> apache-commons-collections
> apache-commons-compress
> apache-commons-io
> apache-commons-jxpath
> apache-commons-lang
> apache-commons-lang3
> apache-commons-logging
> apache-commons-net
> apache-ivy
> apache-parent
> apache-resource-bundles
> aqute-bnd
> atinject
> bcel
> beust-jcommander
> bsf
> bsh
> byaccj
> cal10n
> easymock
> exec-maven-plugin
> felix-osgi-core
> felix-utils
> geronimo-jms
> geronimo-jpa
> geronimo-parent-poms
> glassfish-jsp-api
> google-guice
> guava20
> hawtjni
> httpcomponents-client
> httpcomponents-core
> httpcomponents-project
> jakarta-commons-httpclient
> jansi
> jansi-native
> javacc
> javacc-maven-plugin
> javamail
> javapackages-tools
> javassist
> jaxen
> jdepend
> jdependency
> jflex
> jsoup
> junit
> jvnet-parent
> maven
> maven-antrun-plugin
> maven-archiver
> maven-artifact-resolver
> maven-artifact-transfer
> maven-assembly-plugin
> maven-clean-plugin
> maven-compiler-plugin
> maven-dependency-analyzer
> maven-dependency-plugin
> maven-dependency-tree
> maven-doxia
> maven-doxia-sitetools
> maven-enforcer
> maven-file-management
> maven-filtering
> maven-invoker
> maven-jar-plugin
> maven-parent
> maven-plugin-build-helper
> maven-plugin-bundle
> maven-plugins-pom
> maven-plugin-testing
> maven-plugin-tools
> maven-reporting-api
> maven-reporting-impl
> maven-resolver
> maven-script-interpreter
> maven-shade-plugin
> maven-shared-incremental
> maven-shared-io
> maven-shared-utils
> maven-source-plugin
> maven-surefire
> maven-verifier
> maven-wagon
> modello
> mojo-parent
> munge-maven-plugin
> objectweb-pom
> osgi-compendium
> osgi-core
> os-maven-plugin
> plexus-ant-factory
> plexus-archiver
> plexus-bsh-factory
> plexus-classworlds
> plexus-cli
> plexus-compiler
> plexus-component-factories-pom
> plexus-components-pom
> plexus-containers
> plexus-i18n
> plexus-interactivity
> plexus-interpolation
> plexus-io
> plexus-languages
> plexus-resources
> plexus-utils
> plexus-velocity
> qdox
> regexp
> sisu
> sisu-mojos
> slf4j
> sonatype-oss-parent
> sonatype-plugins-parent
> velocity
> xalan-j2
> xbean
> xmvn
> xz-java
>
> Maintainers by package:
> ant akurtakov jcapik kdaniel mizdebsk msrb
> ant-contrib davidcl mizdebsk
> aopalliance mizdebsk
> apache-commons-beanutils fnasser mizdebsk spike
> apache-commons-collections jcapik mizdebsk
> apache-commons-compress mizdebsk spike
> apache-commons-io mizdebsk spike
> apache-commons-jxpath fnasser mizdebsk spike
> apache-commons-lang mizdebsk spike
> apache-commons-lang3 mizdebsk
> apache-commons-logging kdaniel mizdebsk spike
> apache-commons-net mizdebsk spike
> apache-ivy mizdebsk
> apache-parent mizdebsk
> apache-resource-bundles mizdebsk
> aqute-bnd jcapik mizdebsk
> atinject kdaniel mizdebsk
> bcel mizdebsk
> beust-jcommander jcapik mizdebsk
> bsf choeger mizdebsk
> bsh mizdebsk
> byaccj akurtakov dbhole mizdebsk
> cal10n mizdebsk
> easymock akurtakov ctubbsii dbhole fnasser mizdebsk
> exec-maven-plugin mizdebsk
> felix-osgi-core jcapik mizdebsk
> felix-utils jcapik mizdebsk
> geronimo-jms mizdebsk
> geronimo-jpa lef mizdebsk
> geronimo-parent-poms mizdebsk
> glassfish-jsp-api kdaniel mizdebsk
> google-guice mizdebsk
> guava20 mizdebsk
> hawtjni gil goldmann mizdebsk
> httpcomponents-client jerboaa kdaniel mizdebsk
> httpcomponents-core jerboaa kdaniel mizdebsk
> httpcomponents-project mizdebsk
> jakarta-commons-httpclient dbhole ke4qqq mizdebsk
> jansi goldmann mizdebsk
> jansi-native goldmann mizdebsk
> javacc jcapik mizdebsk
> javacc-maven-plugin jcapik mizdebsk
> javamail mizdebsk
> javapackages-tools mizdebsk msrb
> javassist john5342 mizdebsk
> jaxen mizdebsk
> jdepend goldmann jcapik mizdebsk
> jdependency mizdebsk
> jflex jcapik mizdebsk
> jsoup jcapik mizdebsk
> junit kdaniel mizdebsk
> jvnet-parent mizdebsk
> maven akurtakov jamielinux mizdebsk msrb
> maven-antrun-plugin mizdebsk
> maven-archiver akurtakov mizdebsk
> maven-artifact-resolver mizdebsk
> maven-artifact-transfer mizdebsk
> maven-assembly-plugin gil huwang jcapik mizdebsk
> maven-clean-plugin mizdebsk
> maven-compiler-plugin mizdebsk
> maven-dependency-analyzer mizdebsk
> maven-dependency-plugin mizdebsk
> maven-dependency-tree mizdebsk
> maven-doxia akurtakov mef mizdebsk
> maven-doxia-sitetools akurtakov dbhole mizdebsk
> maven-enforcer jcapik mizdebsk
> maven-file-management mizdebsk
> maven-filtering mizdebsk
> maven-invoker mizdebsk
> maven-jar-plugin mizdebsk
> maven-parent mizdebsk
> maven-plugin-build-helper mizdebsk
> maven-plugin-bundle jcapik mizdebsk
> maven-plugin-testing jcapik mizdebsk yyang
> maven-plugin-tools jcapik mizdebsk yyang
> maven-plugins-pom mizdebsk
> maven-reporting-api mizdebsk
> maven-reporting-impl mizdebsk
> maven-resolver mizdebsk
> maven-script-interpreter mizdebsk
> maven-shade-plugin jcapik mizdebsk pingou
> maven-shared-incremental mizdebsk
> maven-shared-io mizdebsk
> maven-shared-utils mizdebsk
> maven-source-plugin mizdebsk
> maven-surefire akurtakov jcapik mizdebsk
> maven-verifier mizdebsk
> maven-wagon akurtakov dbhole fnasser jcapik mizdebsk yyang
> modello fnasser mizdebsk yyang
> mojo-parent mizdebsk
> munge-maven-plugin mizdebsk
> objectweb-pom mizdebsk
> os-maven-plugin ctubbsii mizdebsk
> osgi-compendium mizdebsk
> osgi-core mizdebsk
> plexus-ant-factory mizdebsk
> plexus-archiver dbhole jcapik mizdebsk
> plexus-bsh-factory mizdebsk
> plexus-classworlds dbhole fnasser mizdebsk
> plexus-cli mizdebsk
> plexus-compiler mizdebsk
> plexus-component-factories-pom mizdebsk
> plexus-components-pom mizdebsk
> plexus-containers dbhole fnasser mizdebsk yyang
> plexus-i18n dbhole jcapik mizdebsk
> plexus-interactivity mizdebsk
> plexus-interpolation gil jcapik mizdebsk
> plexus-io jcapik mizdebsk
> plexus-languages mizdebsk
> plexus-resources jcapik mizdebsk
> plexus-utils fnasser mizdebsk
> plexus-velocity jcapik mizdebsk
> qdox mizdebsk
> regexp mizdebsk
> sisu mizdebsk
> sisu-mojos mizdebsk
> slf4j mizdebsk
> sonatype-oss-parent mizdebsk
> sonatype-plugins-parent mizdebsk
> velocity devrim mizdebsk
> xalan-j2 kdaniel mizdebsk
> xbean kdaniel mizdebsk
> xmvn mizdebsk msrb
> xz-java kdaniel mizdebsk
>
> Packages by maintainer:
> akurtakov ant byaccj easymock maven maven-archiver maven-doxia
> maven-doxia-sitetools maven-surefire maven-wagon
> choeger bsf
> ctubbsii easymock os-maven-plugin
> davidcl ant-contrib
> dbhole byaccj easymock jakarta-commons-httpclient
> maven-doxia-sitetools maven-wagon plexus-archiver plexus-classworlds
> plexus-containers plexus-i18n
> devrim velocity
> fnasser apache-commons-beanutils apache-commons-jxpath easymock
> maven-wagon modello plexus-classworlds plexus-containers plexus-utils
> gil hawtjni maven-assembly-plugin plexus-interpolation
> goldmann hawtjni jansi jansi-native jdepend
> huwang maven-assembly-plugin
> jamielinux maven
> jcapik ant apache-commons-collections aqute-bnd beust-jcommander
> felix-osgi-core felix-utils javacc javacc-maven-plugin jdepend jflex
> jsoup maven-assembly-plugin maven-enforcer maven-plugin-bundle
> maven-plugin-testing maven-plugin-tools maven-shade-plugin
> maven-surefire maven-wagon plexus-archiver plexus-i18n
> plexus-interpolation plexus-io plexus-resources plexus-velocity
> jerboaa httpcomponents-client httpcomponents-core
> john5342 javassist
> kdaniel ant apache-commons-logging atinject glassfish-jsp-api
> httpcomponents-client httpcomponents-core junit xalan-j2 xbean xz-java
> ke4qqq jakarta-commons-httpclient
> lef geronimo-jpa
> mef maven-doxia
> mizdebsk ant ant-contrib aopalliance apache-commons-beanutils
> apache-commons-collections apache-commons-compress apache-commons-io
> apache-commons-jxpath apache-commons-lang apache-commons-lang3
> apache-commons-logging apache-commons-net apache-ivy apache-parent
> apache-resource-bundles aqute-bnd atinject bcel beust-jcommander bsf bsh
> byaccj cal10n easymock exec-maven-plugin felix-osgi-core felix-utils
> geronimo-jms geronimo-jpa geronimo-parent-poms glassfish-jsp-api
> google-guice guava20 hawtjni httpcomponents-client httpcomponents-core
> httpcomponents-project jakarta-commons-httpclient jansi jansi-native
> javacc javacc-maven-plugin javamail javapackages-tools javassist jaxen
> jdepend jdependency jflex jsoup junit jvnet-parent maven
> maven-antrun-plugin maven-archiver maven-artifact-resolver
> maven-artifact-transfer maven-assembly-plugin maven-clean-plugin
> maven-compiler-plugin maven-dependency-analyzer maven-dependency-plugin
> maven-dependency-tree maven-doxia maven-doxia-sitetools maven-enforcer
> maven-file-management maven-filtering maven-invoker maven-jar-plugin
> maven-parent maven-plugin-build-helper maven-plugin-bundle
> maven-plugin-testing maven-plugin-tools maven-plugins-pom
> maven-reporting-api maven-reporting-impl maven-resolver
> maven-script-interpreter maven-shade-plugin maven-shared-incremental
> maven-shared-io maven-shared-utils maven-source-plugin maven-surefire
> maven-verifier maven-wagon modello mojo-parent munge-maven-plugin
> objectweb-pom os-maven-plugin osgi-compendium osgi-core
> plexus-ant-factory plexus-archiver plexus-bsh-factory plexus-classworlds
> plexus-cli plexus-compiler plexus-component-factories-pom
> plexus-components-pom plexus-containers plexus-i18n plexus-interactivity
> plexus-interpolation plexus-io plexus-languages plexus-resources
> plexus-utils plexus-velocity qdox regexp sisu sisu-mojos slf4j
> sonatype-oss-parent sonatype-plugins-parent velocity xalan-j2 xbean xmvn
> xz-java
> msrb ant javapackages-tools maven xmvn
> pingou maven-shade-plugin
> spike apache-commons-beanutils apache-commons-compress
> apache-commons-io apache-commons-jxpath apache-commons-lang
> apache-commons-logging apache-commons-net
> yyang maven-plugin-testing maven-plugin-tools maven-wagon modello
> plexus-containers
>
> --
> Mikolaj Izdebski
> Senior Software Engineer, Red Hat
> IRC: mizdebsk
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
1:54 p.m.
On 09/27/2018 04:34 PM, Neal Gompa wrote:
On Mon, Sep 24, 2018 at 3:39 PM Mikolaj Izdebski
<mizdebsk(a)redhat.com> wrote:
>
> Java SIG is dying slowly, this package set recently lost another
> co-maintainer and I don't have time to maintain all these packages by
> myself. Switching to module-only content is probably the best move to
> keep high-quality software delivered to our users and reduce maintenance
> work at the same time.
Have you done *anything* to try to reinvigorate the Java SIG? I've not
seen anything at all about this problem.
No, not anything aimed specifically at this. I am monitoring various
channels and help people that try to contribute to Fedora, not only to
Java stuff, if that counts.
Do Java folks in the
ecosystem who happen to use RH/Fedora ecosystem stuff know about it?
From what I experienced, people in Java ecosystem are rarely interested
in packaging Java for Linux distros.
Are you doing any outreach/advocacy either across the distro
ecosystem
or across the Java ecosystem to try to bring interested people in
helping with Java stack work?
No, I'm not doing any kind of such activities - TBH human interaction is
not amongst my best skills.
With Rust, we elected to try to become part of the Rust ecosystem, and
we've also taken the tack of working with other distributions to be
able to leverage the efforts across distros to make things better. We
are in the process of reviving the Go SIG in a similar manner. There's
no reason Java couldn't too. And unlike Rust and Go, people *need*
Java for both legacy and new things! Java can be exciting and
interesting, but some effort has to be made to "get the word out".
Many things we do for Java packaging is distro-agnostic and I always
wanted to have some cross-distro cooperation, but I never had enough
time to start connecting with other distros for real.
The Python SIG also does a decent job talking about itself and
showing
up at Python events to talk about how Fedora loves Python. Do we love
Java too?
That's a good idea, thanks. Maybe having a packaging-oriented talk at
some Java conference would help a bit with current situation.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
2:03 p.m.
On 09/24/2018 11:25 PM, Ben Rosser wrote:
On Mon, Sep 24, 2018 at 3:39 PM, Mikolaj Izdebski
<mizdebsk(a)redhat.com> wrote:
> On 09/24/2018 08:52 PM, Miro Hrončok wrote:
>> On 24.9.2018 19:09, Mikolaj Izdebski wrote:
>>> I'm in the process of transitioning maintenance of all software to
>>> modules only. The reason is that module maintenance is much easier
>>> compared to maintenance of non-modular, "ursine" packages.
>>>
>>> Ideally these packages should be retired instead of orphaning them, but
>>> these packages are build-required by a lot of other things.
>> This is an interesting situation. If more maintainers will decide to do
>> this, we can easily break everything and only have modules, except we
>> will no longer have any system to have those modules run on.
>>
>> (I'm not saying you shouldn't do this; I'm just really concerned if
>> modularity is actually helping Fedora as a whole or if it will
>> eventually break it entirely.)
>
> I was hoping for a solution like "ursa-major" described in [1], that
> would allow modules to be used as build-dependencies for non-modular
> packages. This would allow properly retiring non-modular packages and
> maintaining only modules, which would be also used as build dependencies
> for non-modular packages. But it seems that currently no one is
> interested in implementing such solution.
>
> Java SIG is dying slowly, this package set recently lost another
> co-maintainer and I don't have time to maintain all these packages by
> myself. Switching to module-only content is probably the best move to
> keep high-quality software delivered to our users and reduce maintenance
> work at the same time.
>
> [1]
>
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
This is something that worried me also when I read this message.
Are modules only intended for leaf packages at the moment? I admit
that I have not really been keeping up to date with modularity. Or is
the intended workflow that (eventually) everything's a module, and so
if something needs to depend on a module, it too must be inside a
module for this to work?
No, modules are not for leaf packages only. Non-modular packages can
depend on modular packages, as long as module stream is set as default.
(And of modules can depend on any stream of other modules, not just
default stream.) The work to convert everything to a module was
abandoned around December last year, IIRC, as it turned out to be too
difficult to achieve.
This seems like it could become a problem, because I imagine that
there are lots of leaf packages out there that aren't in modules, or
don't necessarily need to be in modules-- unless parts of the
distribution start becoming module-only.
Parts of distribution becoming a module-only does not prevent users from
installing other non-modular software. But it prevents non-modular
software from being built, as Koji currently cannot use modules in
buildroots of non-modular packages. But there is an ongoing discussion
with release engineering to change that, see [1] and [2]. I have some
hopes this may be implemented.
[1] https://pagure.io/releng/issue/7840
[2]
https://meetbot.fedoraproject.org/fedora-meeting-2/2018-09-27/releng.2018...
(Maybe this discussion belongs in a new thread, but I think it's important).
Ben Rosser
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
2:16 p.m.
On 09/26/2018 04:17 AM, Kevin Kofler wrote:
Mikolaj Izdebski wrote:
> I'm in the process of transitioning maintenance of all software to
> modules only. The reason is that module maintenance is much easier
> compared to maintenance of non-modular, "ursine" packages. Starting from
> Fedora 29 modules are first-class citizens, so I am finally able to
> orphan ursine packages that are already available in modules.
This is exactly what I feared when the modules were first proposed:
essential packages moving to modules only.
What would be an alternative? Orphaning/retiring some packages? Or
pretending to maintain them - not keeping them up-to-date, ignoring bugs
or delaying fixes, except from FTBFS fixes to prevent removal from
distribution?
Modules with their API specifications at least make it more clear what
are expectations about packages. Something user may consider essential
is only a build dependency for a packager and the packages won't receive
enough attention from the maintainer.
I think this is absolutely a step in the wrong direction. Things like "ant"
are essential parts of a distribution. They cannot sit in some module with
arbitrary branches that can be EOLed at any time.
Module lifecycles are being discussed in a different thread. But I agree
that current situation in which modules (especially those containing
important packages) can be EOL before distribution EOL is not ideal.
Kevin Kofler
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
2:32 p.m.
On 09/26/2018 08:01 AM, Raphael Groner wrote:
>> Mikolaj Izdebski wrote:
>>
>> This is exactly what I feared when the modules were first proposed:
>> essential packages moving to modules only.
>>
>> I think this is absolutely a step in the wrong direction. Things like
"ant"
>> are essential parts of a distribution. They cannot sit in some module with
>> arbitrary branches that can be EOLed at any time.
>>
>> Kevin Kofler
As far as I can understand the modules idea and while looking into those yaml files of
ant and cmake for instance, I fail see why modules should work without any spec file and
therefore also why without rpmbuild. The modules idea seems to be more about how to have a
possibility to build a bunch of packages in their own dependency tree for a custom branch
(and on which base system that branch should ever work).
Modules are more than just a way to build RPM packages.
To me the most important feature of modules is clear distinction between
different support levels for different packages. Packages that are part
of module API are fully supported (by maintainer and the community in
general), in all aspects. Packages that are non-API packages are
supported only in contexts they are used as dependencies for API
packages. There is also a third group of packages - build dependencies.
These are not supported, except for building other packages with, and
don't even have to be shipped to users in standard repos (mirrors), but
of course are still available in Koji and anyone can use them to build
their modules (locally, in third-party addon repos etc.)
So in my opinion, modules can never work without any base system
built completely from without modules.
Modules are just sets of (zero or more) packages with extra metadata.
Take a non-modular distribution and add metadata file and you have a
module - platform module.
What I like about modules is that it obsoletes the need to check for
the target distribution inside of the spec file (that's now handled with a branch in
git). What I don't like is that all dependencies have to get repeated in the yaml
file. What real problem do we try to solve?
Dependencies specified in modulemd are higher-level dependencies. They
are not simply repeating RPM package dependencies.
Please calm down and just my 5ct.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
6:14 p.m.
On Thu, 27 Sep 2018 10:34:33 -0400, you wrote:
On Mon, Sep 24, 2018 at 3:39 PM Mikolaj Izdebski
<mizdebsk(a)redhat.com> wrote:
>
> Java SIG is dying slowly, this package set recently lost another
> co-maintainer and I don't have time to maintain all these packages by
> myself. Switching to module-only content is probably the best move to
> keep high-quality software delivered to our users and reduce maintenance
> work at the same time.
Have you done *anything* to try to reinvigorate the Java SIG? I've not
seen anything at all about this problem. Do Java folks in the
ecosystem who happen to use RH/Fedora ecosystem stuff know about it?
This sort of came up a couple of years ago when the packaging of
Hadoop and other Big Data stuff was started by others.
Part of the reason it didn't go far was that the Hadoop / Big Data /
Java community didn't trust / weren't interested in using versions of
the software packaged up into rpms. I suspect part of the reason was
that it was difficult to know what was happening (it seems like
installing anything non-minor in Java results in hundreds of rpms to
be installed) and too many Java projects don't maintain their
dependencies very well.
Or, short version, the Java ecosystem is either indifferent or hostile
to distribution packages.
7:50 p.m.
Mikolaj Izdebski wrote:
Modules with their API specifications at least make it more clear
what
are expectations about packages. Something user may consider essential
is only a build dependency for a packager and the packages won't receive
enough attention from the maintainer.
As I wrote in another thread: Any packages that are used to build packages
that are delivered to the users MUST also themselves be delivered to the
users in a self-hosting distribution. This is the definition of
"self-hosting". It is also required to comply with some copyleft licenses.
Kevin Kofler
12:47 a.m.
* Mikolaj Izdebski [24/09/2018 21:39] :
Java SIG is dying slowly, this package set recently lost another
co-maintainer and I don't have time to maintain all these packages by
myself.
Is there anyway to recruit new members? I've been told that Mageia's Java
stack is a recompilation of Fedora's. If that's true, maybe their packagers
are willing to get more involved and share the load.
Emmanuel
3:09 a.m.
On 09/28/2018 02:50 AM, Kevin Kofler wrote:
Mikolaj Izdebski wrote:
> Modules with their API specifications at least make it more clear what
> are expectations about packages. Something user may consider essential
> is only a build dependency for a packager and the packages won't receive
> enough attention from the maintainer.
As I wrote in another thread: Any packages that are used to build packages
that are delivered to the users MUST also themselves be delivered to the
users in a self-hosting distribution. This is the definition of
"self-hosting". It is also required to comply with some copyleft licenses.
This is already not met for Fedora. Lets look at ant package which you
mentioned earlier.
Ant 1.10.2 was built with a chain build [1].
This chain build can be represented as:
ant-1.10.1-9.fc28 -> ant-1.10.2-0.1.fc28 -> ant-1.10.2-1.fc28
Chain build was necessary because:
- Ant is built with Ant.
- Ant 1.10.2 requires Ant 1.10.2 to build.
- Ant 1.10.2 can't be built with Ant 1.10.1 without patching.
Intermediary build ant-1.10.2-0.1.fc28 (which release starts with 0 to
make it clear it's a bootstrap build) was never shipped to users. It was
used only as a buildroot override that was active for less than 5 minutes:
Tue Mar 6 14:13:24 2018 ant-1.10.2-0.1.fc28 tagged into f28-override
Tue Mar 6 14:17:49 2018 ant-1.10.2-0.1.fc28 untagged from f28-override
Moreover, this intermediary build was already deleted [2] from Koji.
Users that want to reproduce Ant 1.10.2 build would need to repeat
series of builds and rely on information stored in Koji to know what
builds should be ran in what order. Trying to build packages only from
content released to users would be even more difficult.
This also shows why Java package maintenance may be time consuming and
why I'm looking for ways to reduce maintenance work - even micro version
bumps like 1.10.1 to 1.10.2 may require bootstrapping. Bootstrapping
developed specifically for particular upgrade.
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25518471
[2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1027958
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
3:15 a.m.
Le jeudi 27 septembre 2018 à 19:14 -0400, Gerald Henriksen a écrit :
Or, short version, the Java ecosystem is either indifferent or hostile
to distribution packages.
Any language ecosystem is initially hostile to distribution packages.
Languages ecosystems are created by devs, that care little about
deployment, because
1. they have nothing to deploy at first
2. if they cared about deployment and upgrades, they wouldn't join an
ecosystem with no deployment story
That initial dev-not-deploy seed tend to imprint the ecosystem culture
deeply.
And it's worse when you have large business adoption, because businesses
want immediate ROI and will pay to have software deployed now even if it
takes manual non reusable steps, immature language-specific packages,
business-specific no shared tooling, SCL hacks and so on. Thus
reinforcing the initial dev conviction they need not bother about
deployment and upgrades (note that in that case the "open source free
software" gets captured inside the business non open or free bubble
because that's the only way to use it in production; and right now
Fedora's main sponsor does not care so much about this capture because
it has become a business provider).
You have to package a large initial baseline of software components,
against at best the indifference at worst the hostility of this
ecosystem, do much outreaching, before it gets established enough a
significant part of the language ecosystem uses it and is convinced the
approach is good. You have to be persistent, and try to bridge two tech
cultures, and be convinced yourself, because people the other side are
waiting for you for give up so they can continue to ignore deployment
problems and offload them to (despised) operations. Containers and
devops are just another way to collect this huge bag of poop and dump it
on someone else. Just take any random container and try to do a security
audit of the stuff contained inside the shiny modern enveloppe.
Besides the main advantage of distribution packages is upgrade
management, and composing of many software components, by tracking the
state of each of those components, and providing uniform deployment
rules. So you have to wait for years of botched upgrades via other
means, and exhaustion of all alternative ways to ignore this tracking by
precomposing every possible component mix in separate images, before it
becomes evident you need to use distribution packages (and devs are not
on the front line for botched upgrades so the realization will not come
from the dev side).
Note that modules already hit the "too many composition scenarii to
precompose everything" wall. That's what caused the back-pedalling on
transforming Fedora in a set of independent leaf modules with no distro
packages left (but modules-only no distro package little song lingers)
There are no special distribution-friendly langages. C∕C++ software was
deployed for years without packages on Solaris, AIX, Windows and so on
before all the efficiency wins of doing via packages on Linux made Linux
distributions capture that market.
Many other markets are waiting for a similar distribution moment. For
now, addressing them via container, images or modules is not a business
handicap, because of the lack of an alternative player. I'm sure they
were many meetings at SUN, IBM, HP & Microsoft where the packaging
question was raised and someone decided "why bother, it takes money and
energy, right now competitors are just as bad as us, devs do not want to
deal with the complexity of tracking dependencies, let's look at it
later".
--
Nicolas Mailhot
3:20 a.m.
Le vendredi 28 septembre 2018 à 10:09 +0200, Mikolaj Izdebski a écrit :
This is already not met for Fedora. Lets look at ant package which you
mentioned earlier.
That just shows it is urgent for Fedora to improve its handling of
bootstrapping operations, because major languages depend on it today
(Java is not the only one).
It is not sustainable to require packagers to manage bootstraping
manually, because koji has no knowledge of it.
--
Nicolas Mailhot
8:49 a.m.
On Fri, 28 Sep 2018 10:15:46 +0200, you wrote:
Le jeudi 27 septembre 2018 à 19:14 -0400, Gerald Henriksen a écrit :
>
> Or, short version, the Java ecosystem is either indifferent or hostile
> to distribution packages.
Any language ecosystem is initially hostile to distribution packages.
Except this has been going on for years, and hence is long past the
initially stage.
Besides the main advantage of distribution packages is upgrade
management, and composing of many software components, by tracking the
state of each of those components, and providing uniform deployment
rules.
Which quickly falls apart when upstream refuses to update their code
to the latest versions of the libraries they use, and Fedora (rightly)
as a rule doesn't want multiple versions of libraries.
I agree that in an ideal world the distribution model is the best and
most effective, but we don't live in an ideal world and sadly many
(most?) upstreams don't follow what a distribution would consider good
practices.
There are no special distribution-friendly langages. C?C++ software
was
deployed for years without packages on Solaris, AIX, Windows and so on
before all the efficiency wins of doing via packages on Linux made Linux
distributions capture that market.
Except all the "modern" languages decided to solve the problem
themselves with their own repositories of libraries and build systems
that pull in dependencies as needed. They (somewhat rightly from
their respective) view maven, gradle, npm, etc. as the best and
preferred solution because they deal with it once and it covers every
OS.
Which is why the C++ community is belatedly dealing with the issue and
has started a working group on trying to deal with the issue of a
package manager.
9:26 a.m.
On Fri, 28 Sep 2018 at 04:21, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
Le vendredi 28 septembre 2018 à 10:09 +0200, Mikolaj Izdebski a écrit :
>
> This is already not met for Fedora. Lets look at ant package which you
> mentioned earlier.
>
That just shows it is urgent for Fedora to improve its handling of
bootstrapping operations, because major languages depend on it today
(Java is not the only one).
It is not sustainable to require packagers to manage bootstraping
manually, because koji has no knowledge of it.
Can you explain what you mean by that? Since we have been doing
basically this for 20+ years since the beginning of Red Hat Linux in
some form or another.. it would seem not just sustainable but just
what happens with various source trees. What does sustainable mean in
this case?
--
Stephen J Smoogen.
1:16 p.m.
Le vendredi 28 septembre 2018 à 10:26 -0400, Stephen John Smoogen a
écrit :
On Fri, 28 Sep 2018 at 04:21, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
> Le vendredi 28 septembre 2018 à 10:09 +0200, Mikolaj Izdebski a
> écrit :
> > This is already not met for Fedora. Lets look at ant package which
> > you
> > mentioned earlier.
> >
>
> That just shows it is urgent for Fedora to improve its handling of
> bootstrapping operations, because major languages depend on it today
> (Java is not the only one).
>
> It is not sustainable to require packagers to manage bootstraping
> manually, because koji has no knowledge of it.
>
Can you explain what you mean by that?
I mean that when a larger and larger package set needs bootsrapping due
to upstream practices, we can't continue to have koji and mock treat it
like a weird exception that can be dealt with by manual packager
handling
Yes the packager has to document the bootstraping recipe in the spec,
but the tools should apply it automatically when normal builds fails,
not rely on manual switching of with/without bootstrap variables by the
packager, or manual computation of mass rebuild execution plans.
--
Nicolas Mailhot
5:39 p.m.
Mikolaj Izdebski wrote:
Users that want to reproduce Ant 1.10.2 build would need to repeat
series of builds and rely on information stored in Koji to know what
builds should be ran in what order. Trying to build packages only from
content released to users would be even more difficult.
The point is, the Ant 1.10.2 package can be used to build itself (as well as
hundreds of other Java packages, including the user's own code). It is not
essential to be able to redo the bootstrapping as long as the bootstrapped
binary that is shipped is self-hosting.
And if you want to no longer ship Ant because it is "only" a build tool,
that is going to make Fedora essentially useless for Java developers.
Kevin Kofler
7:21 p.m.
I wouldn't use the word useless. Having the packages is just a quality of life thing.
Just like for me as mainly C++ developer; not having Basel or abseil does not make Fedora
useless for me or C++ developers. It doesn't take much effort to get your environment
up and running script the procedure and share with team mates to replicate.
\-------- Original Message --------
On Sep 28, 2018, 18:39, Kevin Kofler < kevin.kofler(a)chello.at> wrote:
Mikolaj Izdebski wrote: > Users that want to reproduce Ant 1.10.2 build would need to
repeat > series of builds and rely on information stored in Koji to know what >
builds should be ran in what order. Trying to build packages only from > content
released to users would be even more difficult. The point is, the Ant 1.10.2 package can
be used to build itself (as well as hundreds of other Java packages, including the
user's own code). It is not essential to be able to redo the bootstrapping as long as
the bootstrapped binary that is shipped is self-hosting. And if you want to no longer ship
Ant because it is "only" a build tool, that is going to make Fedora essentially
useless for Java developers. Kevin Kofler
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to
devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing\_list\_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
1:44 a.m.
Gerald Henriksen wrote:
what rule is that?
-- Rex
Maybe our guidelines [*] about bundling and duplication is threatened with modularity.
Last but not least, if there's a CVE or soname bump in whatever library, we'd need
to rebuild the whole modularity stack depending. That would mean to request more traffic
to the end users with all the updates, this coordination needs communication.
Without modularity, we've to just rebuild the affected library package(s) in case of
CVE and it'd be mostly done.
Of course, we shouldn't base the process on one or two maintainers only to be expected
to handle the whole dependencies stack, java packaging is indeed a good example.
Regards, Raphael
[*]
https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplicat...
2028
days inactive
2034
days old
25 comments
13 participants
participants (13)
-
Ben Rosser -
Christopher -
Emmanuel Seyman -
Gerald Henriksen -
Israel Bermudez -
Kevin Kofler -
Mikolaj Izdebski -
Miro Hrončok -
Neal Gompa -
Nicolas Mailhot -
Raphael Groner -
Rex Dieter -
Stephen John Smoogen