Chromium: Why it isn’t in Fedora yet as a proper package

“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
use-case
[sqlite_upstream] hey google, so cool that you want to use our
code.
* 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
12345 *
[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
quick swim.”

Complete
Story