[Webkit-unassigned] [Bug 26379] Reconsider image decoding architecture/APIs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=26379





------- Comment #20 from bfulgham at webkit.org  2009-06-14 16:38 PDT -------
(In reply to comment #18)
> Unforking Chromium meant breaking Gtk+, WX, EFL, Torchmobile Windows CE. The
> cost of you "unforking" is that _now_ every port needs to copy and paste (fork)
> +115 lines of code. It is not a fair trade.... there is no reason to create
> this mess.

Can we please tone down the hyperbole?  Let's review the actual events:
1.   Unforking only broke GTK+ very temporarily.  By the end of the day (PST)
Friday the Windows Cairo and GTK+ code was in great shape and working better
than ever.
2.  Once Kevin Ollivier was available on-line, Peter was able to get the
wxWidgets port working properly and I believe things are fine there as well.
3.  As for the EFL and Windows CE ports, these are basically Qt ports, so this
sounds akin to arguing that "pkasting broke the Qt port, and he also broke the
Qt port and the other Qt port to boot."

I don't think it's reasonable to demand source-level compatibility with
projects that are not part of the WebKit tree.  Do you expect developers to
scour the web searching for WebKit forks that might be affected by changes? 
Should we feel guilty about breaking the code for groups that don't respond on
the mailing lists and don't communicate on IRC?  For that matter, where is the
Qt build bot to help ensure that although architectural issues might be
introduced, at least build and stability regressions will not occur?

Finally, I disagree that "every" port must create a forked file.  It is more
accurate to say that "some graphical backends needs an implementation".


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.