[kubuntu-devel] Project Timelord -- Initial consideration

[Jonathan Thomas]

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 :)
> 

;-)

> 
> 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.

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 
things development-wise. 

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 
Rosetta.

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".

> 
> 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.

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
> materialised?

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 
totally broken.

> 
> 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 
either.

> 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-
notification-helper/trunk
Testing appreciated. :)

> 
> Probably enough for now :)
> 
> Jonathan
>

Jonathan