[webkit-dev] Is the wxWidgets port maintained?
eric at webkit.org
Mon Feb 11 23:44:25 PST 2013
This entire email thread makes me sad.
I'm sad because we did this to ourselves (our porting systems/policies
are lacking), we did this very abruptly (the last port we kicked out
of webkit.org took a year?), and we don't have any clear policy for
this sort of thing (adding/removing ports in webkit.org).
I think this, and many recent threads on the subject, are symptoms of
the same problem:
We are at a point in WebKit (and have been for a long time) where we
are focused less on the Web Platform (via WebKit) being everywhere,
and more on that Web Platform being awesome. Maybe it's time we
clarified this in our goals doc? Our (my!) previous
platform-abstraction mistakes have also left us in an awkward position
where it is difficult for us to support 7+ ports with separate build
systems, and separate sets of constraints (however minor) on WebCore.
I think it is the right decision to de-couple all ports from the core
code, but doing that is going to take us a very long time.
I think that moving closer to one build system will help, but won't
help those trying to advance WebCore from having to deal with 8
different port APIs, 5 different networking libraries, 2 different XML
parser, 4 different GraphicsContext implementations, and countless
other configuration options!
I guess the point of this all is that I'm sorry. I'm sorry to Kevin,
and all the other ports that I've helped integrate with WebKit, that I
and others didn't sit down years ago and design better, more
maintainable porting systems for WebKit.
I think if we as a community are actively interested in maintaining as
many ports as we have (and welcoming new ones) we need to come up with
better ways to do so. And clearer policies for what it means to be a
port in WebKit.
In the specific case of Wx, I am reluctantly agreed that code with
only one(?) maintainer is pretty close to "dead" and thus per WebKit's
long-standing dead/commented-out code policies should be removed. :(
Kevin has been with us a long time, and asking him to "leave" in this
manner is saddening.
Of course saying Wx is "dead code", begs the question as to what is
needed for a port to be considered "live" in WebKit.org? With our
current porting architecture, I would argue that at least 3 full time
people are probably needed, and that this should be considered before
accepting new ports.
I'm not in any rush to see Wx removed, and I agree it makes sense to
let Kevin write the patches as much as he's willing. I think
certainly having to wake up one day to see that one of your Open
Source projects is "kicking you out," is pretty jaring. :( I hope we
can do this better next time, and maybe we should have a separate
discussion about what it means to be a "supported port" in WebKit.org
and what new/existing ports need to do to meet that bar.
As for the future of WebKit on Wx: I don't know enough about WebKit2
to know if it has a more easily portable/maintainable architecture.
For the port I work on (chromium), others haven't really "ported" in
WebKit.org, but rather port at a higher level -- Chromium's Content
layer or https://code.google.com/p/chromiumembedded/. Maybe one of
those options are a better solution for a port like Wx with limited
Again, my apologies to you Kevin for my part in all this.
On Mon, Feb 11, 2013 at 7:44 PM, Benjamin Poulain <benjamin at webkit.org> wrote:
> On Mon, Feb 11, 2013 at 6:17 PM, Kevin Ollivier <kevino at theolliviers.com>
>> To be honest, I think I know more about the wx port, and would probably be
>> better able to cleanly remove it from the tree, than you would. As I've said
>> from the start, I'll remove it if that's what people want, but I do think
>> the severity of this problem is being exaggerated, and going from posing the
>> question of project status to giving a one week eviction notice in less than
>> 24 hours seems a bit rash to say the least. I wish I could get paid good
>> money to spend my time doing things like creating patches to remove inactive
>> files from source trees. :) As it stands, though, this wasn't exactly on my
>> TODO list for this week as of, say, this morning, and I do have plenty on it
>> right now. I'm already even regretting how much time I've put into this
> I am sorry, I should have given more context.
> There is visibly a growing discontent in the community about the cost
> imposed from small ports. Just two weeks ago, there were 2 threads
> discussing the cost of "peripheral ports".
> I am convinced a part of this is technical. The project has not changed its
> policies while the number of ports was growing. While duplicated code and
> interfaces was okay when there were only 3 ports, it has become a pain when
> we have 7+ ports to updates.
> This weekend, I was looking at technical ways to reduce the problems, and
> the wx port looks like one of the issue. Everyone with whom I have discussed
> that today seems to agree.
> You said yourself "As things stand, I'd not only be okay with, but actually
> prefer, that no other port maintainers do anything to try and fix the wx
> build.". The best way to achieve that and reduce the maintenance for
> everyone is to have the wx port developed outside the tree. Which is why I
> propose to do the change.
>> To think, it was wx and GTK that started the whole WebKit porting
>> experiment in the first place, thanks to the gracious help of the WebKit
>> community, and particularly Eric, and now I feel like the project can't push
>> me out the door fast enough. ;-)
>> Please be patient, I will take care of it, but I doubt I will manage it
>> this week.
> In his email "WebKit Wishes", Eric said "It can’t be the job of the core
> maintainers to care about all the peripheral ports which contribute very
> little core code."
> I also think it is just not fair having hundred of peoples taking care of
> updating the port.
> There is no rush to move the port out of the tree. I suggested this week in
> order to have a definite timeline but there is no urgency. If there is
> interest in the wxWidgets community to make the port actively developed,
> that would be a great solution too.
> You do not have to do the change by yourself. I'd be happy to start if that
> helps you, and you can refine the changes.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev