[kubuntu-devel] Project Timelord -- Initial consideration

[Harald Sitter]

Am Donnerstag, 22. Oktober 2009 16:23:24 schrieb Jonathan Riddell:
> 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.

_We_ did consider KDE 4 mature enough to migrate, _we_ wanted to push the 
migration in one dev cycle eventually leading to an incredible lack of QA. 
_We_ did decide to drop perfectly fine KDE 3 tools for their inferior KDE 4 
versions. I don't see where KDE falling behind itself does anything have to do 
with that. We, as the distribution creators, are responsible to shield the 
users from exactly that. We failed.

I completely agree on KDE, in the long run, turning out to be the best choice 
for a free software desktop. But, if we use this believe to reason an 
incredible amount of issues in the product, then we are sure as cat not using 
the right release scheme.
Long term mission + short term release cycles don't go well together.

As for the not using GNOME-esque apps... I think the logic there is flawed 
pretty much.
 * Why do we ship OpenOffice.org instead of KOffice?
It sure can't be because KO is broken (which would, applying the 
NetworkManager example, justify using the GNOME-esque app), because KO always 
worked pretty well manipulating its native formats.
Firefox does not have to be any more bound to GNOME than OOo, Synaptic 
(without recommends) also only depends on a minimal amount of GNOME stuff. So 
why is OOo > KO but Firefox < Konqueror, even though either OOo nor Firefox 
are even native GNOME apps?

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

Using Rosetta is difficult from a maintenance POV. I think I outlined all 
concerns in a document that is yet to be published, so I will not state them 
right now, but to sum it up: we are always one step behind upstream, we are 
always one step behind Ubuntu, 95% of the cycle no one gives a crap, bugs fall 
through the cracks unless the UTC catch them, the translation quality is at 
times worse than what upstram got.
We can only do so much QA, be it of languages the development actually speaks 
and thus can check or of actual time we have available to poke around.
I have spent considerable time on working out issues throughout the last 
cycle, so I am not arguing on assumptions but on observations I made.

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

* K3b -> pre-release software _we shouldnt ship_ at all IMHO,
* Kpk -> I assume this is translation domain vs. file name? If so, it probably 
still would be working if it wasnt for import'n'export
* darkroom -> If it was not for the fact that we need to create pots that 
would not be an issue. Also:
><JontheEchidna> putzing around investigating the darkroom ftbfs due to
> rosetta setup cost an evening, that's for sure. (It probably would have
> been too late even then though...)

So, as I see it, 2 out of 3 l10n problems in _one week_ were at least 
partially caused by the way our l10n works right now. And one was a complete 
waste of time since it did not even get imported into rosetta (darkroom is a 
universe app I have been told).

> Handling bug reports
> ==
> Getting sensible backtraces is the tricky
> thing with drkonqi, anyone know if the download-debug-symbols for it
> materialised?

Yes, at least for 4.4. AFAIK a shell script needs to be implemented, which 
IMHO is quite the overhead, though necessary for us since we have two types of 
debug symbols, those that are actually built in the archive, and those that 
are in the special dbgsym repo. In any case we need to take a closer look at 
it for Lucid.

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

Again, we can only do so much testing, and will certainly never cover all 
cases (especially for KDE releases, and especially for file conflicts on 
multiple levels). Scott also pointed out that we had a bit of a problem with 
security (needs to be considered I suppose?)

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

Agreed. Though we should look into ways to minimize the regression/bug 
potential of merges all together. Every issue that could be prevented is 
simply put wasted time and every issue that could be prevented keeps those 
wicked users that use a the dev series happy.

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

+1

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

Nonetheless the tool itself is quite alien in KDE, it does not even the apply-
then-close paradigm but GNOME's close-and-apply.

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

For both we need to look into it closely. Both don't do anything most of the 
time, yet eat memory like they were responsible for consistency of the whole 
universe. Jonny and I already poked a bit into update-notifier-kde, which 
should be renamed to kubuntu-notification-helper, and replicated the better 
part of the python app's features, so at least that should be a quite 
archivable target.

-- 
Harald Sitter
Kubuntu Core Developer
http://www.kubuntu.org