Skip to content

Meeting 2019 05 10

Jump to bottom
Josh Hursey edited this page May 10, 2019 · 2 revisions

Agenda

Notes

        Joshua Hursey (IBM)
	Thomas Naughton (ORNL)
	Kathryn Mohror (LLNL)
	Barry Rountree (LLNL)
	Jithin Jose (Microsoft)
	Swaroop Pophale (ORNL)
	Stephen Herbein (LLNL)
	David Solt (IBM)
  • PMIx standardization process
    • https://github.com/pmix/pmix-standard/pull/183
      • Discussion of comment here https://github.com/pmix/pmix-standard/pull/183#discussion_r282902292
        • Discussing if the PR can move forward even with addressed objections. What does “addressed” mean?
        • Use the straw poll mechanism to help decide
        • PR author adds a comment saying “Objection X was addressed” and then use the thumbs up/down mechanism for folks to agree/disagree. If disagree then leave a comment that you would like to see the objection be better addressed.
        • Could use the straw poll to determine majority sense of the community to move a ticket forward.
      • Should we have a more formal mechanism in the final Acceptance stage? Or does the process to that point achieve that goal.
    • https://github.com/pmix/pmix-standard/issues/179
      • Should something new to the standard be allowed to be unstable - able to be adjusted in future standard.
      • First define what we mean by the “levels” then try to attach terms later.
      • Level suggestions:
        • Level 1: Allow for wild ideas to be adopted that may have not been fully tested or deployed. Can disappear in the ‘next’ standard or fast track depreciation
          • Low risk to accept something specific since no stability assurance.
          • Can this be skipped. Or can this be an implementation specific interface and not part of the standard.
          • Could there be competing versions of the same level 1 interface?
          • Other models say that implementations disable these by default.
          • Require: implementation, and Read->Accepted into standard
            • Lower bar for acceptance.
        • Level 2: More solid interface. Stability assurances. Longer depreciation process - will require a minor version change.
          • Must demonstrate wider usage - prove some generality to move from Level 1 to Level 2.
          • Don’t make this time based since lack of adoption might cause it to be promoted prematurely.
        • Level 3: Solid interface.
          • Major version change required
          • Move from Level 2 to Level 3 is time based for consideration
      • How do we move between these levels?
      • Should everything in the standard be Level 3. Experimental interfaces go into the implementations.
      • Level 1 being part of the standard gives it exposure to a broader set of users.
    • https://github.com/pmix/pmix-standard/pull/187
      • Take a look at this, and plan to merge it in next week.
  • (Dave) Working group: Implementation agnostic document
  • (Stephen) Working group: Slicing/Grouping of functionality
  • (Josh) Use Case gathering
  • Define scope of PMIx standard
    • Something that we can judge Use Cases against
    • (Josh) Open Issue to have this discussion
  • PR Template
    • Two types:
      • Typos - reference a ticket or have a specific label
      • RFC - see notes on Issue 181 and RFC repo

Action Items

  • (Josh) Create PR templates
  • (Stephen) Followup on https://github.com/pmix/pmix-standard/issues/179 with 'level' proposal
  • (Dave) Send out a meeting invite for Working group: Implementation agnostic document teleconf
  • (Josh) Open issue to discuss "Define scope of PMIx standard"
  • (Josh) Create use case for wireup with PR template

Home

Working Groups

Events

Helpful How To...

ASC Quarterly Meetings

ASC Monthly Meetings

Clone this wiki locally