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 <rn...@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 <gga...@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 <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 >> >> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
