Core Commiter Weekly Interlock - March 13th,2017

Former user (Deleted)

Former user (Deleted)

Paul Scharlach

Torrent Glenn

Former user (Deleted)

Former user (Deleted)

Amy Mullins

Tim Larson

Former user (Deleted)

Former user (Deleted)

Former user (Deleted)

Former user (Deleted)




0. 2.0.0-rc green?  Good to post?

AI Thomas Sullivan Good to post the release.

1. UI Test discussion - RackHD approach for testing and preventing against issues similar to :  (Amy?)

RAC-4363                    -             Swagger-UI not displaying 2.0 API                                                             Done           

 AI Former user (Deleted) to investigate with UI team.

2 Transition to Node.JS 6 (node 4 is to expire 4/2018) transitioning now allows for 1 year to buffer to be prepared (Andrew?)

Need to continue running in parallel dev efforts, start to work on the build issues with node JS 6 in Travis.

AI Former user (Deleted) to create stories to go through Travis failures.  

3. SKU Pack incompatibility across rackHD releases.                       RAC-4408                    -             SKU Pack: fail to match Node automatilly                                                             Done                 This issue brought up a good point about how changes in RackHD can impact skupacks. Are we to maintain compatibility among released versions, announce changes such as this to the community, etc...?  Feedback within the issue indicated "This task is a new created task recently, you need to fetch latest on-tasks code to get this task. Otherwise you need a legacy SKU pack instead."

There is a story created that will introduce skupack testing and close a test gap, but how do we want to handle changes such as this that can impact community members as they create their own skupacks?

Define what needs to be controlled for public API (does jobs/tasks - creation/deletion ) matter for the public API

AI Former user (Deleted) Former user (Deleted) Torrent Glenn to look into this

4.  Former user (Deleted) I have some initial thoughts and grooming some simple/incomplete steps to guide CCs for CI/Nightly pipeline broken failure, feel free to modify and comments. 1. Report and publish CI/nightly pipeline blocking P1 issue to slack channel to let all CCs aware 2. CCs merge-stop (PR could be submitted continiously) 3. Fix issue or Revert PR, CC need to balance the efforts to choose either one. 4. US-SH 24 hours shift to fix P1 issue. US-SH deliver debug progress at the end of worktime. 5. When P1 issue is fixed, or CI pass, broadcast in CC slack channel to notify merge-continue.

Pin the stop merge message to the RackHDCC channel.   Process for all CC before merging look to see if the stop merge message is Pinned.  Only pinner is allowed to remove the PIN.   PIN should contain the RAC issue that has caused the PIN. 

5. Naming conventions for daily releases - contain the previous release candidate plus date  1.3.0-20170208  How do we handle multiple delivery in a day?

AI Former user (Deleted) and Former user (Deleted) to send out there thoughts on this.  To discuss at the next CC meeting

6. CC Responsibilities and Roles - Do we allow PR's to get merged without CC approval - reason being we have TDD and pair programming is that enough.

Figure out process.   Need to be able to make sure we have anchor in place, pair programming in place and TDD is in place.  When will Dev managers and CC feel comfortable that we have enough process in place to remove the CC merge process.  TBD.

7,  Former user (Deleted): Minimize Environment for CI Test: Minimize Environment For CI Test.pptx 

AI All to review ppt and reply to Felix