Core Committer Weekly Interlock - November 2nd, 2016
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:
- Tool Transitions
- RackHD Branch Strategy Proposal - Updates
- RackHD Quality Review Board Proposal
- Pending Pull Requests: https://github.com/RackHD/RackHD/pulls
- Roundtable
Notes:
- Tool Transitions
- Proposal:
- Proposed to utilize external cloud Atlassian as the new front end portal for RackHD
- Migrate the team support from Pivotal Tracker to JIRA for task management
- Goal will be to move to a single backlog (RackHD) which we don't have today with Pivotal Tracker
- Teams will tag issues to create specific team board view
- Migrate from GitHub Issues → JIRA Tracker
- Reduce the toolsets down to two environments:
- Github (Front End)
- Wiki
- Source Code
- Atlassian Public Cloud (Back End)
- JIRA
- Confluence
- Content
- Email Notifications and DLs
- Github (Front End)
- Enables the Defect Review Board to have the ability to look at all issues in one location
- Concerns?
- need to avoid customizations and anything that convolutes the flow management
- need to ensure that search and document management stays "clean" and "manageable"
- Wikis have a tendency to become a "soup" and content becomes messy and not structured - we need to ensure that this
- Will the replacement of JIRA for Github issues cause confusion for the community?
- We would be asking the community to move from one portal (github) to another portal(Jira) when one needs to open defects
- Potential to end up with obfuscated fields in the JIRA trackers that are potentially frustrating/confusing for the community....
- Github issues doesn't allow this today - if we move it - do we run the risk of creating too much complexity?
- How to tie PR flows? Github is very natural for this but JIRA might have some challenges with the integration plugins...
- Next Steps:
- Execute a trial run on an RFS→Pull Request→Commit→Issue Close
- need to understand how to deprecate and replace GitHub issues with JIRA
- Also need to understand how well Github and JIRA can be integrated with the plugins
- Evaluate further how CoprHD is using their flow with Github and JIRA for their efforts
- the new RackHD portal view proposal - finish edits and reviews for intergration and tie into the JIRA/Confluence go live:
- Proposal:
- RackHD Branch Strategy Proposal
- Brian and Amy to present to the RackHD Leadership Team on the current proposal and next steps - then will publish to the RackHD forum.
- RackHD Quality Review Board Proposal
- How do we create a forum that is directly responsible for the RackHD quality metrics and reviews going forward
- AI: TimL and TomS owe the team a write-up on this proposal (Next Week - CC Meeting)
- Pending Pull Requests:
- Need to put an emphasis back on the process for managing "aging" PRs
- BenBP had a proposal a while back to ensure that we managing the lifecycle of PRs to ensure that the "clutter" stays manageable.
- Plan would be to ping on "stale" PRs and then put it on a one week timer to closure
- Validity against the code base become an issue as the PR ages and potentially becomes irrelevant
- Next Steps:
- BenBP will post the process to the Wiki and ensure that the messaging is out on the new "grooming" process for PRs
- Option for Thomas Sullivan to help with metrics and "reporting" tools if needed for this effort
- Roundtable:
- 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...
- 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...
- 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.
- 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...