Bug#591467: Bug #591467: ITA: scim-bridge -- IME SCIM server
On Mon, Feb 27, 2012 at 00:39, Rolf Leggewie
<debian-bugs@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
Reply to: