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

[bugzilla-daemon at webkit.org]

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





------- Comment #70 from mrowe at apple.com  2008-10-16 15:22 PDT -------
(In reply to comment #69)
> dear sam,
> 
> the work done is extensive, comprehensive, and is "too much" for "the system"
> to cope with.  can i therefore recommend that, in order to make progress
> manageable, that pride takes a back seat?

It's a matter of code quality.  If the code is not up to our usual standards
and it is landed anyway, it becomes an ongoing maintenance burden that *we* as
a project have to shoulder.

> unless paid - cash - i will not be expending further effort to split this
> patch down into (non-functional) "bite-sizes".  you're paid _money_ to work
> on this code - to ask me to effectively hand-hold you through understanding
> of the functionality is demeaning to both of us.

You misunderstand what the review process is about.  It is about proactively
avoid bugs and bringing the quality of the code up to a reasonable standard. 
We are completely capable of reading and understanding the code.  It is because
we understand the code we've been able to point out the many outstanding issues
in your patch.

> regarding the outstanding issues: they are documented, here, post-review.
> every issue requested to be addressed _is_ addressed.

That is simply not true.  The coding style still does not match our
well-documented guidelines.  Files are missing license headers, and are not
named according to our conventions.  The patch contains many instances of
commented-out code. The ref-counting of wrapped objects is incorrect.  There
are changes to IDL files which are simply wrong.  All of these issues have been
raised before.

> that they cannot be conveniently found only serves to emphasis just how
> important it is that this code _be_ landed, and the outstanding issues
> addressed _after_ it has been landed.

As we have stated before, all patches must meet the minimum standard for review
before they are landed.  This patch is not yet at that standard, so it will
*not* be landed until it is brought up to that standard.  It's as simple as
that.

> addressed one issue at a time.
> 
> in convenient bugreport-sized chunks.
> 
> it's not possible to issue bug-reports within bug-reports and, until
> this code is landed, you will not receive my cooperation, time or energy
> _unless_...
> 
> unless i am paid cash to do further work.
> 
> then i'll be _delighted_ to help, and will do as _many_ bite-sized
> patches as it takes and is required.
> 
> no money - no work.  it's too much.  sorry.

Asking for payment before you will address review comments is completely
inappropriate.  If you don't feel inclined to do the work unless someone pays
you, that's fine, but please stop saying that we should bypass our review
process for your pet patch.  A great number of developers contribute to the
project, many without compensation, and every one of them follows the same
process for refining their patches before they can be landed.  There's no
requirement that you contribute to this project, and if you're unwilling to do
so without payment then perhaps this project isn't for you.

In short, if you're not willing to address the issues that we've raised about
the patch to sufficient degree to get the patch landed, then at least refrain
from taking the discussion in this bug even further off topic than it already
is.


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