[webkit-dev] WebKit2 build breakage
mcatanzaro at igalia.com
Thu Sep 1 20:18:23 PDT 2016
> The difference is that the GObject bindings are a seriously difficult
> issue for Apple that materially slows down their development (or at
> least appears to me to do so). It's impressive how much extra effort
> Apple devs (hi Chris) have spent trying to keep our bindings building
> (thanks!), but I don't think it's reasonable to expect them to do so.
> As much as we appreciate it, really nobody should be spending an
> afternoon uploading speculative patches to try to please our bindings
> generator. Anyway, if we freeze the API, this becomes a moot point.
Hopefully this will be much less of an issue now that we no longer
generate the GObject bindings.
> WebKit2 is totally different. When WebKit2 breaks (which has
> fortunately become much rarer nowadays than it used to be) it's
> something very very easy to fix -- a function gains an extra
> or a pointer becomes a reference or something -- and it just feels
> borderline spiteful to not spend five minutes with 'git grep' to
> breaking us. It's not as if WebKit2 is somehow less important to us
> than WebCore....
This was an issue again today.  To be candid about this, we all know
there's just a couple developers who routinely and intentionally break
other WebKit ports. This is not appropriate behavior in a free software
project. Please stop.
(I'm grateful that the vast majority of developers at Apple try to
avoid doing this.)
I'd like to formally propose we allow rolling out commits that
introduce build breaks in WebKit2, just like we do everywhere else in
the WebKit project. WebKit2 is an integral component of all modern
WebKit ports. It's not special, and it doesn't make sense to allow this
nonsense anymore. You can take a few minutes to update other users of
the API you're changing. Or if something is tricky (clearly not the
case here), you can wait for other developers to handle it for you.
It's not like we're inaccessible.
More information about the webkit-dev