Hi Patrick.
> On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer <par...@paroga.com> wrote:
> How do we measure an "active port"??? I maintain a buildbot for WinCe and
> usually fix problems with the port within hours. Unfortunately I don't get
> paid to work on WebKit the whole day and so I can't make such big steps
> forward like other ports do.
In my effort to establish the "threads exist" baseline abstraction, I've gotten
a few responses similar to this one: "I maintain port X, but I'm the only one,
and I have limited time…".
Here are my current thoughts, based on that experience:
* A long list of #ifdefs in core WebKit code makes reading and understanding
the code difficult, especially if the #ifdefs select among a matrix of
fundamentally different ways of doings things.
* A long tail of ports makes fundamental improvements to the engine difficult
and time consuming. Fundamental improvements are likely to break a port, and
port maintainers may not be available in a timely fashion to adopt a
fundamental improvement. (For example, it has been about a week since I started
the "threads exist" project.)
* We have a significant number of ports (maybe 5) that are either (a)
maintained by only one person working part-time or (b) not maintained at all in
WebKit trunk, but periodically upstreamed to WebKit trunk by downstream clients
to make their future merges easier.
* Single-part-time-maintainer ports seem to keep up at a reasonable pace with
simple build fixes like adding new files to projects, but not with major
architectural changes.
* Single-part-time-maintainer ports get very little, if any, testing outside of
automated regression tests, so it's hard to know if the code actually works,
who uses it, or what its requirements are.
When I ask if a port is "active", I guess what I mean is, "Can I go ahead and
make this core WebKit improvement, and assume that port maintainers will keep
up, or do I need to stop what I'm doing and wait for them, or worry that they
will roll out some or all of my patch instead of doing the harder work of
upgrading their port?" I also mean, "Is this port actively used, and is the
opportunity cost of upgrading it justified?"
I think the right solution here is for port maintainers, in cases of nontrivial
work, to take on the job of upgrading their ports to match core engine changes,
instead of core engineers taking on that job. And, in cases where a port
upgrade isn't available in a timely fashion for some reason, WebKit should move
forward and break the port (core builder or not). This proposal might seem
unkind, but I think it's the best thing for moving WebKit forward in the long
run.
> On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer <par...@paroga.com> wrote:
> So PLEASE: When do we call a port "active"? It's not cool to get the question
> about removal every few months!
I hope that the plan I've outlined above will make "active" ports much more
well-known to core WebKit contributors, since port maintainers will be working
with core contributors to upgrade their ports.
Regards,
Geoff
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
