On Feb 16, 2007, at 1:43 PM, David Hyatt wrote:
On Feb 16, 2007, at 8:28 AM, Alp Toker wrote:
Far from causing divergent forks and fragmentation, Mike is
proposing a way to avoid each of the concerns you listed. I really
don't care what version control system gets used, but I do care
when a reasonable suggestions gets shot down so lightly.
Nobody "shot anything down." As Maciej said in his message, if you
want to make a public fork, there's nothing preventing you from
doing so.
Here is what I actually do think. I believe other project leaders
like Hyatt and Darin share many of these sentiments, but I speak
mostly for myself:
1) We are strongly in favor of a unified development effort. Many
organizations and individuals are interested in WebKit and we would
like to encourage them towards development on the trunk in the main
repository. We are willing to make changes and to work directly with
other organizations to make this possible.
2) We are not really interested in promoting or encouraging separate
repositories. Anyone who wants to make one is free to do so, and we
will not trouble or criticize you. But we will not encourage it as
the way to go.
3) We would like to share plans and design collaboratively. This is a
challenge as development continues to becomes more distributed and
less Apple-centric. So far we haven't done a great job of putting
design documents or plans about development direction on the wiki.
Right now, with our stabilization focus, it's hard to find the time,
but I think you will find more of these over time. Darin and I have
already discussed writing intros to some of the basic classes like
RefPtr, Vector and HashMap. We also have some overviews of the code
structure from various presentations that we could share.
4) We are not afraid of large structural changes. If you look at the
development history of WebKit you will see we have made many large-
scale changes. Even compared to the Safari 2.0 version of WebKit, the
current code has been majorly changed. We are not afraid of newer
contributors coming in and making big changes as well, if they are
justified and the design is discussed.
5) We think unity on the core engine code (the actual web
technologies like HTML, CSS, JavaScript, DOM, XML, XHTML, SVG, XPath,
and so forth) is more important than unity on support libraries like
networking and image decoding. For facilities that are already
present on many operating systems, we lean towards reusing the system
facilities rather than building our own full infrastructure from
scratch like Gecko does. That's an important part of what makes the
code suitable for limited-resource devices. That being said, we may
find that more code needs to live in the engine over time, and we are
not especially religious about the way things are partitioned now.
6) We will tend to give more weight to the opinions of those who have
already been significant contributors to the project. If the first
thing you bring to the project is a plan to change the project's
philosophy and organization, we will not be as open to it as we would
be if you started out bringing a bunch of code and testing. The
WebKit project is a meritocracy, not a free-for-all.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
