[webkit-dev] Is the wxWidgets port maintained?

Tue Feb 12 09:29:31 PST 2013

On Feb 11, 2013, at 11:44 PM, Eric Seidel wrote:

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

As a port maintainer, I totally agree. I've been talking about how I switched to waf for the benefits it offered the wx port, but it is also true that part of my reason for going that route was to see if I could find a way to get out of the business of needing others to update my port's build system and code. It's a very gracious policy, but I don't like the feeling that just by being in trunk, I'm putting a fair amount of the burden on others to update my build system, etc. for me. The build system choice was my decision, and accordingly, it should also be my responsibility to maintain.

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

As someone whose worked on cross-platform software for over a decade now, I can say that WebKit has, by and large, done a very good job of managing the complexity inherent in supporting multiple ports. You do it far better than wx does in some respects, to be honest. It is not perfect, but no one can get everything right from day one, and overall you did get a lot of important things right. 

The problems the project faces right now are largely a result of its successes, and those are the sorts of problems that aren't so bad to have. :)

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

I actually do agree with most of the points raised, and agree wx being removed is probably the most sensible approach. I think, as you said, it was more the manner in which things were done that was disheartening.

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

Yes, I think the rules can probably change these days. Back in the days when there was only SVN, not being on trunk was a very painful experience because branch merging on such a large tree was so problematic, so it really was necessary for the threshold for inclusion to be lower. Today though, with git, it is a lot more feasible for ports to be a layer 'above' the core code. If I were starting the project today, that is probably how I would do it. 

> 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
> resources?

Yes, in fact, that's an idea that has been stewing in my head a while now. It's mostly an issue of wxWebKit already being used in and working fine for a few projects, so there isn't a pressing need to deal with this issue right now, but I suspect when I need to start a new project, that will probably be the route I take. Part of the hesitation, though, is that I honestly find this project a lot of fun to hack on. :) By and large, I really do find this a great project and community to be a part of.

> Again, my apologies to you Kevin for my part in all this.

You mean for helping me start this port in the first place, which was a godsend to me in the work I was and am doing, and has led to me learning a great deal over the years? Or, do you mean for getting the ball rolling that today leads me to have the other cross-platform WebKit options you mentioned, like Chromium and Qt, to choose from if I wanted to switch? Well... okay then, apology accepted. :)

I've got some other comments to make, but I've got some stuff I need to get out the door, so there will probably be emails trickling out over the next couple days or so. I just felt compelled to respond to this message first, as I think in every instance you, and many others in the community, have really only tried to be helpful, and that is deeply appreciated. Please don't beat yourself up over that!

Thanks,

Kevin

> 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>
>> wrote:
>>> 
>>> 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
>>> discussion.
>> 
>> 
>> 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.
>> 
>> Cheers,
>> Benjamin
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev