Re: javadocs

[Sebastiaan Couwenberg <sebastic@xs4all.nl>]

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