Core Commiter Weekly Interlock - January 9th, 2017
Agenda:
- Logistical Items
- Pending PR Reviews
- Roundtable
Notes:
- Logistical Items:
- Going forward, Former user (Deleted) will take this forum and lead the core committer team.
- 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
- For instance - when to lock head due to regression wheel failures?
- Build and Release Strategy
- Timing on cutting branches from a sprint and posting of the RackHD sprint releases?
- 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.
- We need an incremental and iterative on the regression wheel and ensure that we don't have "late discoveries" during the sprint cycles.
- 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
- Continued discussion on thoughts and strategy for branching at sprint end - is it needed? Or is tagging good enough?
- Continous Delivery and Test Driven Development(TDD) may very well mitigate the need to branch.
- BUT - our CD and TDD capabilities are not proven yet....
- Do we run the risk of a negative regression wheel "Winter"?
- Do we actually branch at this point or just live with tags?
- Proposal to NOT branch - any concerns/objections? (IE - we only go forward with tags)
- AI: Need to ensure that Former user (Deleted) can support this change in POR
- Release Numbering:
- What is the final decision on the starting release numbering?
- Given this will be the first formal RackHD release
- Two explicit compatibility concerns that must be considered:
- front end API revision
- Data Model revision
- Given that this IS the first release - the previous history is not consequential because this is "new"
- Two explicit compatibility concerns that must be considered:
- Semantic versioning is POR
- We will bump the major on compatibility changes to either the (Front End API and Data Model)
- 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.
- To be explicit - the Core Committers will be responsible for managing the revision changes and decision to update.
- AI: Improve the coverage against the regressions for compatibility changes in the front end APIs, including the messaging bus(AMQP Bus)
- Currently the data model does not have tracking versioning (DataBase Schema)
- Updated proposal is 1.0 for the RackHD release starting point
- 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
- AI: Former user (Deleted) ensure that 1.0 "IF" the OnRack branch conflicts are removed can that be the go-forward proposal?