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

Fri Oct 17 04:37:25 PDT 2008

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

------- Comment #77 from lkcl at lkcl.net  2008-10-17 04:37 PDT -------
(In reply to comment #76)
> 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. 

 it's nothing of the sort.

 i think ahead - a lot - and then i assume that people will be able to
 keep up, and fill in the gaps.

 so, i've reached the conclusion - without necessarily explaining everything -
 that the most _convenient_ way forward is to relax some of the requirements,
 and to try a different approach.

 if you're unable or unwilling to try a different approach, and are unable
 to work out for yourself that a different approach will work, then i cannot
 be of further assistance to you, and will wait here patiently until you
 have exhausted all approaches (that i have already anticipated will be
 problematic and/or not work).

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

 i understand the process.  i do not have an issue with the process.
 i respect the process.  i appreciate the process.  and, i have read every
 word, below, to ensure that i am not missing anything.

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

 i have considerable experience with non-egoistic code development,
 so i am not taking it "personally".

 what i _do_ have a problem with is when the ball is dropped.

 i've answered every single one of the issues raised by review, and you
 haven't even _looked_ at my responses, to say either "no, i insist" or
 "oh - i see, yes, we're not going to be able to deal with that" or
 "hmm, i see... well, we're going to let that one pass and we'll raise
  a separate bugreport about it, to make sure it's not forgotten".

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

 i don't mind making changes that are non-disruptive to the functionality.
 simple things that make the work easier to maintain.

 i _do_ mind making changes that disrupt the contribution's future
 maintainability.  for example, removing reminders of issues that will at
 some point need to be addressed, or removing code that was copied from
 another location, which has justifiable reasons for being there, but
 because now it's being added for exactly the same reasons, somehow it's
 now not ok.

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

 well, unfortunately, in this instance, the amount of work required to
 create "working" code - self-consistent and _useful_ code - was considerably
 higher than a "single small" patch.

 there _was_ no way to make a "smaller patch" and still provide
 "useful and working functionality".

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

 i already have.  if someone pays me money, i will be absolutely _delighted_
 to work within the framework as all of the other contributors to webkit.

 if someone does _not_ pay me money, and i work on this project further,
 working within the framework that all of the other contributors to webkit
 do, then i will end up bankrupt, on the streets, and unable to pay for
 food to put into my mouth.

 you can't ask me to do that.

 my gift to you is to provide working code that opens up webkit's reach in
 a really exciting way.

 if you are unable to appreciate or accept that gift, by asking that it be
 supplied in a specific way, by asking for _more_ from me - that's not really
 ok, is it?

 if you're willing to read my review-responses, and respond to them, we
 can move forward.

 if you're not, then i trust that you will work out all of the issues,
 yourself, and, when you re-encounter the issues i've _already_ faced
 (and answered), i trust that you will find appropriate solutions and,
 if you can't, will have the good sense to ask my advice.

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

 great.

 good idea.

 now.

 have you read my comments and responses to the reviews?

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