Skip to content

minutes.md

Latest commit

 

History

History
84 lines (64 loc) · 4.71 KB

minutes.md

File metadata and controls

84 lines (64 loc) · 4.71 KB
Raw

Coding Guidelines Subcommittee Meeting on 2026-02-04 @ 09:00 CET / 17:00 JST

Link to meeting time in common time zones.

Search Key Description
[todo] Action Item
[decision] Something decided on
[important] Key information

Agenda

  1. Solicitation of notetaker
  2. Acceptance of Previous Meeting Minutes
  3. Introduction of new members
  4. Mention review/merge workflow issue (See example)
  5. Review of contributor experience issues (Sam)
  6. Review of open issues (Sam)
  7. Review of open PRs (Sam)
  8. Round table

Check-in area

  • Samuel Wright ☕☕☕
  • Yuchen Shen
  • Andreas Weis 👋Xx
  • Oreste Bernardi ⛰️
  • Christof Petig 🌞

Please add your name, and an emoji that describes your day.

Notetaker:

  • Christof Petig

For tips on how we take notes in the Safety-Critical Rust Consortium, please see the Meeting Notetaker Role doc.

Housekeeping section

Tasks

  • xx

Meeting Minutes

  • Minutes from last meeting were accepted without corrections
  • New member introduction: Andreas Weis of ekxide IO
  • Going through the middle column of the Kanban board
  • Question about the process to assign a reviewer for a pull request: #331
    [todo] We are missing a criterion for ready for review.
    This PR is blocking activity, but the situation is known
    • It should be easy for people to contribute
    • [info] MISRA uses maturity level tags
    • Pete stated that even a merge is not equal to a release, a release will involve an in-depth review process. We agree to the concept of a working document.
      Question: Is this clear enough in the contributing guidelines?
    • Proposal: The FCP process should start after the merge
    • [info] The assignment bot should randomly assign a person, who can then reply to the bot if blocked for the review within the next two weeks
    • [todo] The reviewer can’t tell the bot that the PR is approved, yet. Known problem.
  • Looking at the Guidelines view:
    • #235: We are looking for a valid use case (value initialized by HW but not known from within the abstract machine) which would violate the rule.
      1. [todo] There is no compliant example, this would help clarify the situation. One option is DMA, another option mmap of shared memory.
    • 240: skipped after brief inspection (pr for 235)
    • 246: We clarified the implications of provenance.
      E.g. taking a pointer to the struct and offset of a field is valid, but inferring a pointer to a field from a pointer to a different field is violating provenance.
      1. A link to a good explanation of provenance would clearly help understanding.
        We wondered about the difference between strict and exposed provenance.
        https://doc.rust-lang.org/std/ptr/index.html#strict-provenance
        [info] Potential (non authoritative) link: https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html
      2. There are already architectures which cryptographically generate provenance on pointers, and you can’t create a pointer from an integer only.
      3. Rust has not decided on whether to go for the more secure provenance or the more practical (on classic hardware) traditional model.
      4. [decision] We should recommend strict provenance because of the safety benefits, turning it off with good reasons is still possible.

Material

Any material to read before the meeting should be included here.