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

[bugzilla-daemon at webkit.org]

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





------- Comment #71 from kevin at kubasik.net  2008-10-16 16:17 PDT -------
Ok, as someone who really does want to see this functionality exposed, let me
propose the following. We can agree that a lot of work has gone into this
patch, and it is a lot to ask that one person finish everything that needs to
be done, and pro-bono none the less. 

I am not overly familiar with the patch, or the inner workings of webkit,
however, I do know how to use an editor, and am more than willing to take care
of the cosmetic issues (license headers, code formatting, file naming etc.) if
someone else is willing to look at the more technical aspects that I'm not as
comfortable with. 

So how's about it? Are we willing to meet in the middle somewhere and get a
_very_ cool feature into WebKit?

(In reply to comment #70)
> (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.