search

mozilla / self-repair-server

This project is now EOL, replaced by Normandy Recipe Server.
6 stars 11 forks source link

Recipe Applicability / eligibility (Design Proposal) #97

Open gregglind opened 9 years ago

gregglind commented 9 years ago

Claim: Recipes should have a function Fn that determines whether or not to apply the recipe.

Goals

  1. Debuggable
  2. Auditable, in that the SUPER AWESOME REPAIR DEPLOYMENT BOARD should know why things are deploying or not.

    Constraints:

  3. Fn may be asynchronous or syncronous. Asynchronous behaviour should implemented through returning a Promise.
  4. Fn may "allow" everyone, or no one, using any information at its disposal, including profile info, date, information from outside services, the phase of the moon, and the batting average of the Hanshin Tigers.
  5. Fn should be exported as part of the recipe (Common/JS style).
  6. To be valid, all recipes must have an eligibility function.

    Current:

bool shouldRun(profile, [other arguments useful for testing, interactive, or command line])

Pro

  1. Obvious return value and interpretation (bool).

    Con

  2. Hard to know 'why it failed', if there are multiple 'tests' or criteria.
  3. Encourages 'first fail' design mentality. Not always what is wanted.

    Proposal 1: Reverse the polarity of the neutron flow.

  4. Rename to preventRun or skipRun or dontRun or stopIf.
  5. Arity would be nullOrErrors stopIf(user_info, [optionals...])

    Pro:

  6. Still interpretable (in the negative)

    Con:

  7. Empty lists and objects are 'truthy' in js, annoyingly, so one has to be careful.
  8. if it a list is returned

    Proposal 2: Impartial Bureaucrat: Errors as an object, always

  9. Rename to determineEligible
  10. Arity is `nullOrAnalysis determineEligible (user_info, [optionals...])
  11. analysis would be an object of

    Pro:

  12. Everything is explicit, explicit, explicit
  13. Very very future proof.

    Con:

  14. Needs design of the returned object. 
# something like
errors:  list[ { name:  ,  message: }, ....]
ranAllTests:  (bool)  # did we did all tests?

Questions:

  1. Is Proposal 1/2 reasonable? If so:
    1. Is nullOrErrors or null_TruthyVal_ListOfErrors or null_or_errorsObject a better arity?
    2. If a list is returned, should the error handler have to know how to interpret it?
  2. Is Proposal 1/2 better than current, such that it is worth designing around them?
  3. I am leaning toward Proposal 2.
gregglind commented 9 years ago

@potch thoughts?