Linux Today: Linux News On Internet Time.

More on LinuxToday

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

Dec 02, 2009, 15:02 (0 Talkback[s])


Desktop-as-a-Service Designed for Any Cloud ? Nutanix Frame

"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

Related Stories: