[kubuntu-devel] Project Timelord -- Initial consideration
echidnaman at gmail.com
Thu Oct 22 23:04:34 BST 2009
On Jueves 22 Octubre 2009 10:23:24 AM Jonathan Riddell escribió:
> Just when I was thinking we should be coming up with plans for Lucid
> here comes a big one ready formed :)
> 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.
I have been thinking about what it would take to make this happen technically.
It would include:
- Making binarypkgmangler not strip translations from KDE packages (perhaps
check for the package including debian-qt-kde.mk or kde.mk)
- Removing desktop translation domains from debian/rules of KDE-related
packages in main (Could be done during merge times)
- Stop debian-qt-kde.mk and kde.mk from pkg-kde-tools from including
kubuntu.mk. (We would not want to remove kubuntu.mk entirely, in case we
decide to ever revert)
- Make language-selector install kde-l10n-* by default (It really should do
this already, tbh)
All in all, technically I don't think it'll be too bad. It is a bit of work,
but necessary all the same. Currently we just don't have the manpower to
support the Rosetta stack.
> 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.
K3b not shipping translations is understandable, since it is alpha software.
This is really more of our fault for shipping it as such; it's more of a
problem with our package upgrade policy. Definitely we should take steps in
the future to prevent this sort of thing from happening, but these are mainly
separate issues than our use of Rosetta.
Darkroom is a perfect example of the unmaintainable overhead the current
Rosetta stack incurs. Darkroom, being in universe, never would have received
any benefit from having Launchpad handle translations. This means that this is
not really a problem with the translations, but a problem caused by our
special translations stack.
The main issue with darkroom was that when we transitioned to new cdbs rules
that quilt.mk was neglected from being included, and so our existing patch
that already fixed the broken Messages.sh file was not being applied. While
this is most certainly a quality issue on our part, (read, my part,
unfortunately) that we had to patch Messages.sh in the first place for it to
compile shows the overhead Rosetta brings. I spent the greater part of an
evening figuring this out, which I really should have been using to do better
There are also a handful of packages in Universe that do not have Messages.sh
scripts, and while it may reflect an issue with upstream, it is no reason to
make extra work for the poor soul trying to work with the package. (Who unless
they have knowledge of the workaround in pkg-kde-tools, may not figure out how
to fix it)
Figuring out why Rosetta didn't import a translation template, why it exported
one incorrectly, or why translations are broken even after being exported
properly is also very time-consuming. I know that both Harald and myself have
spent a lot of time figuring out why things are broken that could have been
spent on better things if we stuck to using upstream translations.
As noted in the Timelord Announcement, we really need a translations team to
do proper Quality Assurance. While a developer keeping an eye on how our
translations differ from upstream would certainly be better than not doing so
at all, we really need native speakers to check to see if they are actually
quality changes. We also know that we have lost many translators because of
the inconvenience of the Rosetta translation interface. I believe that several
of our German users can vouch that Rosetta's interface, in junction with it
breaking everything in the past, was they key reason that we no longer have a
German translations team for Kubuntu. When soliciting translations help for
the kcm-gtk software, I have also been told that at least some translators
would contribute translations to kcm-gtk, but won't because of our use of
The use of Rosetta is really detrimental any way you look at it, from a
technical to social point of view. It may be a bit of work to reinstate the
use of upstream translations, but if we are ever going to have great
translations this is a must. As long as we have sub-par translations, we will
never have a great standing with international users, who are one of the main
targets of "Linux for human beings".
> 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.
While I hear the bigwigs of Ubuntu showering love upon the Kubuntu name in how
we are equal, I do believe that we are treated as a second-class citizen
marketing-wise. Ubuntu has been more considerate this cycle in technical
issues, (e.g. they fixed KNetworkManager for NM 0.8 and did not switch
policykit over to policykit-1) but I do think that we do get at least a
little bit shafted in regards to marketing.
> 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.
Awesome, glad this is in the pipeline. Maybe if all existing Kubuntu
developers were a bit more vocal on the blogs about what's going on in
Kubuntu, it could bring more awareness that we are actually a distribution
that cares. :)
> 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
I know that Debian should have a script for this, but I do not know if we have
done a merge since it was added. Something to look in to for 10.04 definitely.
We really, really do not have the manpower for using apport. I would be very
much in favor of ending this experiment, and saying that we tried it for a
year and it just didn't work out. Maybe in the future after we grow a bit we
can consider picking it up again since, in theory, it's a great idea.
> 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 have been quite pleased with the improvement in our KDE packages this cycle,
but I would welcome Harald's proposed package upgrade test automation. (Will
have to check if I remembered to add that to the Timelord Announcement)
I think that backporting for the first KDE release, then using that backport
and updating would be better than re-backporting each time. There's just too
much chance for release+1-specific changes slipping through. I know that this
happened with our apport-kde patches for karmic. Jaunty didn't have apport-
kde, but apport-qt, and this caused problems where the report bug feature was
> 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.
Sounds reasonable. With more aggressive QA maybe in the future we could merge
often, but for now this is a quite sane course of action in my opinion.
> 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.
Probably would be a good thing to do this cycle. The less extra stuff we have
to maintain, the better.
> software-properties isn't being dropped by Ubuntu Desktop, it's still
> being used including in their new software centre.
Ok, good. Rewriting it would be quite resource intensive.
> 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.
The whole "accessing it as a separate application by launching it from System
Settings with a button" thing seems a bit alien, even if the dialog itself it
well-designed. I can't imagine the separate dialog being ideal for netbooks
> 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.
This is less of a problem, but using 10MB because I may eventually think of
printing seems way less from ideal, especially on low-RAM systems.
> 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.
Actually, there's a lot to gain from this. Harald and I have started a C++
kded-based rewrite, called kubuntu-notification-helper, and it has yeilded
great performance benefits. At idle it uses a mere 0.3 MB of RAM, compared to
update-notifier-kde's usage of 10 MB of RAM at idle. This represents nearly
50x less memory usage. Even at kubuntu-notification-helper's heaviest RAM
usage I've only ever seen it use 6 MB of RAM, total. (upgrade hooks... needs
work to be less hungry)
I estimate that, overall, all of our python bits (jockey, printer-applet, and
update-notifier-kde) increase the default RAM usage by 25-30 MB, even when the
programs are just waiting for things to happen.
While kubuntu-notification-helper is definitely still a Work in Progress, it
already reliably notifies for apport events, required reboots, and upgrade
hooks. Upgrade hooks still need work, but they do manage to work better than
they do with update-notifier-kde, where upgrade hook notifications have not
worked since 8.10. Aside from that, all that needs to be done for kubuntu-
notification-helper to become a viable replacement for update-notifier-kde is
to implement restricted install notification and for a python helper app to
check for distribution upgrades to be created/integrated.
You can check it out at: https://code.launchpad.net/~kubuntu-members/kubuntu-
Testing appreciated. :)
> Probably enough for now :)
More information about the kubuntu-devel