On Thu, Jan 31, 2013 at 4:16 AM, Alexis Menard <ale...@webkit.org> wrote: > On Wed, Jan 30, 2013 at 6:28 PM, Eric Seidel <e...@webkit.org> wrote: >> I wish we only had one build system (it were easy to add/remove/move files). >> >> I believe changes like http://trac.webkit.org/changeset/74849 are an >> unhealthy sign for the project. Adam is not the only person who has chosen >> to empty files instead of removing them. The pain of updating 8 build >> system is so great, we jump through hoops to avoid it. Which means it took >> us months to move JavaScriptCore/wtf to WTF, and will take us years to kill >> WebCore/platform. >> >> >> I wish I felt like reviewers understood/trusted each other more. >> >> I’ve worked at both Apple and Google. The WebKit community is full of >> brilliant engineers. Yet I frequently feel a lack of trust in my (or >> others) judgement, or witness hot-headed remarks on bugs, lists or IRC. I >> don’t think it’s that people don’t trust me after nearly 8 years (!?) on >> this project, but rather that we forget, or fail to communicate trust among >> ourselves. Social problems are perhaps harder to solve for us technical >> types, but I worry that for many of us it’s just become “us” and “them” and >> we’ve stopped trying. >> >> >> I wish it were easy to work on feature branches. >> >> We have no good solution for features. For one-patch features, you do them >> on your own. For larger, you maybe use github or most likely you just land >> on trunk behind a #define. None of these have worked well. Some of this is >> the limits of SVN, but it should be trivial for someone to work on a new >> feature a long time, w/o endangering trunk or having massive merge pain >> every day. Other projects can do this. So should we. This is both >> impeding progress, and destabilizing trunk. >> >> >> I wish we didn’t have to worry about platforms we couldn’t test. >> >> It can’t be the job of the core maintainers to care about all the peripheral >> ports which contribute very little core code. Our code needs to be >> structured in such a manner that its easy for the core to march forward, >> while letting the ports catch up as they need to asynchronously. Platform >> support code shouldn’t even need to be in webkit.org! Porting webkit.org’s >> platform abstractions should be trivial, but core developers (which probably >> 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to >> worry about keeping all ports working. > > Sure. I'm wondering how you would define a "peripheral" port? Anything > not Apple or Google?
I guess I would go the other way and define some sort of "kernel" ports which should never be broken by a patch. Those ports are defined as the ones which added-up account for 90% or 80% or something of WebCore developers. The idea here is not one of exclusion, but rather one of productivity. We need to keep our WebCore developers as productive as possible, so we should not break their builds, but they shouldn't need to worry about breaking uncommon builds. As I've said in other mails, this is *completely our fault*. And by "our" I mean all of us who were around 6 years ago when we designed the porting layer. I think we didn't understand then how exposing the details of a port into WebCore would bind us. We can have our cake and eat it too! We can have lots of ports and yet never have to care about them (and never have them break!). But I don't believe we can do that with current WebCore designs, where WebCore knows intimate details about each port. :( In my dream WebCore would not have a single PLATFORM() #if. > Many "little" ports are very active every day, sure some of them does > not contribute as much as they should on common parts but some > companies behind these are just limited on resources. They are not > Google or Apple with an army of engineers who have time to take any > spec of W3C and implements it. Agreed! > In WebCore the contribution is pain mostly because the buildsystem. > For the rest if EWS goes red, in many cases it's a real bug, a real > problem. > > Coming from a so called "peripheral" port I find very frustrating and > demotivating that our contributions are devalorized the way they are > or our reviews discredited. Many of us contributes important feature > and improvements to WebCore and sure not as visible as Google or Apple > in terms of log but still crucial or important. I can only imagine. I wish it were easier for you, not harder. :( > I believe you and many people are not aware what "little" ports > contribute because we don't work on high visibility feature such as > Regions, Grid, FooBar W3C API. We do improve W3C compliance (CSS, XHR, > media queries, viewport interactions, @viewport rule, various work on > tests infrastructure, WebGL fixes) and I'm talking only of the people > in my company and I'm probably forgetting some work. The number of > contributions per day makes hard for me to see what others than Google > or Apple are doing. Oh, I'm quite aware. :) Depending on how you count commits, lines of code, etc. some very simple git log processing will show you that "other" contributors in aggregate contribute about as much to WebCore as @apple addresses do these days, which is a very non-trivial number! (Much of that may be caused by our bad-porting layer, as small ports probably contribute much more to WebCore/platform than @apple would need to, for example.) Again, this is our past mistakes, and our fault, IMO. It should be easier for you to have WebKit running beautifully on your port, not harder. > I tend to agree that some are not playing the game but for the ones > who try their best it's sad to be rejected like that. > >> >> >> I wish that the tree always built and tested cleanly. >> >> Other (much larger) projects than WebKit accomplish this. Yet somehow >> Google pays 2 full-time engineers to watch our bots and yet we fail. I know >> other companies do similar. Automated rollouts is one solution. >> Branched-based development, or trybots are others. But at the size and >> scale we’re at now, every minute of a broken tree, is 100x or more minutes >> of potentially lost developer productivity. >> >> >> I wish I felt like I could follow what was going on (and trust WebKit to >> guard the web, instead of depending on Apple or Google). >> >> We’re the leading browser engine, with hundreds of committers, any of whom >> can add an API to 50% of internet browsers with a single commit. I wish we >> had a public process for feature/web-api review. I wish I felt like both >> major companies were willing participants in such. (Google has an internal >> process, but it sees limited use, in part because it’s powerless -- a ‘yes’ >> from our process is not a ‘yes’ from WebKit.) I want to feel like I can >> better observe and participate in the development of our web-api (and trust >> that it’s being done well!) without scanning every changeset just to be able >> to comment post-facto. (This is also reflected in the fact that the >> features enabled by the major Apple or Google ports are wildly different, >> with seemingly little rhyme or reason.) >> >> >> I wish WebCore was not trapped by Mac WebKit1’s legacy designs. >> >> WebKit2 is obviously a step towards the future. But until we can kill the >> Widget tree, the insanely fragile loader complexity, and the limits imposed >> by the least-common-denominator on classes like ResourceRequest, we’re still >> trapped in the past. One of the things I’ve learned in working on Chromium, >> is that we were wrong many years ago to fold our platform abstraction >> (Qt-implementation) and khtml into one library. In a sand-boxed >> multi-process world, the rendering library is just a hunk of code running >> the same on every platform. And platform code has no place in our core >> engine code (aka WebCore). >> >> >> I write less out of pain, and more out of hope for the future. I believe >> all of these are solvable problems, but I believe we need the will to solve >> them. Apple’s recent announcement of WebKit2 lockdown is clearly one >> attempt at some of these. But for the other 50% of WebKit developers who >> don’t work on WebKit2, locking down WebCore is not a good solution. >> >> I think we need to work together to bring about some of these dreams, for >> the short and long term health of the WebKit project. >> >> Thank you for listening. >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> > > > > -- > Software Engineer @ > Intel Open Source Technology Center _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
