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

Mon Jun 8 08:32:08 PDT 2009

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

------- Comment #207 from zuh at iki.fi  2009-06-08 08:32 PDT -------
(In reply to comment #206)
> > Noteworthy point here is that you are responsible for over 100 of those 200
> > messages, and quite likely more than 75% of the overall amount of text in the
> > comments.
> 
>  this should give you an indication of the complexity of the process involved
> in the development of this work.
> 
>  it should also show you the lengths to which i was prepared to go to educate
> people on request.

I don't think they asked for education. Furthermore, I'm pretty sure they
understood the situation with W3C DOM, JS extensions to it and their adoption
to the patch quite early so most of the repetetive commentary about the
JS-specific features (starting around comment #88)  were not needed.

>  much also of the comments show my shock and confusion at being both personally
> insulted by respected members of free software communities, and at the way in
> which the advancement of free software's strategic reach is being jeapordised
> by bloody-mindedness.

Free software allows you to take the code, modify and distribute it. So if you
think WebKit is disfunctional wrt advancement of free software's strategic
reach, you might want to fork the project to accommodate this. That way you not
bound by the processes and infrastructure of the current project maintainers.

>  it should also indicate the respect that i have for people who are patient
> enough to provide valuable technical input, even in the face of an increasingly
> stressful process, and even whilst at the same time teaching them (with
> unfortunately very harsh lessons) to be a tiny bit more cooperative and
> collaborative in the _strategic_ development and direction of webkit.

>From the comments in this bug I get the impression that they indeed have a
strategy, and you just don't agree with it. Which is naturally ok, as is the
project maintainer's right to only accept code which implements *their*
strategy.

> > So you are basically claiming that because you obfuscated the review process
> > with long-winded rants about why you are right and others wrong, you get a free
> > pass for your code.
> 
>  couple of things:
> 
>  1) does the above paragraph contribute to the project or does it aggravate it?
>  i would say that it both aggravates the project and also once again borders on
> personal insult instead of adding technical or strategic value.

I simply disagree with your assertion that the task is inherently so
overwhelming that it should not be subjected to the review process. I also
disagree that the amount of "comment spam" in this bug (most of it by you, mind
you) would be another reason not to make sense of the patch before landing it.

There is a good example of a too-large-to-handle patches and how to resolve the
issue in the Glib Unicode bug:
  http://bugs.webkit.org/show_bug.cgi?id=15914

There the patch was after multiple rounds split and now the first ones are in.
That would be how this work should evolve too.

>  please can i respectfully request that you refrain from making comments that
> aggrave the project.
>
>  please refrain from making comments that border on personal insult.

If my tone was too personal for you,  I apologize.

>  2) http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation
> 
>  correlation does not imply causation.  that there exists 200 comments does not
> imply the insulting conclusion that you deduce.

I have read each comment so my conclusions are not made by statistics of the
commentary but also by the content therein. In fact, please refrain from making
assumptions that I made my comments without understanding the issues concerning
this bug and how to resolve it. Throwing wikipedia links to fancy terms and
concepts that you seem to assume I don't know feels like questioning my
intelligence and intent.

> > Why not just split out the controversial bits of the patch (like the de-facto
> > standard features that you so crave) to get it reviewed and committed?
> 
>  1) pay me money, and i'll do exactly as you wish.

I would, if it would be valuable enough for me to get this functionality in. It
is not.

>  2) if you don't pay me money, fee free to contribute to the project rather
> than aggravate it.
> 
>  3) why don't _you_ split out the controversial bits of the patch that you
> claim that i crave.

I've wanted to help with this feature, but unfortunately lack proper time for
it currently. :(

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