add decision for libjpeg api

diff --git a/717076_libjpeg/decision b/717076_libjpeg/decision
new file mode 100644 (file)
index 0000000..1aeaa6d
--- /dev/null
+++ b/717076_libjpeg/decision
@@ -0,0 +1,86 @@
+===== TITLE
+
+Default libjpeg implementation in Debian
+
+===== WEB SUMMARY
+
+The committee decided that the default libjpeg implementation should
+be libjpeg-turbo.
+
+===== EMAIL INTRO
+
+The technical committee was asked in #717076 to decide whether
+libjpeg8 or libjpeg-turbo would be the default libjpeg implementation.
+The decision is below:
+
+===== EMAIL EPILOGUE
+
+
+===== DECISION
+
+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:
+
+10. The Technical Committee resolves that libjpeg-turbo should
+    become the libjpeg implementation in Debian, using its power
+    under 6.1(2) to decide on technical matters of overlapping
+    jurisdiction.
+
+11. The prospective libjpeg-turbo maintainer should propose an appropriate
+    transition plan for this change, and, after a reasonable period for
+    comment, prepare tested packages for upload.  The transition
+    plan should state the timescales for the relevant changes.
+
+12. Implementing the decision in 10 above will require removing
+    "Provides: libjpeg-dev" from libjpeg8, since such a virtual
+    package must be provided by only one real package at a time.
+    Therefore the Provides should be removed from the libjpeg8
+    package - in accordance with the transition plan -
+    notwithstanding the libjpeg8 maintainer's preference that
+    libjpeg8 should remain as the default libjpeg.  This change
+    should be made by the libjpeg8 maintainer; if the change is not
+    made within a reasonable time it should be done in an NMU by the
+    libjpeg-turbo maintainer.
+