> Following this pattern, giving a warning then waiting for some period of time > might be sufficient. e.g. > Warn the port (probably on webkit-dev) > Wait for six months > If there's no activity in step 2 to counter the argument, then remove the > port.
You might think this leniency is friendly to port authors. I don't. Leniency is friendly to the author of the port you're considering removing, but unfriendly to all other port authors, for two reasons: 1. It decreases the overall quality of the code everyone shares, inhibits new features, and slows development. 2. If we codify a high barrier to exit for ports, we're likely to need a corresponding high barrier to entry. We'll need to make it harder for new ports to enter the project, for fear that they'll go stale but we'll still have to limp along with them in the tree. I tend to think that the reverse is the best policy: Low barrier to entry, low barrier to exit. This keeps the project open and growing, but also ensures that it can move forward without getting bogged down in unmaintained or poorly maintained ports. Barrier to entry: Send email to webkit-dev, get a reviewer to r+ a patch. Barrier to exit: Rough consensus among reviewers that a port is stale and/or a maintenance burden. Geoff
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
