<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 3, 2015 at 5:24 PM, Mark Finkle <span dir="ltr"><<a href="mailto:mfinkle@mozilla.com" target="_blank">mfinkle@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 class="">On Thu, Sep 3, 2015 at 4:11 PM, Martin Thomson <<a href="mailto:mt@mozilla.com">mt@mozilla.com</a>> wrote:<br>
<br>
> On Thu, Sep 3, 2015 at 12:21 PM, Mark Finkle <<a href="mailto:mfinkle@mozilla.com">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<br>
> approach.<br>
> > Any changes must be landed in the client application.<br>
><br>
><br>
> 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.<br>
><br>
<br>
</span>Pushing updates is exactly what we want to avoid. Pushing updates is what<br>
we do right now, and it's not without issues. Pushing updates also makes it<br>
almost impossible to mange staged rollouts, or quick backouts. Going faster<br>
is part of our goals too.</blockquote><div><br></div><div>I'm not following the concern.</div><div><br></div><div>The usual way to do this is to have the server publish a manifest that tells</div><div>the client "if you are in this range of the UUID space, then behave this</div><div>way". You then use exactly the same retrieval policies you currently</div><div>do but instead of publishing per-client instructions, you publish the</div><div>manifest.</div><div><br></div><div>-Ekr</div><div><br></div></div></div></div>