Now that we finally have a new JOSM tested snapshot in Debian, we need to decide whether or not to maintain backports for it too. This was requests about two years ago in #705548, and the experience with the outdated JOSM 8159 in Debian for some time (popular plugins require more recent tested snapshots) show that there is a need for recent JOSM versions for stable users.
Backporting JOSM also required backporting JMapViewer. The jmapviewer package in Debian is also a dependency on freeplane which tends to break with JMapViewer releases. JOSM also frequently requires more recent metadata-extractor releases, and these updates tend to break the other libmetadata-extractor-java reverse dependencies too (gpsprune & tika). libmetadata-extractor-java, freeplane & tika are maintained by the Java team, and they, like me, may not want to deal with these breakages in stable too. The josm (0.0.svn8800+dfsg3-1) package, that is expected to migrate to testing soon, was changed to use the embedded copies of JCS and metadata-extractor as this was the only way to get a new JOSM build in Debian. This makes maintaining a backport much easier, because it doesn't pull in newer metadata-extractor versions to break gpsprune & freeplane, and allows us to build JOSM in Debian without having JCS packaging available (as is also the case for javax.json). Since we generally don't want embedded copies in Debian, the use of these in JOSM should be a temporary thing until the requirements are met by the packages. We'll then need backports for the various packages from the Java team too, I don't want to ask this of them just to enable JOSM backports, nor do I want to maintain those backports too (although that seems the most feasible option). I'm not entirely happy with the embedded copies in JOSM, because I consider it an admission of defeat that Debian is unable to keep up with fast moving Java projects like that. But it does make maintenance of the package easier, with much less need to coordinate updates to prevent breakage. To summarize, I'd like to maintain backports for josm and its extended family (jmapviewer, josm-plugins & openstreetmap-map-icons), but I don't want to require backports for the packages maintained by the Java team. The current suboptimal situation for JOSM 8800 makes that an option, but not entirely up to Debian standards. Should we worry about breaking freeplane with the jmapviewer updates? Or tika if go for libmetadata-extractor-java backports? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
