Versions Compared

Old Version 24

changes.mady.by.user Tapio Tallgren

Saved on

compared with

New Version 25

changes.mady.by.user Tapio Tallgren

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Join Zoom Meeting: https://zoom.us/j/598290523

One tap mobile
+16699006833,,598290523# US (San Jose)
+16465588656,,598290523# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 598 290 523
Find your local number: https://zoom.us/u/acimKOClJk


Notes

June 19, 2019

  • Sonobuyo testing on ARM
  • Release 2 requirements
    • What do we need for the first release?
    • When can we have it?
  • Meetings for next two weeks

June 12, 2019

  • New rules enforced: you need a "+2" in a review for merging, but it cannot be your own
    • If you are a committer, you can give a "+2" to your own patch
    • One "+2" from someone else than submitter is needed
    • After this, anyone can merge the patch
  • Sonobuoy doesn’t work for arm, so we have 2 options→ postponed to next meeting
    • call the tests directly without sonobuoy on arm hr
    • adapt sonobuoy to work on arm (I incline more to this option but seems difficult to do it upstream so we’ll have to figure out a clever solution)
  • Documentation strategy
    • We have projects lined up to test the Blueprint validation project
    • We need to separate user documentation and developer documentation
    • Follow Documentation Sub-Committee requirements (Architecture, User Guide and Release Notes)
  • Proposal to TSC about mandatory tests: https://docs.google.com/presentation/d/1ONU7jmeGVrhbJe2gKRtode1aHKH8teRgfN91LYAPBmo/edit?usp=sharing
  • We had a discussion about when a blueprint project can be "mature": is the maturation review before Release 2 or after it? Do we want to have "Mature" projects in Release 2? Assumption is yes
  • We need to define what a Blueprint Validation release is, since the different blueprints need to be able to test against a stable set of tests. It would make sense to call the first release "2", so that BluVal Rel.2 would be used to test blueprints for Release 2. Most likely will also need a BlueVal Rel. 2.1 to fix bugs, and then the blueprints could choose any version 2.x (the latest is probably the best choice but there is no pressure to upgrade if an earlier release works)

...