Re: anyone interested in adopting ICU?
Please reply to me directly (or CC me on replies) as I am not currently subscribed to debian-devel. Enrico Weigelt weig...@metux.de wrote: * Jay Berkenbilt q...@debian.org schrieb: 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. If it's not urgent, I'd like to take the job (need some time to set up an recent Debian build machinery again, as I didn't use it for almost a year now, and I'm little bit busy right now :(). . . . I should have done this a long time ago, but I finally got around to posting an RFA for this. The bug number is 638590. -- 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/20110820090838.0299465509.qww314159@soup
Re: anyone interested in adopting ICU?
Please reply to me directly (or CC me on replies) as I am not currently subscribed to debian-devel. Enrico Weigelt weig...@metux.de wrote: * Jay Berkenbilt q...@debian.org schrieb: 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. If it's not urgent, I'd like to take the job (need some time to set up an recent Debian build machinery again, as I didn't use it for almost a year now, and I'm little bit busy right now :(). ICU4C is a little bit tricky case, as it tends to break ABI (sometimes even API) between releases, sometimes even semantic changes (at least had been the case in recent years). So I'd go for a full MVCc installation (IMHO better than Gentoo's slotting + revdep-rebuild approach ;-p). I'll yet have to pull it through my own embedded QM process and build machinery first, so we'll also get crosscompile fixups etc as a buy-product here ;-) My offer stands, so if you'd like to take it, go right ahead. There's a problem right now with icu 4.8 in experimental on kfreebsd-amd64 that I haven't been able to solve in the 20 minutes or so I spent trying to figure it out. Also, 4.8.1 has been released, and I have not packaged yet. There is an open bug for tracking the transition to 4.8, but obviously these issues should be corrected first. How long do you think it will be before you are ready to adopt the package? Maybe you can take a look at bug 630517 and see if you can make some headway on it. Also, are you a DD? I can't find any indication that you are. I am not interested in sponsoring uploads (as I don't really have time to do the reviews, etc.), so hopefully I have either overlooked your debian account or you have sponsorship arrangements. I have a local subversion repository with all my packaging stuff in it, and I use svn-buildpackage against my local repository. If you're interested in a dump of that, let me know, and I can send it to you. -- 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/20110724091158.0304813597.qww314159@soup
Re: anyone interested in adopting ICU?
* Jay Berkenbilt q...@debian.org schrieb: ** 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. If it's not urgent, I'd like to take the job (need some time to set up an recent Debian build machinery again, as I didn't use it for almost a year now, and I'm little bit busy right now :(). ICU4C is a little bit tricky case, as it tends to break ABI (sometimes even API) between releases, sometimes even semantic changes (at least had been the case in recent years). So I'd go for a full MVCc installation (IMHO better than Gentoo's slotting + revdep-rebuild approach ;-p). I'll yet have to pull it through my own embedded QM process and build machinery first, so we'll also get crosscompile fixups etc as a buy-product here ;-) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- 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/20110516094323.GB14996@nibiru.local
anyone interested in adopting ICU?
** 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