"This is akin to much of the Java methodology, which I can sum
up as "I'd like to use this third-party code, but my application is
too special to use it as is, so I covered it with Bedazzler Jewels
and Neon Underlighting, then bury my blinged out copy in my
application.". A fair amount of the upstream Chromium devs seem to
have Java backgrounds, which may explain this behavior, but it does
not excuse it. This behavior should be a last resort, not a first
instinct. What should happen is this:
"[google] hey, it sure would be nice if we could use sqlite in
chromium for our local db needs.
[google] hmm, the sqlite API doesn't mesh 100% with how I'd like
chromium to use it
[google] hey sqlite upstream, there are a few places where we'd
like to see API improvements so chromium can leverage it for our
[sqlite_upstream] hey google, so cool that you want to use our
* sqlite_upstream looks at google's proposed changes to sqlite
[sqlite_upstream] interesting, you could try using the foo_bar
function for your camel launching needs, but the rest of the
changes seem okay
* sqlite_upstream commits changes to the source tree in commit rev
[sqlite_upstream] Our next release will support that.
[google] yay! we'll tell people to either apply our patch or use
commit rev 12345 or newer.
"To be fair, when Google forks an upstream project in chromium,
they do write a README.chromium which summarizes the changes that
they made. This is technically, better than nothing, but much in
the same way that swimming in a pool full of angry, underfed,
electric eels is better than nothing when you're desperate for a
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.