On Wed, Jan 30, 2013 at 1:57 PM, Maciej Stachowiak <m...@apple.com> wrote: > > Hi Eric, > > These are great thoughts. I agree with you on all points. One informative > comment below: > > On Jan 30, 2013, at 1: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. > > > 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). > > > In designing WebKit2, we tried to avoid some mistakes in the WebKit1 Mac API > design (such as exposing the underlying network library, exposing our NSView > hierarchy as part of the API, and giving too much salience to frames). While > we can't remove those parts of the API entirely, if we get more Mac API > clients onto WebKit2, then the performance of these details of the WK1 API > becomes less critical, and we can simulate them in ways that have lower > performance but also less impact on WebCore.
Do you have any pie-in-the-sky guestimates as to when in the future we may be able to release ourselves from WebKit1 API constraints (through this current WK2 path)? 1 year? 5 years? 10 years? > 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 > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev