some notes about Safari team plans for WebCore and JavaScriptCore

[Dirk Mueller]

On Die, 22 Jul 2003, Darin Adler wrote:

Hi Darin,

First of all: thanks for the insightful and detailed reply. 

> - Our team needs to be able to control what goes into our tree; there 
> are at least some changes that happen in the KDE version that we don't 
> want.

Like, for example? It would be great that each time you spot such a change 
a short note could be dropped on this list. Its been awfully quiet here 
for the last few weeks, and I hope that this changes soon. 

There are also some changes in WebCore which we would like to avoid in our 
codebase and instead have them solved differently. 

> - Our schedules are different; a current example is that we have been 
> doing lots of active development, and shipped 1.0 recently. KDE head is 
> not considered stable at this point, yet WebCore has many differences 
> from the KDE 3.1 branch.

Thats correct, however there are also many changes in KDE 3.1. branch which 
are not yet in WebCore. Particularly this part makes merging of your changes 
a lot more difficult and is very frustrating. 

> - Our team uses a process where we require review of each change as it 
> is landed, which is different from the process used in KDE.

Just because some of the commits being made are not reviewed before the 
checkin doesn't mean that they won't be reviewed afterwards. And even a 
single person reviewing a change can hardly spot all regressions introduced 
by it, especially if he doesn't remember all the problems a certain codepath 
caused in the past. 

IMHO you make it sound far worse than it actually is. There are only very 
few people working on the KHTML codebase, and those who do already work on 
it for a much longer time than Safari even exists. 

I can understand your development process and I'm happy about it, but 
honestly the situation is slightly different for us, because we're not 
looking at the code for the first time ;-)

Anyway, the important part here is the regression-testing during 
development. In the past we never really spent enough time on maintaining
our own regression testsuite, instead we used others which already existed
on the web. Bigger changes which happened between major releases are never 
regression-free, and it took us considerable time to recover from them in 
the past (BTW, this is no different to the situation right now with HEAD 
after parts of WebCore changes have been merged). 

It looks like you spent a lot of effort into creating an own regression 
testsuite, so it would be very benefitial for both sides if we could work
on it together. This way we can proof that although our code bases are not
quite the same we deliver a render engine of comparable quality. 

> There may be some way of resolving many of these issues in the long 
> run, depending on how comfortable you are doing KDE development with 
> the policies we use on the Safari team.

Unfortunately I can only partially agree. First of all, KHTML development 
has very little to do with KDE development, even though it ships in kdelibs. 

I've to admit that I'm not too familiar with the Safari team policies and
I haven't seen much of these policies on this list. For example I didn't see 
patches being posted before review from your side, or bigger architectural 
changes being discussed with others here before they were implemented. In 
fact they were not even questioned after they were already in a released 
Safari code version. Is this part of the Safari team policy?

With KDE development, nontrivial patches are posted on the mailinglist, 
which is open for review and anybody is able to comment on it. A lot of the 
debugging and new features as well as design decisions are discussed on IRC, 
in some cases we travel the long distances between our living places to meet 
in person and discuss it directly.

In KDE development, we usually test for bugs in multiple branches and 
codebases and inform the individual maintainers for example about security 
or crash fixes being applied to the code base, so that they can do equally. 
I have not seen such action from the Safari team. 

I could go on with the publically browsable repository, the commit logs 
which are available for anyone or the public bugs database, but I think the 
message is clear, and anyway its not too important *how* we work, but
the important part is despite that that we *work together* (!).  



All KHTML developers have spent a lot of their free time to work on this 
project voluntarily. We all have sweat blood and tears and did not sleep a
lot while working on the code and we feel connected to this
incredible piece of software and a small reason is that
we devoted all our passion to this project. 

We've discussed this before, and we made clear that we understand and 
we deeply respect the burdens you have with having to stick to different 
release schedules and Apple specific development processes and I believe
you're doing a great job. 

We expressed clearly our willingness of cooperation in the past already, 
which naturally also includes adopting required policies from your side. I 
hereby like to repeat that we still want to adhere to this previous 
statement. 

Its not a really big secret that currently neither Lars or I have much time 
to spend on KHTML, thats mainly because we have day jobs to do and those 
demand a lot of time and energy from time to time, but we're still actively 
planing and discussing the changes necessary inside KHTML for future 
improvement. I would like to see the same happen from your side. 

Perhaps the goal of a common codebase was a bit too far fetched and 
illusionary, so lets not rush it for now. It might be wise to focus 
on the groundwork instead *right now* and then improve from there. 

That said, please let me state again that it would be *VERY* beneficial for 
both sides if we could meet during the hacking party of the Nove Hrady 
conference and talk directly about WebCore and JavascriptCore (so at least 
one of each team should attend). Its at least a magnitude easier to 
communicate and even only one or two days of concentrated work there can 
replace a whole month via mail. 


Thanks for reading,


-- 
Dirk