Core Committer Weekly Interlock - November 2nd, 2016

Owned by Tim Larson
Nov 02, 2016
3 min read

Previous Meeting Notes (October 19th, 2016  - https://groups.google.com/forum/#!topic/rackhd/pNGOHDzNicU) and Agenda:

1) Transition of OnRack activities to RackHD as a workstream effort
2) Debian Breaks Prevalent in the #RackHD Slack Channel
3) RackHD Branch Strategy Proposal
4) Improvement Plans for Dependency Challenges
5) FIT/CIT Strategy - QA process/capabilities for RackHD going forward...
6) Pending Pull Requests for RackHD - https://github.com/RackHD/RackHD/pulls


Attendees:

Felix [X]

Andrew [X]

Peter [-]

Brian [X]

Ben [X]

Paul [X]

Amy [X]

Leo [X]

Tim [X]

Joe H[-]


New Agenda Items:

  1. Tool Transitions 
  2. RackHD Branch Strategy Proposal - Updates
  3. RackHD Quality Review Board Proposal
  4. Pending Pull Requests: https://github.com/RackHD/RackHD/pulls
  5. Roundtable


Notes:

  1. Tool Transitions
    1. Proposal: 
      1. Proposed to utilize external cloud Atlassian as the new front end portal for RackHD
      2. Migrate the team support from Pivotal Tracker to JIRA for task management
        1. Goal will be to move to a single backlog (RackHD) which we don't have today with Pivotal Tracker
        2. Teams will tag issues to create specific team board view 
      3. Migrate from GitHub Issues → JIRA Tracker
      4. Reduce the toolsets down to two environments:
        1. Github (Front End)
          1. Wiki
          2. Source Code
        2. Atlassian Public Cloud (Back End)
          1. JIRA
          2. Confluence 
            1. Content
            2. Email Notifications and DLs
      5. Enables the Defect Review Board to have the ability to look at all issues in one location
    2. Concerns?
      1. need to avoid customizations and anything that convolutes the flow management
      2. need to ensure that search and document management stays "clean" and "manageable" 
      3. Wikis have a tendency to become a "soup" and content becomes messy and not structured - we need to ensure that this 
      4. Will the replacement of JIRA for Github issues cause confusion for the community?
        1. We would be asking the community to move from one portal (github) to another portal(Jira) when one needs to open defects
        2. Potential to end up with obfuscated fields in the JIRA trackers that are potentially frustrating/confusing for the community....
          1. Github issues doesn't allow this today - if we move it - do we run the risk of creating too much complexity?
        3. How to tie PR flows? Github is very natural for this but JIRA might have some challenges with the integration plugins...
    3. Next Steps: 
      1. Execute a trial run on an RFS→Pull Request→Commit→Issue Close 
      2. need to understand how to deprecate and replace GitHub issues with JIRA
        1. Also need to understand how well Github and JIRA can be integrated with the plugins
      3. Evaluate further how CoprHD is using their flow with Github and JIRA for their efforts
      4. the new RackHD portal view proposal - finish edits and reviews for intergration and tie into the JIRA/Confluence go live: 
        1. https://panpan0000.github.io/
  2. RackHD Branch Strategy Proposal 
    1. Brian and Amy to present to the RackHD Leadership Team on the current proposal and next steps - then will publish to the RackHD forum. 
  3. RackHD Quality Review Board Proposal
    1. How do we create a forum that is directly responsible for the RackHD quality metrics and reviews going forward 
    2. AI: TimL and TomS owe the team a write-up on this proposal (Next Week - CC Meeting)
  4. Pending Pull Requests:
    1. Need to put an emphasis back on the process for managing "aging" PRs 
    2. BenBP had a proposal a while back to ensure that we managing the lifecycle of PRs to ensure that the "clutter" stays manageable. 
    3. Plan would be to ping on "stale" PRs and then put it on a one week timer to closure
    4. Validity against the code base become an issue as the PR ages and potentially becomes irrelevant 
    5. Next Steps:
      1. BenBP will post the process to the Wiki and ensure that the messaging is out on the new "grooming" process for PRs
      2. Option for Thomas Sullivan to help with metrics and "reporting" tools if needed for this effort
  5. Roundtable:
    1. Paul Scharlach: Issue more recently with the Alpine images for the micro-kernel docker images - do we continue with that one? Or switch it out? Need to consult with Andre K and Roland on this topic for guidance on where we go next with this... 
      1. Early view is that there is not a specific reason to hold us on the Alpine micro-kernel - at this point the decision point is do we drop the support and move to Debian? Answer looks like probably yes but we need to finalize...
    2. Amy Mullins: Highlighting that next weekend is the transition to Daylight Savings Time so we will need to reset the calendar entries (AI: Tim Larson) to ensure no confusion with the time shift going forward.