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