On Mon, Feb 27, 2012 at 00:39, Rolf Leggewie <debian-b...@rolf.leggewie.biz> wrote: > On 26.02.2012 23:57, Aron Xu wrote: >> It's funny to flame, Rolf. > > flame? what do you mean, Aron? >
Flamewar is not a good thing, seriously. I was trying to help you, but in return there isn't a friendly response from you. Actually I have planned to help fix most missing points in SCIM stack before Wheezy release. But please read on, because I planned to fix a subset of SCIM only. > Honestly, I was just trying to explain to you my position and where I > think it differs from yours. I think it's great you have higher > standards than me. My goal is simply to give a more smooth way out, out > of the inevitable - eventually. > > Between you and me, I'm also a bit miffed about this whole push to > remove scim. > [...] I know there was unclear things among SCIM maintainers, including you and others. But I don't think this push to the removal of SCIM is wrong. The reason is simple, Debian is an organization aimed at shipping quality software. When you have said you don't have plan to do the work about scim-bridge itself, then it should go away because upstream is dead for years, and there are only several unnamed patches around but no new upstream maintainer. The situation might be OK for software that don't integrate to user's environment very much. But as you already know, input method (the platform) is something intended to work with all kinds of user programs, namely X, Gtk2/3 and Qt3/4. The bug report itself for not supporting something is not RC-buggy, but it does not mean ignoring it is okay if the package still builds and run under certain situation. > Another thing that I'm very slightly miffed about is the air of > "officialdom" coming out of the pkg-ime corner. Whatever that project > is, scim has been around longer so the burden would have been on pkg-ime > to contact the current maintainers, not the other way around. And > pkg-ime not knowing about scim or its status, that was really just > laughable, you have to admit. For one thing, Osamu-san is part of both > projects and Debian is a public project. I'm not concerned if some leaf > packages in scim eco-system are being lost, for example, or I would make > an effort to take them over. That's healthy and good. > We are not official, but it's a rather strong voice within Debian on issues related to input methods. Actually the original packagers and maintainers of the most of SCIM stack (and who are still active) are either in the team directly, or have very closed communications with us. The upstream author of the software is also in contact with us. It's pointless to say we don't know it well, to be rude but honest. > Again, frankly, I don't see any urgent work necessary in scim right now. > I'd say it would be very nice if scim were to support gtk3, but > upstream is struggling with it. And if scim only supports what's > already there, then personally I have no problem with that. I'm not out > there to do upstream work to expand use cases for scim. I'm mostly here > to make sure it dies a death in style. The time hasn't come, yet. > Again, look at user numbers. > > IYO, where IS a real problem with scim or scim-bridge? As I have repeated for several times, there ARE real problem in scim and scim-bridge. And you also agree, SCIM just needs some more time to die. I'm not going to ask for its death immediately, and I believe it's the right choice to keep SCIM itself for Wheezy, and remove stuff that are badly unmaintained before SCIM. It is reasonable: 1.On the effects towards users Keeping scim for Wheezy is obvious, it's far too late to raise any kind of discussion about whether it should be removed. I'm only going to ask to remove functions that aren't work/useful at all, like scim-python, and scim-bridge. scim-python isn't working at all; scim-bridge provides gtk2/qt4 support, but actually qt4 support isn't good enough (as skim has been removed long ago), gtk2 support is provided by scim. It's pointless to add extra features to the software if you don't want to keep and update it for next few years. This gives users a false sign that the software is still alive, but actually we need to tell users that it will go away in the foreseeable future, and then give them sometime to plan and migrate. 2.On the effects towards Debian developers This will reduce the workload of SCIM maintainer in Debian, particularly, Rolf. I see Rolf is lacking of time to work on scim, and it's an ancient thing which consumes a lot of time to deal with the ancient build system and code. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w7yx9zvsiyclohgca6icwj8upmujc14t7v1bottewr...@mail.gmail.com
