How to best maintain libqt4-ruby (and libsmokeqt4) once KDE4 is here
Adeodato Simó
dato at net.com.org.es
Wed Jan 2 17:20:35 UTC 2008
Hello, Vincent.
I was looking today at the kdebindings module of KDE4, and I noticed it
not only ships Ruby bindings for KDE (Korundum), but also to Qt, which
you maintain at the moment in a separate source package (libqt4-ruby).
From what I've seen, these bindings are all maintained in KDE's SVN
repository, and releases to Rubyforge are made periodically. How do you
think we'd best proceed? In particular, let's address these points:
1. once kdelibs from KDE4 enter unstable, would you still like
(hopefully!) to continue to maintain libqt4-ruby? If so, would you
be willing to maintain it from a kdebindings package (we'd give you
commit access to the pkg-kde repository), or would you rather
continue to maintain it in a separate source package?
2. would you have any interest in maintaining Korundum, the Ruby *KDE*
bindings? Again, either from the kdebindings package, or from a
separate source package (belonging eg. to pkg-ruby-extras). I ask
because the pkg-kde team is already overloaded, and we know that a
single interested maintainer would do best than ourselves.
3. on the other hand, though, we feel that libsmokeqt4 should be
maintained from the kdebindings source package, since that's its
origin, and (if I'm not mistaken) other bindings can need it (in
other words, it's only bundled in the qt4-qtruby tarball for
convenience, ain't it so?) So, would you agree that we make
kdebindings gains the libsmokeqt4-* packages once KDE4 starts
entering unstable?
Thanks in advance!
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Los Planetas - Desaparecer
More information about the pkg-kde-talk
mailing list