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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 8 09:33:06 PDT 2009


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





--- Comment #213 from Luke Kenneth Casson Leighton <lkcl at lkcl.net>  2009-07-08 09:33:04 PDT ---
(In reply to comment #210)
> (In reply to comment #203)
> > > Why do you feel that this particular patch does not need to follow that
> > > process?
> > 
> >  david, thank you for asking that question.  parts of the answer have already
> > been made, a number of times, but i am happy to reiterate them here, and i
> > trust that you are asking this question in order to take this matter seriously,
> > and i trust that you will give the reasons outlined below serious
> > consideration. 
> 
> It was a serious question, yes.

 ok, great.

> > the work has therefore been done, i apologise, as pretty much a one-off
> > "fait-accomplit"; for this reason alone, it should be accepted as-is and then
> > worked on, slowly, in manageable chunks, to fix any known issues.
> 
> Although I have NOT read all the comments in this bug, I'm going to assume
> you've done a fair job of summarizing them repeatedly in recent comments.  To
> reiterate your position:
> 
> - You believe the patch should be landed as-is, then iterated upon.

 i believe that that is a realistic and pragmatic approach.

> - You don't have time to break up the patch into smaller pieces.

 ... and neither do the other people who have worked on it, see:

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

 also neither will, i believe anybody else be willing to break it up;
 because DOM is so entangled that to even _begin_ unravelling it is
 tricky.



> The reviewer(s) have said:
> 
> - The patch must be broken up into smaller pieces before being reviewed
> further.
> 
> I think the important take-away here is that no one has stated that the patch
> may never be landed, just that it needs to be broken up, reviewed and landed in
> pieces.

 that is extremely unlikely to happen.

 from a "high level", using empirical testing and using pyjamas-desktop,
 the patch can be proven and demonstrated to work, and provide the
 necessary functionality.

 two separate contributors (myself and also martin) utilised this "indirect"
 method of testing (using pywebkitgtk) to verify and validate that the code
 works.


> I'm not sure there's much more to say at this point until you (or someone else)
> can find more time to work on breaking up the patch.

 trust me on this when i say that after two separate groups' valuable
 time has been wasted on trying to fulfil reviewers' decisions that
 you are extremely unlikely to find any further contributors with
 the skills and the time to do any further work.

 i'm deeply impressed by martin and adam's contributions and attempts
 to work with the reviewers, but the skills and time required to handle
 over 600 auto-generated files is just... too much for free software
 resources to handle.

 and it's _this_ that you will, ultimately, come to realise, and you
 will, eventually, come to a pragmatic decision.  it make take another
 100 comments; it may take another year...

 so.

 i will continue to refer people to this bug report, asking them
 to make their views known on this decision.

 when the number of comments gets to 250+ and you simply get sick to
 the back teeth of saying "no! our rules are more important than progress!",
 and you decide to land this patch (or whatever revision i have at the
 time) as-is, do contact me, and i will be delighted to help you and
 other contributors to create smaller (and for them more manageable)
 patches that will bring the code back into line with the strict
 coding standards.

 lastly: before anyone decides that they want to criticise me for the
 above, bear in mind this: i have the skills to patch any code that i
 want to, to do what i want, how i want.  i can indefinitely maintain
 patched versions of webkit, patched versions of XULrunner, patched
 versions of pywebkitgtk.

 NOT EVERYONE has the time or resources or the confidence to do that.
 and the reason why i am not letting you - apple - get off the hook
 on this one is for THEIR benefit, NOT mine.

 so - do you, apple, want to help serve the free software community?
 or you want to serve yourselves?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list