****** Please reply to me directly (or CC me on replies) as I am not currently subscribed to debian-devel.
****** I'm looking for someone who might like to take over the icu package. 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. I'll wait a few days before replying to messages about taking over ICU to give people time to reply. 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. A 4.8 release candidate is expected on May 11. When it comes it out, it should be packaged for experimental. I could do this, or someone else could take over the package at that time. * 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. * 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 <q...@debian.org> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110509133500.3226151089.qww314159@motoko.argon.local
