[webkit-dev] What is an "active port"? [WAS: Do you maintain OS(WINCE)?]

Adam Barth abarth at webkit.org
Wed Sep 14 12:50:30 PDT 2011


One of the things I admire about the WebKit project is that
historically the project has been very inclusive.  One common thread
that's woven through a number of recent discussions is that folks feel
we've taken on too much complexity and that it's harder to make
fundamental improvements to the engine.  Maybe it's time to adjust
that balance slightly, but I hope we adjust our behavior deliberately.

Adam


On Wed, Sep 14, 2011 at 12:08 PM, Geoffrey Garen <ggaren at apple.com> wrote:
> Hi Patrick.
>
> On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer <paroga at 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 <paroga at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>


More information about the webkit-dev mailing list