Core Commiter Weekly Interlock - January 9th, 2017

Agenda:

Logistical Items
Pending PR Reviews
Roundtable

Notes:

Logistical Items:
1. Going forward, Former user (Deleted) will take this forum and lead the core committer team.
2. The ability to interlock between the Quality Review Board and the Core Committer forum will be one of the first AI's on this going forward
  1. For instance - when to lock head due to regression wheel failures?
Build and Release Strategy
1. Timing on cutting branches from a sprint and posting of the RackHD sprint releases?
2. Initial proposal of cutting the branch on day 10 of a sprint but that is not optimal due to closing the window early on the development pipelines for the team during the current sprint.
3. We need an incremental and iterative on the regression wheel and ensure that we don't have "late discoveries" during the sprint cycles.
4. We will use the manifest and commit IDs as the mechanism for the fall-back as needed for when we lose our green status on the dashboards, if the green dashboards falls down - we will have the ability to post "last known" good on builds in every sprint
5. Continued discussion on thoughts and strategy for branching at sprint end - is it needed? Or is tagging good enough?
  1. Continous Delivery and Test Driven Development(TDD) may very well mitigate the need to branch.
  2. BUT - our CD and TDD capabilities are not proven yet....
  3. Do we run the risk of a negative regression wheel "Winter"?
  4. Do we actually branch at this point or just live with tags?
  5. Proposal to NOT branch - any concerns/objections? (IE - we only go forward with tags)
    1. AI: Need to ensure that Former user (Deleted) can support this change in POR
Release Numbering:
1. What is the final decision on the starting release numbering?
2. Given this will be the first formal RackHD release
  1. Two explicit compatibility concerns that must be considered:
    1. front end API revision
    2. Data Model revision
  2. Given that this IS the first release - the previous history is not consequential because this is "new"
3. Semantic versioning is POR
  1. We will bump the major on compatibility changes to either the (Front End API and Data Model)
  2. Consumer implications needs be taken into account - what is the downstream impact of API and Data Model changes? Ensure that the changes are account for in the revision management.
4. To be explicit - the Core Committers will be responsible for managing the revision changes and decision to update.
5. AI: Improve the coverage against the regressions for compatibility changes in the front end APIs, including the messaging bus(AMQP Bus)
6. Currently the data model does not have tracking versioning (DataBase Schema)
7. Updated proposal is 1.0 for the RackHD release starting point
8. AI: Former user (Deleted) look into the current RackHD release branches that support OnRack and get them renamed to clear the way for 1.0 as a potential revision to start
9. AI: Former user (Deleted) ensure that 1.0 "IF" the OnRack branch conflicts are removed can that be the go-forward proposal?