Skip to content

Meeting 2019 06 28

Josh Hursey edited this page Jun 28, 2019 · 1 revision

Agenda

Notes

        Joshua Hursey (IBM)
	Ralph Castain (Intel)
	David Solt (IBM)
	Michael Karo (Altair)
	Stephen Herbein (LLNL)
	Swaroop Pophale (ORNL)
	Thomas Naughton (ORNL)
	Howard Pritchard (LANL)
	Geoffroy Vallee (Sylabs, Inc)
  • PR https://github.com/pmix/pmix-standard/pull/193
    • Outline: Governance, Voting Rules, Membership, Roles (chairs, release managers)
      • Co-Chairs - distributes the organizational workload
      • Suggestion: Add sentence like “informal members are encouraged to attend quarterly meetings” to make it clear that the meetings are not exclusive to members.
      • Suggestion: Add a nomination sentence. Something like “members may nominate others for membership”
      • Suggestion: Add more weight to the face-to-face meeting to help justify travel requirement. Maybe just add wording that it’s strongly suggested that folks attend the face-to-face.
        • Can you attend the face-to-face virtually? It’s difficult to attend this way, and would be an easy out for companies that don’t want to fund travel. Leaning towards no virtual attendance, but ASC members can vote to allow it on a case-by-case basis.
      • Suggestion: Maybe add a note about setting the date for the quarterly meeting be set no later than the prior quarterly meeting by a vote of the ASC members. So folks can plan travel if there is a face-to-face.
      • Suggestion: Releases occur in at most quarterly basis. Suggest minor release every quarterly meeting, major release on annual basis.
    • Outline: Process
      • 3 classes:
        • Provisional:
          • No backward or cross-version compatibility requirements
          • Changes: API/Attribute can change but with warning in at least two minor releases. (minimum 2 quarterly meetings if a minor release occurs in each of those meetings)
          • Removal: normal depreciation process. So a bit longer of a process than a change.
          • Attributes in Provisional class come in as Optional since it is free to be changed.
          • Suggestion: Maybe add a note about reusing the same API/Attribute name of one that had been removed in a previous version of the standard.
          • Suggestion: That provisional goes through a faster deprecation/removal process. Suggest 2 quarterly meetings (instead of 2 major releases).
          • Suggestion: Are provisional items in the normal body of the document or in a separate section of the document?
            • This is more of a general document structure guideline
        • Stable:
          • Permanent, non-changing parts - may only be deprecated
          • No changes allowed.
          • Removal via deprecation process
        • Deprecated:
          • Still in the document, but marked for removal in a future document - at least 2 major releases.
Clone this wiki locally