<div dir="ltr"><div>Thanks for sharing. I have read the proposal and I think it describes the problem well!</div><div><br></div><div>I have only one minor comment on the proposed solution, which is this:</div><div><br></div><div>> The new supervisor flag is named <code>shutdown</code> with possible values <code>normal</code>,
<code>any_significant</code>and <code>all_significant</code>, with <code>normal</code> being the default.</div><div><br></div><div>I don't like "normal" being the default because now I have to remember to change two places, the supervisor specification and the child spec, when configuring a significant child. The argument for this choice was:</div><div><br></div><div>> With the supervisor <code>shutdown</code> flag set to <code>normal</code>, the child spec flag
<code>significant</code> is ignored, even if present and set to <code>true</code>. This is intended
as a safety means to defend against unwanted breaking of old code.</div><div><br></div><div>I don't think it is possible for old code to break because there is no old code using significant in a child spec. :)</div><div><br></div><div>Therefore I would propose for the default to be either any_significant or all_significant (if we want to be conversative, the latter). If we really think a default of normal is necessary, then I would propose to at least warn if the supervisor is normal and a significant child is given, as that will eventually save someone from debugging why the significant flag is not working as expected. :)</div><div><br></div><div>I also think #{shutdown => normal} in a supervisor spec can be confusing, because someone may think it is customizing the exit reason of the supervisor, which is typically shutdown (and not normal). If normal is no longer the default, you could remove the normal option altogether, but if you want to keep it, perhaps something like ignore_significant is clearer?</div><div><br></div><div>Thank you!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 4, 2021 at 3:52 PM Maria Scott <<a href="mailto:maria-12648430@hnc-agency.org">maria-12648430@hnc-agency.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
   
 
 <div>
  <div>
   Hello,
  </div>
  <div>
   <br>
  </div>
  <div>
   in the course of discussion around <a href="https://github.com/erlang/otp/pull/4521" target="_blank">PR #4521</a> in OTP, it was decided by the OTP Technical Board that the PR will need an EEP. So here it is. We hope we did everything right, we tried hard to be clear, precise and exhaustive, and adhere to the requirements outlined in EEPs 1 and 33. But this is our first EEP ever, so... ^^;
  </div>
  <div>
   <br>
  </div>
  <div>
   Kind regards,
  </div>
  <div>
       Maria Scott
  </div>
  <div>
       Jan Uhlig
  </div>
 </div>
_______________________________________________<br>
eeps mailing list<br>
<a href="mailto:eeps@erlang.org" target="_blank">eeps@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/eeps" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/eeps</a><br>
</blockquote></div>