4 ms·

I would generally agree, but to any observer it looks like SunSpider isn't being actively developed: http://bit.ly/lScLRi http://bit.ly/lScLRi - my correctness

by pbiggar 16y ago

I would generally agree, but to any observer it looks like SunSpider isn't being actively developed: http://bit.ly/lScLRi http://bit.ly/lScLRi - my correctness bugs have gone unanswered since August, - other mozillians bugs have not been fixed either (at least one since 2009), - the SunSpider svn logs show that there is no work being done on the sunspider tests themselves, since the release of 0.9.1 in January 2010, - the last fix to the harness was 5 months ago (which broke shell tests for everyone except JSC). If you [1] want to remain the "maintainer" you have to show that's you're maintaining it. While this isn't how I would have gone about it (and I was thinking about it), I can't really fault Google for this. [1] And by "you", I mean "Apple", not you personally.

sayrer 16y ago
They should still file bugs and ping the maintainers, at least.
- pbiggar 16y ago
  I agree that would be the right way to do it, and I'm sure that we [1] would have done it that way. There is a certain shoot-first-ask-questions-later approach to forking that, while unpleasant, is certainly effective. There are two ways Google could have gone: 1) Talk to Apple, file bugs, wait around for a year to see if anything is being done. Then threaten to fork, but wait when Apple says they're doing it, but they're really not, they're just trying to avoid a fork. Or worse, Apple would simply refuse, saying that it wasn't a good direction for the SunSpider benchmarks to go, which would be legitimate. Then Google is stuck with worse V8 scores forever. 2) Just fork it. They didn't cite a reason, but when asked they no doubt have a few up their sleeves. Now Apple is on the back foot, doesn't have a plan, and perhaps has lost maintainership of SunSpider forever. From a public perception point of view, this is a real winner for Google. They have better open source cred than Apple [2], and they keep V8 up-to-date pretty well. I would be unsurprised if people started reporting the forked scores from now on. That will probably depend on how they steward the project, for example by doing some trivial maintenance like the bugs we've reported on SunSpider. While I don't agree with this approach, I can see how it achieves their aims better. It's reminiscent of the launch of V8 or Google code, where the surprise is used to spur competition from the incumbents. With luck, Apple will update SunSpider like they suggested they would in 2009, there'll be a merge, everything will be forgiven, and JS benchmarking will be better. [1] for those watching at home, sayrer and I both work on the JS team at Mozilla [3] (he's actually my boss). [2] Google may have a closed development model for the V8 engine, but that's par for the course with Apple. [3] Nothing I say represents Mozilla, etc, etc.
podperson 16y ago
Indeed, all seems terribly quiet on the Apple JavaScript Engine front lately. For a while they were leading the pack (and, in some ways, they probably still are) but aside from Mobile Safari, not much lately.
- calloc 16y ago
  I'm hoping that is mainly because of the run-up to the new OS X Lion release.
othermaciej 16y ago
If they filed bugs and got impatient, I'd understand. This blog post is the first I've heard of this particular idea though. Your bugs are good ones and should be addressed. I will try to do an update soon. FYI, if you want a patch approved, you should flag it for review (and make sure it follows the style guide), your patch would have been noticed much sooner had you flagged it.
- pbiggar 16y ago
  > If they filed bugs and got impatient, I'd understand. I think it's acceptable to look at bugs others have filed to determine whether to file bugs. > I will try to do an update soon. Great, thanks! (I know you won't like this, but it sort of validates Google's approach. By making a big splash about this, they accomplish far more than they would have by filing bugs and waiting, or contacting you directly.) > FYI, if you want a patch approved, you should flag it for review Funnily enough, we're dealing with problems like this at Mozilla too - a contribution comes in, but is missed because the review flag isn't set, or it needs work, or whatever. We're adding dashboards and metrics and things to avoid this happening at Mozilla - and it happens a lot. I'll mark them for review now.

by pbiggar 16y ago

sayrer 16y ago

They should still file bugs and ping the maintainers, at least.

pbiggar 16y ago
I agree that would be the right way to do it, and I'm sure that we [1] would have done it that way. There is a certain shoot-first-ask-questions-later approach to forking that, while unpleasant, is certainly effective. There are two ways Google could have gone: 1) Talk to Apple, file bugs, wait around for a year to see if anything is being done. Then threaten to fork, but wait when Apple says they're doing it, but they're really not, they're just trying to avoid a fork. Or worse, Apple would simply refuse, saying that it wasn't a good direction for the SunSpider benchmarks to go, which would be legitimate. Then Google is stuck with worse V8 scores forever. 2) Just fork it. They didn't cite a reason, but when asked they no doubt have a few up their sleeves. Now Apple is on the back foot, doesn't have a plan, and perhaps has lost maintainership of SunSpider forever. From a public perception point of view, this is a real winner for Google. They have better open source cred than Apple [2], and they keep V8 up-to-date pretty well. I would be unsurprised if people started reporting the forked scores from now on. That will probably depend on how they steward the project, for example by doing some trivial maintenance like the bugs we've reported on SunSpider. While I don't agree with this approach, I can see how it achieves their aims better. It's reminiscent of the launch of V8 or Google code, where the surprise is used to spur competition from the incumbents. With luck, Apple will update SunSpider like they suggested they would in 2009, there'll be a merge, everything will be forgiven, and JS benchmarking will be better. [1] for those watching at home, sayrer and I both work on the JS team at Mozilla [3] (he's actually my boss). [2] Google may have a closed development model for the V8 engine, but that's par for the course with Apple. [3] Nothing I say represents Mozilla, etc, etc.

podperson 16y ago

Indeed, all seems terribly quiet on the Apple JavaScript Engine front lately. For a while they were leading the pack (and, in some ways, they probably still are) but aside from Mobile Safari, not much lately.

calloc 16y ago
I'm hoping that is mainly because of the run-up to the new OS X Lion release.

othermaciej 16y ago

If they filed bugs and got impatient, I'd understand. This blog post is the first I've heard of this particular idea though. Your bugs are good ones and should be addressed. I will try to do an update soon. FYI, if you want a patch approved, you should flag it for review (and make sure it follows the style guide), your patch would have been noticed much sooner had you flagged it.

pbiggar 16y ago
> If they filed bugs and got impatient, I'd understand. I think it's acceptable to look at bugs others have filed to determine whether to file bugs. > I will try to do an update soon. Great, thanks! (I know you won't like this, but it sort of validates Google's approach. By making a big splash about this, they accomplish far more than they would have by filing bugs and waiting, or contacting you directly.) > FYI, if you want a patch approved, you should flag it for review Funnily enough, we're dealing with problems like this at Mozilla too - a contribution comes in, but is missed because the review flag isn't set, or it needs work, or whatever. We're adding dashboards and metrics and things to avoid this happening at Mozilla - and it happens a lot. I'll mark them for review now.