--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: RFA: icu -- API documentation for ICU classes and functions
- From: Jay Berkenbilt <qjb@debian.org>
- Date: Fri, 19 Aug 2011 20:49:43 -0400
- Message-id: <20110819204943.0291383242.qww314159@soup>
Package: wnpp
Severity: normal
I'm looking for someone who might like to take over the icu package.
This is primarily due to lack of time on my part, so I'm not interested
in sponsoring someone else; the new maintainer should be prepared to
completely handle the package. I would be glad to answer questions
about it, however.
The package description is:
ICU is a C++ and C library that provides robust and full-featured
Unicode and locale support. This package contains HTML files
documenting the ICU APIs.
This is ICU4C (C/C++), not to be confused with ICU4J (Java), which is a
separate package maintained by someone else. ICU is "International
Components for Unicode". It is a robust, well-maintained project that
is widely used and has corporate backing. In Debian, it has a few
high-profile reverse dependencies including OpenOffice.org and Boost.
If no one is interested in taking it over, I will continue to maintain
it, but I don't have as much time right now to work on packages, and I
actually don't use ICU anymore myself.
ICU is a relatively low-effort package to maintain, but there are a few
things about it that are tricky. I would say you must be a C programmer
(and preferably C++) to maintain these packages well. Some of the past
debian ICU maintainers have actually been members of ICU's upstream
development community.
* ICU releases twice a year, and each release requires an soname bump,
which means you have to coordinate a transition with the release
team. The ICU project is very careful to preserve source
compatibility, and I have the packages set up so that an automatic
recompile is sufficient for pretty much all packages that depend on
icu. However, I always coordinate with the openoffice team and stage
new versions in experimental since sometimes new versions of ICU
introduce new bugs or change behavior in a way that breaks
openoffice. In fact, I skipped packaging 4.6 entirely because, with
the freeze leading up to the release of squeeze, 4.8 would probably
be out before the 4.6 transition could have completed. 4.8 is
currently in experimental, though as of this writing, it is not the
most recent 4.8 release. There is also an RC bug filed against it
that I have not had a chance to investigate thoroughly enough to
solve.
* It is high enough profile to have fairly regular security issues,
though all in all, its security situation is pretty good as upstream
stays on top of this. Because of the frequent updates, there are
usually three versions of ICU that you have to worry about for
security: oldstable, stable, and unstable. Sometimes you have to
backport fairly complicated security fixes to an older version. I
have often been able to take advantage of Red Hat's ICU packages for
security fixes, though we don't always have the same patches applied
or patches applied in the same order. Clever use of quilt has
helped, but in at least one case, I had to spend a few hours fixing
patches to backport a substantial security fix and be sure I got it
right. Upstream will sometimes help with this if necessary.
* On 64-bit platforms, ICU builds both 32-bit packages and 64-bit
packages. There have been some problems (though none recently) that
only appeared on 64-bit platforms. I would highly recommend that you
have an amd64 system as your primary build platform if you maintain
ICU. Better yet, ICU needs to be converted to use multiarch, and
this will be a little bit tricky in light of the existing 32-bit
packages built on 64-bit architectures.
* ICU includes several optimizations that use assembly language or even
directly generated object files containing only data. There have
been instances in the past where some of debian's more obscure
platforms have fooled ICU's build process and generated incorrect
results. To fix this, you have to be able to understand how all the
code generators used in ICU's build play together. I have originated
a handful of patches that have kept ICU working on all of debian's
platforms, and I have also worked with upstream to get patches
created by debian porters into the main release. This hasn't been
a problem for quite a while, but things like this happen every now
and then. Upstream is very supportive.
* Many of the bugs found in ICU only affect certain languages or
language environments. Sometimes problems can be hard to reproduce,
and unless you are familiar with the language that has the problem,
you may not be in a position to evaluate whether a patch is correct.
Sometimes the debian maintainer's job will end up being to act as an
intermediary between an end user and upstream, though I guess is true
of most packages. It can take a long time to get fixes in. I have
had bug fixes take two years to get into an upstream stable release.
This is because of how they target fixes, how they do pre-releases,
etc.
I have enjoyed maintaining ICU, and I think the debian ICU packages are
in very good shape, so I am offering it up with some reluctance. If you
think you have the skills to maintain this package in debian, please let
me know if you'd like to take it over. In spite of the complexities,
this is a relatively low-effort package to maintain. Sometimes I can go
months without having to touch it at all, and other times there is a
flurry of activity dealing with backporting security fixes or fixing
obscure problems. Many times problems have been found in pre-release
versions, so I highly recommend packaging those in experimental and
encouraging people to try them out. In this way, we have had very few
problems with serious problems getting into unstable.
--
Jay Berkenbilt <qjb@debian.org>
--- End Message ---