hyatt at apple.com
Mon Jul 13 15:17:34 PDT 2009
On Jul 13, 2009, at 5:02 PM, Darin Fisher wrote:
> This small interval rule-of-thumb idea sounds pretty good, but I
> still wish it didn't put the burden on the guy doing the branch to
> figure out what is or isn't incomplete about a particular snapshot
> of WebKit. That guy might not be savy enough to know what he should
> be concerned about.
That's exactly who the burden should be on though. ToT is a
development tree. It's the organization shipping their product that
should be working to determine when their product is shippable.
> The developer of the new feature, on the other hand, is the expert
> and should be in the best position to know when their work is
> shippable. It seems like there should be a low-cost way for such
> developers to flag a feature as incomplete and then clear that flag
> when it becomes safe to ship the feature. Afterall, it would seem
> to be in that developer's best interest to not have their new work
> shipped prematurely (thus causing its adoption to be stunted by
> incompatibility issues).
> Adding an ENABLE flag doesn't seem like that great of a tax to me.
I think it would be a great annoyance for very small features. I also
expect that people would sit on their feature until it was completely
done and stop properly staging work in order to avoid adding such
short-lived ifdefs to the project. That would just make the patch
review process more painful, and make it harder to track down
individual bugs caused by the lack of incremental landings.
> Alternatively, perhaps there could be more communication from the
> developer landing an incomplete feature? A simple heads-up to the
> list might be enough. "Hey, I just landed the first part of HTML5
> foo bar. Right now, everything is just stubbed out, but I will be
> landing the implementation in the next few days."
I think that's an excellent idea. We could try to do that more via
checkin comments and ChangeLogs also.
(hyatt at apple.com)
More information about the webkit-dev