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

[Patrick Gansterer]

Hi,

I completely agree with all of your points. I also don't think that it's your task to keep every "part time" port working with every change.
IMO most of the "is active" questions come with a "when do we remove the old code/port from trunk" question. That's not very cool to hear after the "hard" upstreaming work. But that's only my personal view.
More interesting questing is: How do "part time" maintainers get "informed" about fundamental changes? I'd prefer cc'ing on a bug which might break a build. So it's possible for the maintainer to try to build with the patch locally and implement the missing parts. At least for me it's easier to fix compiler errors than answering questions about a possible build break on webkit-dev. ;-)

- Patrick

Am 14.09.2011 um 21:08 schrieb Geoffrey Garen:

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110914/42b80008/attachment.html>