On Apr 9, 2010, at 7:14 AM, Adam Treat wrote:
On Friday 09 April 2010 06:24:51 am Maciej Stachowiak wrote:
Given what proportion of overall maintenance work on WebKit I done by
Apple, I don't think anyone is entitled to veto us adding a new API
Whaa? Who is talking about veto of Apple's work? Rather, I am
suggesting
that it would have been helpful if people in the broader community
had a
chance to review and discuss the patches before they were summarily
landed.
To be clear, I have not had a chance to review the patches (I'm
actually
pretty excited by the ideas and I've no doubt the work is technically
excellent given the people involved) and see what is going on before
they were
pushed into the tree. It just would have been nice to give the
*community*
more of a heads up and a chance to have a look and offer opinions.
This isn't
about 'Apple' and 'veto' so much as it is about a significant new
piece of tech
being added to WebKit without going through the common procedure
where a bug
is opened a patch is attached webkit-dev is notified and people have
a chance
to discuss and poke a little.
There were in fact bugs opened with patches attached, and webkit-dev
was notified before any of the patches were committed afaik. However,
the "new piece of tech" really is just a new API layer for the Mac and
Win ports. We are interested in other people being able to reuse this
technology, but fundamentally, this is an extension of our existing
APIs.
It just felt a little rushed especially so that the new stuff is
being landed
with style errors. I normally wouldn't quibble with style issues,
but others
have and new ports have been required to fix any and all styling
issues before
landing.
Agree, it was not good to commit with style errors and we should try
to fix them promptly.
layer. I also recall that when the Chromium API layer was added, no
one asked permission, you just let us know that it was coming. Which
is fine - API layers are pretty low cost, and I hope no one would
argue against a major contributor including theirs. What's more, this
is really a parallel version of existing well-maintained API
layers. I
do not like the implication that Apple should have to ask permission
for what we do with the WebKit API on Mac OS X. We do not ask the Qt
or Gtk developers to explain all their API choices.
Again, I think it'd be good to get away from 'Apple' vs 'Others'. The
community as a whole has some fairly common procedures for landing
large
changes like this. This just felt a bit rushed. And no doubt I was
a bit
taken by the name 'WebKit2'.
It was in retrospect not a good choice of name. We hoped it would be a
very boring choice. Think of it as WebKit/mac/async/ or something and
see if you might feel differently.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
