3 ms·

It's Apple's (and Google's) modus operandi. They work in secret, and then they make huge code drops every so often.

• dchest 15y ago
  https://bugs.webkit.org/show_bug.cgi?id=75812 https://bugs.webkit.org/show_bug.cgi?id=75812
• olliej 15y ago
  If you actually look at the commit logs for javascriptcore you see all development goes on in public, all patches follow the webkit review rules (you can't do an unreviewed code dump, and large code dumps aren't pleasant when you need reviews). JSC is developed in the open, everyone can see the work we're doing, and the progress we're making, as we're making it. If you had actually followed the link you would have seen a change log pointing to a bug on bugs.webkit.org that shows the huge amount of (public) work that preceded actually landing this https://bugs.webkit.org/show_bug.cgi?id=75812 https://bugs.webkit.org/show_bug.cgi?id=75812 . Additionally there was substantial refactoring in multiple commits leading up to the final landing of LLInt in order to reduce the patch size as much as possible. The reason the LLInt landed as a "code dump" is because that is the minimal size possible - you can't land part of an execution engine, as by definition part of an engine is not sufficient to pass tests. As it is, this is only 32 bit for the simple reason that 32-bit x86 is the easiest way to stress register allocation, our value encoding requires two 32bit registers per value and 32bit x86 has very few registers. TLDR; You can't really do massive codedumps in the webkit repository, the commit rules make it very hard. Alas some patches are intrinsically large though as a partial patch won't be sufficient to pass tests, but even then we don't like them.
  • ootachi 15y ago
    My apologies then. Google does do that with V8, but your practices sound great.