<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.  We should formalize this as policy too in my opinion.  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&#39;s pretty much no guarantee of when a WebKit trunk build could be shipped as (eventually) a stable Chromium/Google Chrome release.  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 &quot;ToT&quot; (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 &quot;in-progress&quot; on the branch.  Expecting ToT to actually be shippable all the time is not very practical.  Realistically people will always be causing occasional regressions from bug fixes and feature work.  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&#39;s heuristic for when things should be behind a flag.  Regressions can always happen, but if you&#39;re knowingly introducing something that&#39;s half-baked it really seems like it should be behind a flag.</div>
<div><br></div><div>Note also that Chromium&#39;s dev channel releases are pretty much weekly, so cutting a branch for those is not practical.  Some web developers do use WebKit&#39;s nightly builds and Chromium&#39;s dev channel, so keeping things relatively stable (with not much cost...flags are easy to add) seems like the right way to go.</div>
<div><br></div><div>J</div></div>