move old issues to the resolved_issues directory

[debian-ctte.git] / resolved_issues / 717076_libjpeg / cjwatson_draft.txt

diff --git a/resolved_issues/717076_libjpeg/cjwatson_draft.txt b/resolved_issues/717076_libjpeg/cjwatson_draft.txt
new file mode 100644 (file)
index 0000000..350dd71
--- /dev/null
+++ b/resolved_issues/717076_libjpeg/cjwatson_draft.txt
@@ -0,0 +1,67 @@
+  Whereas:
+
+   1. There is a dispute between Developers about whether libjpeg8/9 or
+      libjpeg-turbo should be the default libjpeg implementation in
+      Debian.  The release team does not want to have more than one
+      libjpeg implementation.
+
+   2. The Debian libjpeg8 maintainer does not see libjpeg-turbo as a
+      suitable replacement, and notes that it does not implement the
+      full libjpeg8/9 ABI.
+
+   3. libjpeg8 adds new features to the JPEG image format.  These have
+      however been rejected from the ISO standard, and their
+      contributions to image quality and compression appear to be widely
+      disputed.
+
+   4. libjpeg-turbo is reported to have significantly better performance
+      than libjpeg, and to be API/ABI-compatible with libjpeg6b.
+
+   5. libjpeg-turbo is in use by several other distributions (at least
+      Fedora, Gentoo, openSUSE, Ubuntu) and browser projects (WebKit,
+      Blink, Gecko).
+
+   6. The former organiser of the IJG advised Fedora of his opinion that
+      libjpeg8 was a "dead end" due to fragmentation.
+
+   7. The libjpeg-turbo packages in Debian are not yet in a state where
+      they could be a drop-in replacement for libjpeg8.  However,
+      similar work has been done in Ubuntu and could be adopted.
+
+   8. In general it does not appear that other Debian packages require
+      the libjpeg8 API.  The sole exception appears to be a "decode from
+      memory buffer" interface (jpeg_mem_src/jpeg_mem_dest), which is
+      implemented by libjpeg-turbo unless configured
+      --without-mem-srcdst.
+
+   9. While libjpeg-turbo can be configured with support for much of the
+      newer interfaces in libjpeg8, it does not support the SmartScale
+      API.  However, images with this extension may have
+      interoperability problems.  Those developers advocating
+      libjpeg-turbo generally suggest disabling the libjpeg7/libjpeg8
+      APIs there.
+
+  Therefore:
+
+A (3:1 majority required)
+A
+A 10. The Technical Committee resolves that libjpeg-turbo should become
+A     the libjpeg implementation in Debian, using its power under 6.1(2)
+A     to decide on technical matters of overlapping jurisdiction.
+A
+A 11. The prospective libjpeg-turbo maintainer should propose an appropriate
+A     transition plan for this change, and, after a reasonable period for
+A     comment, prepare tested packages for upload.
+A
+A 12. Implementing this change will require removing "Provides:
+A     libjpeg-dev" from libjpeg8.  The libjpeg8 maintainer has made his
+A     preference clear that libjpeg8 should remain as the default
+A     libjpeg.  Under 6.1(4), we overrule this decision and require that
+A     this Provides be removed in accordance with the libjpeg-turbo
+A     transition plan.
+
+B 10. The Technical Committee resolves that libjpeg8/9 should remain
+B     the libjpeg implementation in Debian, using its power under 6.1(2)
+B     to decide on technical matters of overlapping jurisdiction.
+
+(Option A requires a 3:1 majority.)