<div dir="ltr">How would we change the decision?<div><br></div><div>How would we do staged rollouts or backouts?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 3, 2015 at 4:15 PM, Eric Rescorla <span dir="ltr"><<a href="mailto:ekr@rtfm.com" target="_blank">ekr@rtfm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Sep 3, 2015 at 1:11 PM, Martin Thomson <span dir="ltr"><<a href="mailto:mt@mozilla.com" target="_blank">mt@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Sep 3, 2015 at 12:21 PM, Mark Finkle <<a href="mailto:mfinkle@mozilla.com" target="_blank">mfinkle@mozilla.com</a>> wrote:<br>
> We only intend to use this when the experiment is in a code path that<br>
> happens very early in application startup. We lose all ability to<br>
> dynamically alter the configuration and code path if we use this approach.<br>
> Any changes must be landed in the client application.<br>
<br>
<br>
</span>I'm not sure that I understand your concern here.  If you were to<br>
publish the low and high values for a given experiment, then you do<br>
commit to using CRC32 (and low and high markers), but that's not a<br>
problem in an of itself.  After all, you could include an indicator<br>
that describes how the buckets are calculated if you wanted to allow<br>
for some flexibility.<br>
<br>
If the concern is that you won't be able to update rapidly, I'd<br>
suggest that you might want to look at pushing updates rather than<br>
rely on clients polling.</blockquote><div><br></div></div></div><div>I don't follow what the issue is here either with using client-side decisioning.</div><div><br></div><div>-Ekr</div><div> </div></div></div></div>
</blockquote></div><br></div>