[Webkit-unassigned] [Bug 16401] [GTK] GObject/C DOM binding

[bugzilla-daemon at webkit.org]

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


ddkilzer at webkit.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ddkilzer at webkit.org




------- Comment #201 from ddkilzer at webkit.org  2009-06-07 15:30 PDT -------
(In reply to comment #200)
> * review was not done for several weeks because it was not understood that a
> "?" has to be put next to patches.

Information about how to contribute to WebKit has been on the web site for a
long time:

http://webkit.org/coding/contributing.html

> * a review cycle began, which comprised several levels:
> 
> 1) compliance with webkit coding standards.  communication on exactly which
> parts of the coding standards were required to be complied with was in some
> cases not made explicit enough, but was eventually understood.

Coding style has similarly been documented on the web site for a long time:

http://webkit.org/coding/coding-style.html

> 3) an explanation of refcounting that was beyond the ability of three separate
> engineers to understand, and a request to comply with the c++ webkit standards
> on refcounting rather than the "mixed" manual approach, which the three
> separate engineers all attempted to implement, independently, without success

More about ref counted variables is available here.  It's not linked from other
pages on the site, but it's available via direct link and has been committed to
the svn repository for a while now:

http://webkit.org/coding/RefPtr.html

The rules for how to use RefPtr and PassRefPtr really do make sense once you
understand what they're doing.  It took me a while to fully understand the
pattern, and it definitely helped me to read through this document more than
once.

> * a request was made, by apple employees, to two separate engineers, to provide
> a much "simpler" patch [...].
> 
> the "arguments of last resort" being utilised by apple engineers were simply
> silence or to state "because we said so".

Everyone who contributes patches to the project must follow the same process. 
That includes making their patches of reasonable size and complexity for
reviewers to understand and comment on (and breaking them up if necessary),
following the coding style guidelines and writing regression tests whenever
possible.

Why do you feel that this particular patch does not need to follow that
process?


-- 
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.