-
Notifications
You must be signed in to change notification settings - Fork 22
Meeting 2019 05 24
Josh Hursey edited this page May 30, 2019
·
2 revisions
- PMIx standardization process (try to limit to 30 min)
- Discuss: https://github.com/pmix/pmix-standard/issues/181
- https://github.com/pmix/pmix-standard/pull/183 - Reading scheduled for May 31 meeting
- Discuss: https://github.com/pmix/pmix-standard/issues/181
- Discuss: https://github.com/pmix/pmix-standard/issues/179
- GitHub PR templates:
- https://github.com/pmix/pmix-standard/pull/188
- If no objection I would like to merge this in the May 31 meeting
- (Dave) Working group: Implementation agnostic document
- Meeting Tuesday's at 9 am (Central)
- https://github.com/pmix/pmix-standard/issues/175
- (Stephen) Working group: Slicing/Grouping of functionality
- Meetings Wednesday's at 11 am (Central)
- https://github.com/pmix/pmix-standard/issues/182
- (Josh) Use Case gathering
- See template here: https://github.com/pmix/pmix-standard/pull/187
- Open GitHub Issues
Kathryn Mohror (LLNL)
Geoffroy Vallee (Sylabs, Inc.)
Barry Rountree (LLNL)
Aurelien Bouteiller (UTK)
Ken Raffenetti (ANL)
Stephen Herbein (LLNL)
- Reminder that discussion/decision regarding naming of reference implementation and standard is set for June 14
- Aurelien reports that the reference implementation team prefers single name for both and is making efforts to distinguish between the two
- External people (not reference implementation group) still prefer a name change of either the implementation or standard to clearly distinguish the two
- Suggestion of code of conduct to encourage inclusivity
- Perhaps require/encourage video for teleconf since face to face meetings are challenging
- PR 183, official acceptance part is unclear and could be interpreted differently by different readers
- Haven’t defined acceptance levels or what it means for a vote at different levels
- Is anything being held up due for this PR?
- Is work in PMIx 4 subject to this PR? We think not, that the efforts for PMIx 4 are abiding by the “old rules” and only the new version will be subject to these rules
- General feeling that because nothing is being held up by this PR that we should spend more time on getting it right
- No real disagreement, but really want to get it right
- Templates PR
- No objections
- Interface Classes
- Is there still disagreement on this?
- Yes, do we still want to have the L1 class? (experimental) Does it serve the purpose we want?
- Perhaps this should be left to the implementations and they can do it if they want and get their users to try it
- What about people who don’t have their own implementation? Perhaps having L1 would encourage more people to participate.
- Some folks have a feeling that nothing should be in the standard without strong stability guarantees
- This idea is good for users who may not full appreciate what ‘experimental/L1’ means
- What about two versions of the standard, one that does not include L1 (the official version that users would find first), and one that does include L1 that is a bit hidden on the web site, maybe with red warning text
- Should comment on the ticket to ensure that discussion is captured and points of contention are noted
- Working group: Implementation agnostic document, no update, Dave not here
- Slicing/Grouping of functionality working group
- Decided to work from ground up, from use cases
- Lay out use cases and group them to see if there are common interfaces
- Will go through the RFCs and pull out the use cases from there
- Will use Josh’s wire-up use case as example starting place
- For now they are going to drop the use cases in a google doc instead of using the use case issues framework that Josh set up
- They are not going to meet next week because people are on vacation
- Code of conduct
- Are there good ones we can draw from? Anyone have suggestions?
- Homework: people search around and make suggestions next time
- (Josh) Create use case for wireup with PR template