[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Concentrating on existing kde2 ports.
I'm finally catching up on kde ports...
I hope I won't forget anything, since I have my own work, Christian and
Maurice Nonneke's to merge, sometimes multiple times with intermediate
versions.
Everything is probably not going to work outright.
Instead of having MORE kde ports, I would like people to concentrate on
fixing outstanding issues. Namely, it would be cool if kdm were to work
(right now, it does not).
It could also be very useful to sub-package kdebase. For instance, except
for testing ports, the only part of kde2 I currently use it konqueror.
A subpackage that only installs the parts that konqueror needs could
be handy (as some people will say, with reason, that kde2 is just too big
for `just the web browser').
Providing more useful configuration (running kapplnk and stuff, doing
intelligent things with our ports tree) also comes to mind...
I believe we can ditch kde1 at some point in the near future. kde2
appears to become reasonably stable. In six months times, all issues will
probably have been fixed.
Hunting down the few apps in the ports tree that depend on kdelibs1 and
checking whether an updated kde2 version exists could come in handy...
kde1 conflicts with kde2. Note also that kde1 depends on qt1, which still
has a TrollTech licence, hence can't go on CDs, whereas kde2 looks to me
like a prime candidate for the next release (it wasn't included in 2.8
because of its youth and various problems).
Cleaning up patches and feeding them back to the kde team also comes to
mind (I ought to take care of libtool issues reasonably soon).
A class that builds on mkstemp and is easy to use is probably the right
way to solve all temporary file issues (kde does have a tempfile class,
but it necessitates modifying code to work. Namely, it creates temporary
anonymous files that it unlinks right away).
Right now, the kde2 ports don't have actual MAINTAINERS, mostly because
of their sizes. Well, I spent some time fixing libtool and C++ details,
but I don't want actual maintainership for those ports. I believe that
shared maintainership (like we did we teTeX a while back) might be the
key: keeping ports as maintainer is a good way to ensure no-one will move
their asses, but the ports themselves are a bit daunting.