OCT
24
2007

KHTML: a position statement

I guess sometimes one has to be direct. So, here is what I do and do not believe in:

I am not opposed to:

(1) Dropping our tree in favor of Apple's in general. I am quite aware of the tons of good things they've done (along with a few things I thought were poor decisions); however, I would only want this to happen after some concerns are addressed, and I, perhaps naively, expect that all those people going around talking about how it would be great, and how all those people and businesses are involved would lend a hand. I am a busy guy and my priority is to get things in shape for 4.0.

The truth is, we have done something like this with JavaScript. And why did it happen? In large part because George Staikos did a lot of the heavy work, and convinced me to help. He believed it was right, and he made it happen by working within the community, and doing some of the skull-numbing portions. Of course, it was easier there, due to smaller, less active, codebase, and since regression testing is more robust for programs than for mages. However, that didn't result in a single repository, but rather a close working relationship.

(2) Working with Apple. I do it in JS all the time. See above. We have a pretty good relation with them, where the ideas bounce back and forth, get developed in one repository, and then get incorporated into an another, usually getting improved in the process. It's an unorthodox setup, perhaps, but it lets us work at our own paces and styles and have some reasonable differences
based on those in our goals and value systems.

So what are my concerns, then?

I am opposed to:

(1) Dropping our source tree w/o a good undestanding of what's being regressed.

(2) Dropping our source tree w/o being sure that the interests of KDE community are going to be represented, and that the development setup will not be isolated from KDE contributors.
I do not think our interests can survive long term if we don't provide a way for people to get interested in web stuff when they originally didn't plan of it. This should actually not be too hard these days, because a lot of Apple people have earned our utmost respect, unlike some of the folks alluded to by the very last bullet

(3) Dropping our source tree in a way that drops API compatibility. It doesn't matter what tree the renderer is based on, one can still provide a libkhtml that's backwards compatible for all applications. The only thing that would cause problems for doing that would be using whatever TT ships, since it would have a different API and hide the internals.

(4) Having to rely on someone else to get bugfixes out to our users (or more importantly security fixes). Call me selfish, but if I spend a weekend fixing something, I want to know that it'll get to KDE users by a certain KDE release, and not when TrollTech feels like shipping a release. I want to be able to provide improvements with each KDE release, I don't care about versions of Safari or Qt including it or not.

I am more than disappointed by:
(1) Attempts by people who have never touched KHTML to bypass concerns of the active maintainers and contributors by misleading PR campaigns, such as articles making definitive statements on future of something, written without asking people working on it. Or, by defining maintainer as "someone who didn't touch something for 3 or more years".

Comments

Clear and free of unnecessary antagonism.

Although I do look forward to having the advantages of Webkit at some point, so far the explanation from the KHTML side why that might not be the best idea in the short term make a lot of sense. Webkit isn't all roses, and is only one part of a fully functional browser. At least for 4.0, KHTML is the way to go. Maybe once a webkit based browser appears for users, things will change.


By leos at Wed, 10/24/2007 - 16:45

I don't think anyone sane would propose to dump KHTML for 4.0 - no way. The fact Qt will have WebKit makes the whole issue a bit more complicated, imho, as it will be much harder to add stuff and have it in the next KDE release. So I think at least until there's a solution for that, KHTML needs to stay as it is now.


By superstoned at Wed, 10/24/2007 - 18:16

It would be harder to add stuff, yes, but is that a realistic problem? Only if it can be shown that losing control would unnecessarily hamper progress. So if it can be shown that holding on to KHTML would give us a lot of advantages ok, but so far what I've understood is that the WebKit code is more advanced (at least right now), has more people working on it and is supported by 2 companies who have an interest in making WebKit as good as it can get. So it seems that we would actually be gaining.


By quintesse at Wed, 10/24/2007 - 20:05

I can understand all your points except for #4.

Your wish to see fixes appear in the next KDE version seems a bit arbitrary. [Security] fixes happen all the time in QT code or other 3rd party modules, don't they? You have to wait for them as well, so what's different here? Maybe because you're not working on those? Fine. Then what about KDE releases? You have to wait for a lot of other people as well, you can't just decide to push out a new KDE release because you feel like it. It seems to me that is just the way things work. Now if it could be shown that either TT or Apple are often unresponsive with regards to fixes you'd have a point. (which at least shows it should be looked at and analyzed)


By quintesse at Wed, 10/24/2007 - 20:14

Stable KDE releases happen on a pretty fixed schedule. So if a user files a bug, I can make a judgement on when I can fix it, prioritize it, do the fix, etc, and be confident that they will get it soon enough. If we use whatever TrollTech ships, they can decide they don't want to update the sources for a while, because that's not the best decision for their customers. I fix things for KDE users, not anyone else, so I want to be able to get those fixes to the users, and to make judgement calls on what's appropriate stability-wise for each release. It's not uncommon for us to use a totally different solution on a stable branch and a developmental one.

Note that this applies specifically to the idea of not having a libkhtml and relying on TrollTech. It doesn't have anything to do with what renderer underlies libkhtml. If libkhtml were to be rebased on an another tree, we still would be able to do this sort of release management. Now, there would be coordination difficulties because people would want to freeze at different times, and all that, but that's a solvable issue rather than inherent one.


By Maksim Orlovich at Wed, 10/24/2007 - 22:09

You wrote;
> I am more than disappointed by: Attempts by people who have never touched KHTML
> to bypass concerns of the active maintainers and contributors by misleading PR campaigns

I understand your feelings here, you feel like people are getting on your part of the sourcetree. Making decisions about your work. And you are right that nobody outside the people hacking on khtml get to decide what to do with the code.
Or, in other words, the maintainers of the khtml sourcetree get to decide what happens in there. I get that.

The real issue, however, has absolutely nothing to do with the khtml code. I tried to explain this to your in another forum, and I'll happily repeat it here to make clear to everyone what the facts are so they can judge for themselves if you (the khtml devs) have been mistreated.

The real issue is one of choice, the choice that the end users and general KDE community HAS to use khtml. Surprise, I choose the technology that works best, not the one that traditionally has been the default. KHTML developers don't get extra rights on deciding what I should use just because they have been the default (read, only choice) for the last couple of years.

But, really, the choice in my personal opinion is one of maintainership. Not code.
Which maintainer does what is best for the KDE community. And while I'm sure you clearly have an answer to that question, probably based on technology and more, I have one specific metric;
What I really really care about is how easy going the maintainers are. How easy it is to work with a maintainer to get your patches in. And if you are abusive and generally annoying, you loose big time.

See, in my mind, Community comes before Code :)


By Thomas Zander at Wed, 10/24/2007 - 20:51

> my priority is to get things in shape for 4.0

and as user I like to thank you so much for that!


By Sebastian Sauer at Wed, 10/24/2007 - 23:14

I'm following KTHML-Webkit in Developers blogs.
I do not understand why all this discusion went for public.
OK, it's community, it more transparent, but should developers decide it in roundtable discusion?
It's very bad PR signal from KDE. Like a regular user I'm concerned about disagreements in KDE team.

Is there any policy in KDE about making such decisions inside KDE?

I'm not trolling, it just intresting for me. It is not much info about that in KDE page.


By dumas33 at Thu, 10/25/2007 - 06:51

The discussion is public, because outside forces has made it public. We tried to keep it private, but Troy decided to blow the story before a solution had been made.

Disussing this just doesn't seem to work in private.


By Allan Sandfeld at Fri, 10/26/2007 - 09:40