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

Mon Jun 8 02:12:52 PDT 2009

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

------- Comment #203 from lkcl at lkcl.net  2009-06-08 02:12 PDT -------
> Everyone who contributes patches to the project must follow the same process. 
> That includes making their patches of reasonable size and complexity for
> reviewers to understand and comment on (and breaking them up if necessary),
> following the coding style guidelines and writing regression tests whenever
> possible.

1) coding style guidelines i perfectly understand and accept.  where it has
been possible to understand what is being requested, and where, in amongst what
is now 200 messages i have been able to _find_ the requests, i have complied,
because i understand completely the value of coding style guidelines.

2) the available testing resources - and the available _time_ to _create_ tests
- are limited.  the process by which the work was done and tested was by
utilising an empirical high-level process.

i apologise for not having enough time and not enough money to spend on
creating better, more acceptable test resources.

the testing and development process involves use of pywebkitgtk (an
intermediate library) and pyjamas-desktop (a high-level API).  by comparing and
observing the results of the operation of the 20 or so applications under the
pyjamas-desktop API against the "original" (pyjamas), i was able to empirically
gain a level of confidence that the work actually performed as expected.

[attempts to recommend this process of testing to the webkit developers were
met with scorn and derision, dismissed out of hand, being described as a "pet
project".  such belittlement of an empirical and comprehensive test process is
wildly inappropriate, as well as being part of an inappropriate personal
attack].

i mention this because just because this empirical test process is "different",
it doesn't make it "invalid".

if i had available time and money, i would go create some reassuring unit
tests.  i apologise for being a free software developer who does not have
access to unlimited funds.

i made the decision to bypass unit tests on the gdom_ code and even on
pywebkitgtk because i _trust_ the process which created glib and i _trust_ the
process by which codegen.py in the well-established python-gobject project
auto-generates python bindings.

so i saw no need to go reinventing the test process, and went direct to a much
more overall useful empirical test process.

that this process involves projects and code that are not part of the core of
webkit is, to be blunt, not my problem.

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

 1) the development of this work was a highly complex one-off that required
approx eight weeks of 11 hour days in order to complete _without_ losing track
of what was involved.  hundreds of classes required memorisation (which could
not have been done on a part-time basis or over a longer time period);
approximately 250 simultaneous editor sessions were needed, at one point, to
keep track of related files.

requests to "fit in" with a "simpler" process were, and are, therefore simply
not practical, on a task that was, and is, already monstrously complex.  one
attempt was made (GdomNode), and it became immediately clear that it would pull
in vast amounts of extra code and classes - GdomNodeList, GdomAttr and more).

a second independent engineering team were also requested to create a "simpler"
patch: the request by apple for _their_ time and resources to be spent was
_also_ denie.

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.

one other independent engineering team has already given up on trying to "fit
in" with the process; this should emphasise and highlight to you that this is
not .... see inappropriate and disrespectful accusations, in this, 2nd from
last paragraph:
https://bugs.webkit.org/show_bug.cgi?id=16401#c70

2) keeping track of issues has proven to be a nightmare (which i predicted it
would be, very early on) and the reviewers have repeatedly expressed
frustration at their comments being "ignored" when in fact they were simply
_not seen_ because there is _too much_ for one bug-tracker thread to handle.

and the reason for there being "too much" is: see 1), above.

you can see evidence of the frustration of the reviewers in their use of
language to diminish the value of the work carried out, in beginning to utilise
non-technical and non-strategic arguments, and in ignoring repeated requests
for comments, in an attempt to reduce stress levels.

there is a well-known and proven process by which the project can be made more
manageable: the use of a bugtracker and the use of patches.

however, it is not possible to have a bugtracker-within-a-bugtracker, and it
extremely impractical to use patches-to-patches, and to consider developing a
bugtracker-within-a-bugtracker and a patch-to-patch system _just_ for this
one-off work would be a waste of developer resources.

i started using github as a substitute but that is a "non-authoritative" source
which is being ignored.

for _this_ reason alone, it seems pretty obvious that the solution is to
utilise the existing resources in the best way that they are intended - by
creating smaller individual patches and having separate manageable bugreports. 
_but_, of course, that means that the work has first to be accepted.

attempts to utilise the bug tracker to keep track of issues that need to be
resolved in the patch itself (#20897, #20898) were requested to be terminated
(ironically to avoid confusion).

3) the glib / gobject language bindings do not impact on the core webkit
functionality in any way, shape or form.  why therefore should apple _care_
about them?  apple has its objective-c bindings.  apple has its own port of
webkit.

so for goodness sake stop being obstructive and stand aside; make your own
lives easier and let those people who _do_ care about the glib / gobject
bindings be able to cooperate and collaborate on the development and
progression of this strategically important functionality.  _without_
interference.

i fully appreciate and understand that it is desirable to stick to a known,
tried and tested development path and process.  however, unfortunately,
sometimes with something as comprehensive as what has been created, in this
instance, the easiest development process for the work itself _isn't_
necessarily the easiest thing to fit into the nice safe cosy comfortable
practices.

last but not least, in answer to your question, is this: look at the dates on
CodeGeneratorJS.pm, CodeGeneratorCOM.pm and CodeGeneratorObjC.pm.  they all
state Copyright 2006.

that means that those code generators have had _three_ years in which to go
through an incremental (viz: "safe") development process, and it is the glib /
gobject bindings which were left behind.  a catch-up had to happen, and it was
done in a mere eight weeks out of necessity.

tell me you don't _seriously_ expect any free software developer willing to
create glib / gobject bindings to go through some "nice", "safe",
"apple-satisfying" development process, to create some half-baked unusable bits
of code _just_ so that apple employees can get "up to speed" on how that
development occurred?

i trust that that's not what's being requested.  i trust that apple is not
asking free software developers to spend their time and resources on educating
apple employees on the workings of these glib / gobject bindings.

now.

having said that, here are some issues which this work has raised, which need
to be properly addressed, ideally before proceeding with this one-off work
being merged "as-is" as a one-off exception into the svn repository:

1) all independent issues raised need to be created as separate bugreports
(suggestion: dependent on this one, to keep track of them) preferably _before_
the work is merged.

2) the _strategic_ issues raised by this work need to be discussed, and
arguments involving sentences with the words "apple's vision for webkit
language bindings" will not be a part of that discussion.  apple is _not_ the
de-facto dictatorial decision maker for language bindings to something as
strategically important as webkit. the research material (listed in this
bugreport and requested to be reviewed _five_ times) showing that webkit will
be left behind if apple's dictats are obeyed _will_ be investigated and
discussed, amongst other things.

i trust that you will give these matters serious consideration.  i trust that
the time and resources already wasted by not listening to my advice earlier can
be clearly seen as an example of _why_ i advised that this work be accepted
as-is, and that further time and resources need not be wasted.  i trust that
you can see this clearly and that it is long overdue to move on to much more
exciting and adventurous issues such as adding SVG support and bindings to
HTML5 features.

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