Hmm... I vaguely remember us discussing a separate staging flag which would serve the purpose of separating incomplete features from complete features which are soon to be turned on, but unless the idea is to that staging features are on by default, I think it's too late to put O.o through this new staging process.
The goals we agreed on were to ship in M35 and to enable by default as soon after the m34 branch point as possible to maximize "time to bake" in Canary/Dev, etc... We explicitly waited beyond M34 so we could have enough time to be on by default before the next Beta branch. Am I misunderstanding something? If not, it would be very helpful to have this patch ready to land as soon as you guys feel the tree is ready for it and a full review is much appreciated =-) On Wed, Mar 5, 2014 at 1:55 AM, <[email protected]> wrote: > Hi Rafael, this CL makes sense eventually, but right now it would be > skipping > the ES-staging process that we have decided to take new features through. > > I have implemented a respective flag two weeks ago > (https://codereview.chromium.org/165723008/), but couldn't land it yet, > due to > the tree still being closed. However, I just got special sheriff > permission to > do it. :) > > Moving something away from under --harmony also requires moving associated > JS > tests from harmony/ to an es6/ subdirectory yet to be created (or in your > case, > es7/, actually). That is to allow ClusterFuzz to pick them up (which is > intended > to skip harmony/). > > https://codereview.chromium.org/183683022/ > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
