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

[bugzilla-daemon at webkit.org]

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





------- Comment #76 from mrowe at apple.com  2008-10-17 02:45 PDT -------
(In reply to comment #74)
> i would be very surprised if you've had any patches to webkit that
> have totalled 200k and 7,000 lines.
> 
> it's therefore outside of everybody's comfort zone.
> 
> you're therefore going need to make some allowances and run by
> a slightly different set of rules.

Luke, your condescending tone is getting tiresome.  I had been hoping after
reading previous comments that it was purely miscommunication, but it's reached
the point that it is clearly intentional. 

I'll try once more to help you to understand why our processes are they way
they are, and why this patch does not get special treatment.

The matter of patch review and our standard for the quality of patches that we
will land is not up for debate.  The size of the patch itself is not inherently
a problem, as we have many regular contributors that rework large areas of code
in patches larger than this.  The reviewers and regular contributors to WebKit
are clearly able to comprehend changes to a large code base, after all they
regularly work on a project containing over half a million lines of code.

The big difference between the patches that these developers contribute and
your patch is that these developers are very familiar with how to contribute
code to WebKit.  They have a deep understanding of the code that they are
working with. They understand what quality is expected of the code that they
write.  They contribute changes in chunks where it possible to do so.  They
follow our coding style guidelines.  You're new to the project, and have not
yet had a chance to learn how the project works, and how best to contribute, so
it's understandable that your first patches may require a little iteration to
be ready to be landed.

I understand that the review process can seem a little hostile and rough at
first, that it can be easy to take review comments personally at times, and
that it can be frustrating for someone to ask you to make further changes
before accepting a contribution that you have expended a lot of effort on.  The
goal is simply to ensure that issues with patches are addressed before they're
landed, that the developer improves their skills, and learns how to contribute
effectively to the project.  Smaller patches lead to quicker reviews with fewer
comments that need to be addressed.  This accelerates the learning process for
new developers, as they can quickly iterate on their initial patches to address
reviewer feedback.  This quick iteration in turn leads to the contributor
getting a feel for the process of submitting a patch to WebKit, and in my
experience,  greatly improves the quality of their subsequent patches. 

We have found that asking developers to make a little extra effort up front
pays off substantially in terms of the long-term health of the project, which
can be seen by the incredible speed at which development on WebKit progresses.

If you're not willing to work within the same framework as all of the other
contributors to WebKit then you will find it very hard to contribute to the
project.  If you feel the need to debate this further, I feel that it would be
better for everyone involved in the WebKit project if you were to simply walk
away.





Let's please keep the discussion in this bug to technical issues about the
patch from here on in.


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