On Mon, Jul 13, 2009 at 11:57 AM, David Hyatt <[email protected]> wrote:
> On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote: > > On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt <[email protected]> wrote: > >> On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote: >> >> On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt <[email protected]> wrote: >> >>> 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 > (1month?) to implement, then the feature >>> should be landed inside ENABLE ifdefs (that can then be removed when the >>> feature is sufficiently far along). >>> >> >> 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. Even having an >> incomplete feature in the tree a few days can result in the incomplete >> feature getting shipped to web authors. >> >> >> 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. 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. >> > > I agree, but I also agree with Peter's heuristic for when things should be > behind a flag. 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. > > > I agree with that. I'm just asserting that some reasonable time limit > before requiring ifdefs is ok. If a feature only takes 1-2 weeks to land, I > think it's total overkill to put it inside an ifdef. Any cut branch should > take long enough to stabilize that it could merge the rest of the feature in > anyway. > Hm. Now that I think about it, I'm mixing up breaking existing behavior and adding new features which are in flux. In the former case, it should always be behind a flag, right? But yeah, for the latter case, I guess 1-2 weeks seems reasonable to me. > 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. > I think we can all agree with that. :-)
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
