Re: [webkit-dev] Open Design beyond Open Source
On 16-Feb-07, at 9:22 PM, Mike Emmel wrote: Actually their are five ports. QT OSX Gdk Windows and S60 you forgot the windows port. Of the five the windows port and gdk port are not progressing that well and don't have a lot of developer support. The QT S60 and OSX ports have a lot of developers with commit access and these port are proceeding so its 3 live ports and 2 half dead ones. Here is the link of what you have to go through to commit now. http://webkit.org/coding/contributing.html People wanting to do a new port are not going to go through this long trial program just to commit in fact that have not. The KDE team has pre-existing interest and both OSX and S60 are commercial. The two true open source ports gdk/windows plus the wx widget port have basically been failures so far. If you mean to say that the impression given off by the webkit project is one of we don't want you or at least we're not really interested in having more people join our project, I have to agree. I still don't get the feeling of a welcoming project. Is it a form of extreme paranoia that some new developer might introduce a bug? Maybe I'm not sure I consider that a valid reason though. So from and opens source perspective webkit is not a smashing success in drawing in the open source community only the KDE team has really contributed and they were the original developers. The S60 port also has a history of working with KHTML before webkit was made a open project. I wouldn't say so. I think the KDE contribution is effectively nil. The Qt port is distinct from KDE plans. KDE as a community has yet to find a way to work together with WebKit for reasons that I think you're also experiencing and perhaps not clearly articulating. Yes I'm writing this from @kde.org and have contributed a huge amount to KDE, KHTML, etc over the past 8-9 years. Until I have the KDE community feeling welcome and confident in participating, and until we have functioning code and development happening for a useful kpart, I don't see our Qt port as anything relevant to KDE. I'm trying to make it relevant, and I want it to be relevant, but it really isn't. I've had a webkit SVN account for almost 2 years now. I first tried to merge WebKit code back to KDE after all the KDE developers effectively gave up, and after successfully merging JavaScriptCore (with Maksim's help), determined that it just wasn't feasible to go any further without a complete replacement. I then started the current Qt port and managed to enlist several KDE developers to help me. At least one has given up again already, unsurprisingly. We made some great progress but it's an absolutely ridiculous development model as far as getting real work done. So far we had: 1) Work outside webkit SVN to start the port - webkit renames and refactors hit us hard 2) Port again, also outside of WebKit SVN (note: we were doing a very large number of commits/week. far more than now) 3) Spend far too much time merging from WebKit SVN, especially when things like renames and refactors happen 4) Eventually give up and merge back to webkit SVN 5) End up in a ridiculous situation of having one member of the porting team as the only person with rights to review the work. Interesting, since that person has no-one who can review his work under the formal rules. The guy who started the port, and the guy who invented KHTML altogether are not given review rights. 6) Work slows down drastically as developers are discouraged and are stuck in procedure that has relatively little value for the given situation. Not a good model. Maybe it works in an office with a couple of infrequent contributors, but it doesn't work so well for a distributed network of people trying to contribute significant amounts of code. I fully agree that some sections of webkit need strict review control, testcases, bug reports, and other formal procedures. I strongly support it in fact. The current situation is not limited to just this. Moreover, it feels very much like a Brusselized project, in stark contrast to where it came from originally. This feeling applies to ports as much as anything else right now. In my book this makes WebKit a failed open source project so far. I wouldn't go that far. I would call it a successful open source project with a rather closed community at the moment. Open source doesn't need community, but it sure helps. I really don't think there are any technical problems, just social ones. -- George Staikos KDE Developer http://www.kde.org/ Staikos Computing Services Inc. http://www.staikos.net/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Open Design beyond Open Source
I think this is a constructive email, George. Thanks for writing it. Specific responses below. On Feb 16, 2007, at 10:29 PM, George Staikos wrote: We made some great progress but it's an absolutely ridiculous development model as far as getting real work done. So far we had: 1) Work outside webkit SVN to start the port - webkit renames and refactors hit us hard There's not much to say here except that the porting layer was obviously still under construction. Trying to build a house on top of a foundation that is shifting is going to be hard. If the porting efforts had begun now instead of months ago when the porting layer was still in a high state of flux, there would not have been very much pain. 2) Port again, also outside of WebKit SVN (note: we were doing a very large number of commits/week. far more than now) 3) Spend far too much time merging from WebKit SVN, especially when things like renames and refactors happen These are problems that are solved by working in the WebKit SVN if the later problems you mention are addressed. 4) Eventually give up and merge back to webkit SVN 5) End up in a ridiculous situation of having one member of the porting team as the only person with rights to review the work. Interesting, since that person has no-one who can review his work under the formal rules. The guy who started the port, and the guy who invented KHTML altogether are not given review rights. 6) Work slows down drastically as developers are discouraged and are stuck in procedure that has relatively little value for the given situation. I agree that for work within a specific porting layer that it's clear that the rules should be different, especially in the earlier stages of development. I think there are several ways to address this issue: (1) Branches - This is the way Nokia has been working. I don't recommend it for any newly-starting ports, but it worked for Nokia because they had done an initial implementation already. However the rules are different for the Nokia branch. People have commit/review access for that section and can basically use it as they see fit. (If Nokia wants to make review optional, it's their branch, so that's fine). (2) I think we should allow for ports to operate in a similar fashion on tip of tree if they need to. Basically within platform-specific code (like say the Qt port), we should be much more open about granting commit access to interested contributors and let the people working on that port decide if they want to make review required or not. This would allow people to - for example - fix build bustage without having to consult anyone or seek review (assuming the fixes don't impact core engine code or other platforms in any way). For core engine code, being very locked down and paranoid is a good thing, but I see no reason to apply that paranoia to porting layers. dave ([EMAIL PROTECTED]) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Open Design beyond Open Source
Hey George, Thanks for sharing your concerns. On Feb 16, 2007, at 10:29 PM, George Staikos wrote: On 16-Feb-07, at 9:22 PM, Mike Emmel wrote: Here is the link of what you have to go through to commit now. http://webkit.org/coding/contributing.html People wanting to do a new port are not going to go through this long trial program just to commit in fact that have not. The KDE team has pre-existing interest and both OSX and S60 are commercial. The two true open source ports gdk/windows plus the wx widget port have basically been failures so far. If you mean to say that the impression given off by the webkit project is one of we don't want you or at least we're not really interested in having more people join our project, I have to agree. I still don't get the feeling of a welcoming project. Is it a form of extreme paranoia that some new developer might introduce a bug? Maybe I'm not sure I consider that a valid reason though. We really do want the WebKit project to be open to new contributors. We spend a lot of effort working on this. If we didn't care about having new developers join, we wouldn't have the whole public repository and web site at all. It is true that the WebKit project has somewhat higher barriers to entry than other large open source projects, like KDE. But I believe the barriers are lower than some others, like Mozilla. Here are the barriers I think we have: 1) We require code review for all changes. 2) We do not grant commit access automatically; we expect people to have a track record of being good contributors. Note that this is more about showing that you can work with others and are not a source of conflict or negativity. It is not about coding skills. 3) We do not give review privileges automatically. This is more about understanding project policies and having good judgment 4) We require all code changes that affect processing of web content to come with a regression test case (if it is possible to make one). I think getting a patch reviewed is easier than in Mozilla, where you need a review and a superreview and adherence to all review happening in bugzilla is much more strict (we often bypass that and do review via email or IRC for established developers). But perhaps it is harder than for KDE, where things are often committed without review. I think it is also easier to get commit privileges than in Mozilla. I checked some stats, and everyone who has contributed more than 5 patches so far this year already has commit rights. That says to me that the people actively contributing have the access they need. Now, it may be that some people were discouraged from even contributing in the first place. But that shows a lack of commitment to me. So from and opens source perspective webkit is not a smashing success in drawing in the open source community only the KDE team has really contributed and they were the original developers. The S60 port also has a history of working with KHTML before webkit was made a open project. I wouldn't say so. I think the KDE contribution is effectively nil. The Qt port is distinct from KDE plans. KDE as a community has yet to find a way to work together with WebKit for reasons that I think you're also experiencing and perhaps not clearly articulating. Yes I'm writing this from @kde.org and have contributed a huge amount to KDE, KHTML, etc over the past 8-9 years. Until I have the KDE community feeling welcome and confident in participating, and until we have functioning code and development happening for a useful kpart, I don't see our Qt port as anything relevant to KDE. I'm trying to make it relevant, and I want it to be relevant, but it really isn't. I've had a webkit SVN account for almost 2 years now. I first tried to merge WebKit code back to KDE after all the KDE developers effectively gave up, and after successfully merging JavaScriptCore (with Maksim's help), determined that it just wasn't feasible to go any further without a complete replacement. I then started the current Qt port and managed to enlist several KDE developers to help me. At least one has given up again already, unsurprisingly. We made some great progress but it's an absolutely ridiculous development model as far as getting real work done. So far we had: 1) Work outside webkit SVN to start the port - webkit renames and refactors hit us hard 2) Port again, also outside of WebKit SVN (note: we were doing a very large number of commits/week. far more than now) 3) Spend far too much time merging from WebKit SVN, especially when things like renames and refactors happen 4) Eventually give up and merge back to webkit SVN 5) End up in a ridiculous situation of having one member of the porting team as the only person with rights to review the work. Interesting, since that person has no-one who can review his work under the
