This causes features to sometimes just "go missing" for long periods of time, if the original committer (i.e. the code's only advocate with commit privs) A. works for some big company that's not Google or Apple, and thus has other responsibilities; B. was just "helpfully" pushing the code they wrote for their own private fork of Webkit/Chromium; and C. doesn't much care what happens to it in the OSS project after that.
- any feature, no matter how small, has some cost (code size, testing, cognitive complexity, etc), and frequently contributes in some way to making the product and/or other development slower. - as a developer, user, product manager etc, it's up to you to figure out how to convince other people your change is a good idea, and how your change will be maintained going forward, if you have to switch projects for instance.
We have a long history on the Chrome team of deleting code that was only relevant to one or two developers and those developers moved onto something else. It's the only way to stay sane at our scale, frankly, and we don't even do it as much as we should.
I guess I'm too used to DCVSes with light feature branching--I would expect every piece of code to end up in your codebase as a result of a merge commit, and be backed out by backing out that merge commit--leaving the unmerged feature branch itself available indefinitely if anyone ever does want to take up the reins on that particular idea again. As it is, it feels a bit like a publisher shredding every manuscript that contains a typo ;)
---
Oh! And since I have a Chrome developer on the line, so to speak: when are we going to see nearest-neighbour image-scaling (https://bugs.webkit.org/show_bug.cgi?id=56627) in Chrome for Windows/Linux? As it is, I get an itch whenever I see pixel-art emoticons with CSS- or device-zoom applied to them. :)