[kubuntu-devel] Project Timelord -- Initial consideration

[Jonathan Riddell]

Just when I was thinking we should be coming up with plans for Lucid
here comes a big one ready formed :)

Here's what I think Kubuntu is: a KDE distribution intended for home
users.  My hypothetical girlfriend is my usual target user, someone
who uses computers for home and work use but otherwise doesn't care
too much about them.  The KDE centre gives us a consistent experience,
technical help from upstream and an initial user base of KDE fanboys
(not the majority of our users I'm hoping but the sort of people who
will pick Kubuntu over other KDE distros to help with PR and testing
because we are closer to KDE).

That has the obvious downside that when KDE suck we suck too, not
having a decent network connection tool is a collective failure of KDE
because it's something every desktop environment should have, but it
hit us hard being the ones who deliver KDE to users.  The transition
to KDE 4 has been a problem for us because of some similar cases like
that where KDE has fallen behind.  It's probably my Quaker idealism
but I do think that sticking to KDE is the best way to make a rocking
free software desktop in the long term, rather than using Gnome or
distro-proprietary tools as other distros do, because KDE is the best
platform.  In that respect I'm entirely against using Gnome-esque apps
like Synaptic or Firefox.  Network manager could be a different case,
we include proprietary drivers because without them some people
couldn't use their computer, so the same could be said there, however
I think we're over the worse for that.

translations
==
Dropping rosetta is difficult both technically and politically.  What
I do think is a glaring hole is QA to compare the upstream language
packs with our own.  I did this quickly earlier this week and found
some extra bits in our language packs that weren't needed but that was
at the file level not within files.

Most of the translation problems in the last week have come from
upstream, k3b tar missing .pos, kpackagekit using wrong templates,
darkroom having a broken Messages.sh, all of which we've fixed.  There
are also some ubuntu issues that I'm unsure about, is usb-creator
translated, why is the Ubiquity .desktop file not translated, but
dropping rosetta doesn't do anything for that of course.

Marketing
==
We're stuck in the difficult place of having an uncertain relationship
with Ubuntu, are we a derivative project to Ubuntu's main desktop or are we
one of several equal variants from the Ubuntu family?  I always
consider us the latter but I know others don't.

On promotion there are outstanding changes to our website that Ryan is
working on, we should indeed also do better to make update
announcments more human-readable, screenshots and apt-url would help.
And remember to make announcements user-feature orientated rather than
version number orientated.

Handling bug reports
==
I put off using apport for KDE apps because I suspected we didn't have
enough triagers and most bugs (should) come from upstream.  Using
apport was a bit of an experiment and we can easily enough go back to
using drkonqi if we want.  Getting sensible backtraces is the tricky
thing with drkonqi, anyone know if the download-debug-symbols for it
materialised?

Packaging flaws
==
I tink our usage of PPAs has settled into a sane fashion now.  I did
add "upgrade tested by" to our last batcave page to make sure they
were tested before release.  We should also be clear on the method for
backported packages, do we use the packaging from old backports and
update or do we use the packaging from the main packages and adapt it
each time, the answer will be different depending on where we are in
the release cycle.

I'm against merging more frequently with Debian because merging causes
bugs to happen, of course we should keep an eye on their packaging to
cherry pick useful changes, I have all debian kde svn commits go into
my inbox.

During the merge cycle for Lucid we should make an effort to document
our patches and make sure the relevant upstreams are aware of them.
The proposed list of KDE optional build-deps that we use/don't is a
good idea too.

Kubuntu application integration
==
replace Gdebi-KDE with kpackagekit was on the todo list for this cycle
but didn't get picked up alas.  kpackagekit itself could do with a
load of simplification being done on its UI of course.

software-properties isn't being dropped by Ubuntu Desktop, it's still
being used including in their new software centre.  

language-selector I've always been a bit unsure about, the design is
celeste's but contrained by it needing to be easy to implement.
possibly we should look into a developer-resources-not-an-issue
perfect design to see what can be done.

I don't think rewriting printer-applet in c++ is feasable (we havn't
completed the system-config-printer port even using the same
language), but there is some code missing compared to the gtk one to
stop it loading all python-kde libraries at startup which we should
look into.

update-notifier-kde should use notifications rather than systray icons
for sure (although presistent notifications in KDE have no indication
that they are linked to the "i" systray icon but that's a UI issue for
upstream).  re-writing in C++ would be possible but a lot of work for
not too much gain.

Probably enough for now :)

Jonathan