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

[Ryosuke Niwa]

For those of you interested in this stuff, I have a patch to add a
webkit.org/team.html that auto-generates a list of contributors from
committers.py on https://bugs.webkit.org/show_bug.cgi?id=68045.

This version doesn't include area of expertise but we can add it easily once
the bug 68061 is fixed (i.e. a script to detect active contributors and
reviewers is added).

- Ryosuke

On Wed, Sep 14, 2011 at 1:08 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> To mitigate this issue, Leandro (acidx) and I are working on change log
> parser that can automatically detect active patch contributors and
> reviewers. (See https://bugs.webkit.org/show_bug.cgi?id=68061).
>
> Having said that, I think contributors should help maintaining ports that
> have bots on build.webkit.org or EWS bots.
>
> - Ryosuke
>
> On Wed, Sep 14, 2011 at 12:08 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>
>>  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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110914/8ee556f8/attachment-0001.html>