<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<br>
Benjamin Poulain wrote:
<blockquote cite="mid:52325E43.4000206@webkit.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 9/12/13 5:21 PM, Thomas Fletcher
wrote:<br>
</div>
<blockquote cite="mid:52325A97.7060904@cranksoftware.com" type="cite"><meta
content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
Geoffrey Garen wrote:
<blockquote
cite="mid:5B5A1EB3-342D-40C1-9A7D-ADF5A267908D@apple.com" type="cite"><blockquote
type="cite"><pre wrap="">Sure. We at University of Szeged who work on WebKitNix from this year
contributed many fixes to various part of WebKit: JavaScriptCore,
WebCore, Tools, …
</pre></blockquote>
<pre wrap=""><!---->
Thank you for this list. I started reading through it, but I noticed a high percentage of patches that were port-specific build fixes or port-specific features like support for legacy ARM chips. For example, “...on ARM traditional” (<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="https://trac.webkit.org/changeset/142616"><https://trac.webkit.org/changeset/142616></a>). Those patches are cost to core WebKit development, not benefit. </pre></blockquote>
I don't want to mis-interpret your statement here. Can you
clarify what you mean by "Those<br>
patches are cost to core WebKit development, not benefit."<br></blockquote>
I cannot talk for Geoff but here is my take.<br>
<br>
The WebKit code base has:<br>
-Core features used by everyone.<br>
-Core features used by many (e.g. curl, Texture Mapper, etc).<br>
-Port code that is only useful for some people.<br>
<br>
In the WebKit project, we value the first two. The port work is
necessary for everything to fit together, but that is not a
contribution to the project per say.<br>
It is always good to refer to the project goals as it summarizes
this quite nicely: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://www.webkit.org/projects/goals.html">https://www.webkit.org/projects/goals.html</a><br>
<br>
This being said, I think this thread is not longer very productive.<br>
If you are interested in things like removing ancient CPU
architecture, better start a new thread.<br>
</blockquote>
I disagree .. I think that this has been a very civil discussion on a
very relevant topic to the long term sustainability<br>
of WebKit as an OpenSource project via an easier barrier to adoption
into custom environments. I'm familiar with <br>
the project goals, which is another reason why you've never seen much
back contributions from @cranksoftware.com <br>
since most of our work does indeed end up being in the area of "Port
code that is only useful for some people".<br>
<br>
What this discussion is starting to center on is why the NIX port would
not be valued as a mainstream port that,<br>
like the other ports, validates that the implementation of Core features
(the first two items) makes sense in a broader <br>
context. <br>
<br>
Is the main concern about having maintainers for the port so it can be
kept up to date or is it more a concern that<br>
the technology direction that the NIX port represents, as an alternative
porting layer. That if people want to port to <br>
platforms they should drop down to a lower level and effectively start
copying and pasting the stub implementations <br>
from other ports?<br>
<br>
Thanks,<br>
Thomas<br>
<br>
<br>
<br>
<br>
</body></html>