<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 13, 2009, at 11:57 AM, David Hyatt wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt <span dir="ltr">&lt;<a href="mailto:hyatt@apple.com">hyatt@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div style="word-wrap:break-word"><div class="im"><div><div>On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt <span dir="ltr">&lt;<a href="mailto:hyatt@apple.com" target="_blank">hyatt@apple.com</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex"> <div style="word-wrap:break-word"> I agree. &nbsp;We should formalize this as policy too in my opinion. &nbsp;Maybe something time-based, e.g., if you have an implementation of a new Web technology that is going to take &gt; (1month?) to implement, then the feature should be landed inside ENABLE ifdefs (that can then be removed when the feature is sufficiently far along).</div> </blockquote><div><br></div><div>For Chromium this kind of time frame can be problematic, since there's pretty much no guarantee of when a WebKit trunk build could be shipped as (eventually) a stable Chromium/Google Chrome release. &nbsp;Even having an incomplete feature in the tree a few days can result in the incomplete feature getting shipped to web authors.</div> <div><br></div></div></blockquote><div><br></div></div></div><div>The way to ship "ToT" (in my opinion) is to cut a branch, watch ToT for any regressions from recent work, merge those fixes into the branch, and then turn off anything that is "in-progress" on the branch. &nbsp;Expecting ToT to actually be shippable all the time is not very practical. &nbsp;Realistically people will always be causing occasional regressions from bug fixes and feature work. &nbsp;Branches are the way to stabilize from some known point.</div> </div></blockquote><div><br></div><div>I agree, but I also agree with Peter's&nbsp;heuristic&nbsp;for when things should be behind a flag. &nbsp;Regressions can always happen, but if you're knowingly introducing something that's half-baked it really seems like it should be behind a flag.</div> </div></blockquote></div><br><div>I agree with that. &nbsp;I'm just asserting that some reasonable time limit before requiring ifdefs is ok. &nbsp;If a feature only takes 1-2 weeks to land, I think it's total overkill to put it inside an ifdef. &nbsp;Any cut branch should take long enough to stabilize that it could merge the rest of the feature in anyway. &nbsp;If you're ever cutting a branch off ToT and shipping it as a full-blown release with less than 2 weeks turnaround, you're doing it wrong in my opinion.</div></div></blockquote></div><br><div>I'm more or less with Hyatt on this one. I think it would be process overkill to require ifdef for every feature that has more than one implementation step. A month sounds like about the right time scale where a switch is useful. One other thing to keep in mind: sometimes an incomplete implementation of a feature may still be a state that's useful to ship. I'm hoping people can exercise good judgment here and ping the list when in doubt.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div></body></html>