On 2/19/25 8:57 AM, Julien Plissonneau Duquène wrote:
Le 2025-02-18 10:59, Sebastiaan Couwenberg a écrit :
I doubt those "other maintainers" have the discipline to target their uploads
reintroducing -java-doc packages to experimental where they'll land after NEW processing.
I'm not sure this is much of an issue. Maybe you could elaborate why you think
so?
All subsequent uploads will be blocked until the package passes NEW, this
hinders the primary maintainer unless he reverts the java-doc changes again
negating the other maintainers work.
NEW uploads not targeting experimental are bad because the enter unstable at an
unpredictable time instead of shortly after being uploaded. This is very
annoying when that package is part of an ongoing transition where the uploaded
binaries are then not built of the buildds with the new version. This is
luckily less likely for java packages, but the principle stills stands.
I also wouldn't appreciate having to drop the reintroduced -java-doc package
again when its breaks with the next JDK update.
People who value java-doc package should maintain them separately to not bother
the maintainers who don't care for them. The separately maintained gcc -doc
packages might serve as an example.
I'm not against the principle, but this isn't workable for javadocs. gcc-N-doc
has separate source files and its own build system (and even a different,
non-DFSG license). javadoc source is embedded in source code, and its build
more or less tightly integrated with the binaries build system. Having
different maintainers for those would mean duplicating the entire source code
as a new source package, which is obviously not something that would be
reasonable to do.
Building something on top of snapshot.d.o might be feasible for separately
maintained javadocs.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
