Present: @ftynse (chair / scribe) @matthias-springer
Absent: @rengolin @jpienaar
-
Procedural update:
- Area Teams are expected to nominate maintainers for relevant parts of the area.
- Area Teams are expected to regularly go through RFCs or contentious PRs and take action to resolve contention. They may take technical decisions on those or defer to the Project Council. The Project Council can also overturn a technical decision by an Area Team by a ⅔ vote.
- We will proceed with RFCs discussions and try to make relevant parties reach consensus at this stage.
-
Nominating maintainers (from the area team duties):
- Ask people to self-nominate.
- If multiple people nominate themselves for the overlapping parts of the area, discuss within the Area Team and make a proposal to the community.
- Look at frequent contributors / reviewers per directory and ask directly for broad scopes to be defined.
- Consider deleting orphaned parts and see if somebody steps up to maintain those instead.
- j2kun asks about getting involved more to become a maintainer. Suggested to actively monitor and review PRs and RFCs in the relevant area.
-
Specific RFC discussions:
- Mandatory data layout in the LLVM dialect
- ask the proposer and some contributors to think about doing this at pass granularity and beyond llvm dialect
- Bug in `OperationEquivalence` (breaks `-cse` on `linalg.index`)
- encourage the proposer to hold an ODM, this is a hard topic; several area team members had hour-long discussion with that person + have a time poll for those involved
- there was a PR Remove Pure attribute from Linalg::IndexOp. by erick-xanadu · Pull Request #68894 · llvm/llvm-project · GitHub revive or at least ping the participants
- [RFC] Simplify x86 intrinsic generation
- removing stuff is reducing the maintenance burden, so good, at least for x86dialect
- ask them to proceed, review PR
- ping people from similar dialects (nvvm, amdgpu)
- Mandatory data layout in the LLVM dialect
-
Strategy on RFCs resolution for now:
- Find more people who are relevant, ping them actively.
- Identify emergent / “rough consensus” and call that out.
- TODO: decide what happens if they don’t react.
- We need less vocal support for removing something (because nobody objects) than for adding something (because nobody cares or is willing to maintain).
- Document how and when (not immediately after an RFC) to call the Area Team into topics when consensus proves elusive or if the discussion is otherwise stalled.
Live document: MLIR Area Team Meeting Minutes - Google Docs