Skip to content

2026-02-05.md

Latest commit

 

History

History
122 lines (113 loc) · 7.1 KB

2026-02-05.md

File metadata and controls

122 lines (113 loc) · 7.1 KB

areaDetector Collaboration Meeting (2026-02-05)

Attendance

  • Érico Nogueira Rolim
  • Gustavo de Souza dos Reis
  • Henrique Simões
  • Gustavo Montenari Pechta
  • Jakub Wlodek
  • Mark Rivers
  • Tejas Guruswamy
  • Freddie Akeroyd
  • Famous Alele

Meta-issues

  • Retrospective: What are your thoughts on how the meetings have been going?
    • Format, usefulness, efficiency
    • Mark: have a presentation from someone every meeting (new detectors, developments)
  • How can we improve engagement of developers and maintainers? How can we encourage folks to attend meetings?
    • Meeting agenda hasn't been posted with 1 week advance, that should be fixed
    • What's missing for more people to interact in general issues?
  • We should review the maintainer list. What to do for those who still haven't responded?
    • Mark: add recent contributors as maintainers for some of them, such as Kaz do ADMythen
    • Xiaoqiang: remove from ADMythen
  • Do we have long-term roadmaps? Maybe revisit milestones?
    • Mark: there are wishlist items (e.g. refactors to use smart pointers), but they will take time, skill, and require thought towards updating drivers/plugins as well
      • Jure: does the single NDArrayPool cause issues with attribute list reuse? Would be interesting to benchmark effect of allocating for every frame
    • Jure (February Codeathon): destructible areaDetector drivers
      • Implement support in ADCore
      • Implement support in ADAravis
  • Items below discussed this meeting
  • Documentation gaps (issue tracking effort):
    • Driver documentation
    • Design decision documentation
      • Mark: this kind of documentation should go in the Architecture section in User Guide
  • Development and code standards:
    • It would allow us to have a document to point out to contributors
      • Mark: document further driver guidelines, improve base class in order to simplify it
    • Is there interest in this?
    • Suggestions:
      • Using commit messages to document development choices
      • Avoid inclusion of commented out code
      • Prefer modern C++ practices (?)
        • Freddie: what C++ standard can be used?
        • Mark and Jakub: older machines with limitations for C++ standard, standard compiler support
        • Mark: some things are already C++11
        • Mark: Windows support is important and care should be taken (e.g. PVXS); dbd files in O.Common can cause build issues when using the same tree
  • Rules/procedures for taking care of the org:
    • Technical disagreements, how to solve?
      • Each maintainer has the last word for their drivers; or
      • External consensus can override that, and certain standards/designs have to be followed
    • Situations where merging without maintainer approval is fine
    • Mark: things have been going well, might not be necessary to spend time on such rules. Maybe clean up current permissions and have a procedure for new projects?

Issues

Ongoing development