Bug#733586: closure-compiler: new upstream version available

[Nicholas D Steeves]

Hello Thomas and Tony,

CCing Javascript team (JS Team, please see below for why), and fixing
threading, since top-posting is confusing.  Reply follows inline:

Thomas Koch <thomas at koch.ro> writes:
>> tony mancill <tmancill at debian.org> hat am 29.03.2022 07:26 geschrieben:
>> > On Mon, Mar 28, 2022 at 03:27:17PM -0400, Nicholas D Steeves wrote:
>> > 
>> > This package came to my attention via #975505, where it was noted that
>> > MathJax2 has had to disable functionality because of too ancient of a
>> > closure-compiler, and at this time it appears that MathJax3 will have to
>> > do the same.
>> > 
>> > Closure-compiler is a candidate for salvaging:
>> > 
>> >   https://wiki.debian.org/PackageSalvaging
>> >   https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
>> > 
>> > The ideal resolution would be for one of the listed Uploaders to resume
>> > maintenance of the package, but orphaning is of course also an option :-)
>> 
>> The closure-compiler package is officially a team-maintained package by
>> the Java Team, so you or anyone else who is interested in joining Java
>> Team and maintaining the package is welcome to do so.  That is, please
>> feel free to add yourself to Uploaders.
>> 
>> That said, it's more of a JavaScript tool than a Java package, and so
>> the package could also be moved to another team if that's preferable.
>> 
>> I will gladly help with either of those options, or with reviewing and
>> sponsoring an upload of a newer version if one is made available.
>> 
>> Finally, I have never been a user of closure-compiler - my packaging
>> work on it has been under the Java Team umbrella - and I have
>> (obviously) been unable to devote sufficient time to it.  I will remove
>> myself from Uploaders to avoid any future confusion.
>>
>
> Hello,
>
> sorry, I was under the wrong impression that closure-compiler would be
> abandoned upstream and that it would eventually die of age and be
> removed.  I packaged closure-compiler as a dependency of the code
> review system Gerrit which however couldn't be packaged at the time
> due to GWT.
>
> Whoever does another upload to closure-compiler please also remove me
> from uploaders.
>
> Thank you!
>

Thank you both for your quick reply!  Your clarification and context is
much appreciated :-)  While closure-compiler is currently under the Java
Team umbrella, removing both human uploaders will create a Policy §3.3
violation (the need for a human Maintainer/Uploader is unfulfilled):

  https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer

Closure-compiler must be formally orphaned for this reason.

There is additionally a practical reason to orphan it: The maintainers
of all packages that depend on it will receive a Package Tracker
notification that it is unmaintained; This includes transitive
dependencies via MathJax2 (sigil, pandoc, etc).  Furthermore, it will
show up on the list of packages that prospective DMs and DDs investigate
as part of their process.  If I remember correctly the orphan bug will
also appear for developers who have the "how-can-i-help" package
installed.

Thus, please file the wnpp Orphan bug, because it's clearly the correct
avenue forward, and because it maximises the chance of finding a new
maintainer.

Cheers!
Nicholas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 857 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20220329/674efdf4/attachment.sig>