Thanks for sharing this. 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. +1 This is a hard problem. It is a problem worth solving. Do you have more thoughts on this, particularly since you know quite well how both Xcode and gyp work? I suspect this is one of those things that it would be hard to achieve consensus on since there are so many stakeholders. But it may be fruitful to have a "what if" discussion about what this might look like. > > > 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've done this for JSC JIT optimization work before, and I think it worked quite well. The pain of merging the branch back into trunk was bad, but the reward was that I had ~2 months of time where I didn't have to worry about breaking other people's junk. Merging only took a week. One week of pain in return for 2 months of bliss? I'll take that. I concur that we can do better on this. I would especially love to see feature branching and merging follow a review process as if it were on trunk. Creating a branch involves a bug and a review. Patches that land on the branch are reviewed. Merging is either reviewed or rubber stamped. > > > 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. +1 > > > 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 actually think this just goes along with the territory. Browser engines are hard. Browser engines that achieve the configurability and portability of WebKit: even harder. Maybe I'm naive but I think we're doing quite well on this front given the circumstances. I also suspect that this problem ought to be diminished with your other suggestions, particularly having more branch-based development, and especially if there was a magical way to simplify building. > > > 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.) This is made harder by the fact that a lot of the "API" is poorly specified to begin with, and the things we have to do to mold the API into a form where it doesn't break the web leads to dark and difficult to grok corners. I think a lot of this goes with the territory and perhaps just being more cognizant of the implications of the things we do is the best solution. > > > 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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
