Open Hour 2020-AUG-13

January 23, 2021 - slangadmin


  • Salt news and updates
  • Release process and strategy FAQs
  • Open discussion and questions

Salt News and Updates

Community Manager Cassandra Faris

  • Meetup speakers and topics are needed. If you’re interested in speaking or know of a good speaker, contact Cassandra.
  • Triage is streamed on Twitch every Tuesday at 12:00pm MT/6:00pm UTC.
  • Working Group and Open Hour YouTube videos and August Open Hour notes are now up-to-date.

Dedicated Topic: Release Process and Strategy FAQs

SaltStack SVP of Engineering, Moe Anderson

Thank you to SaltStack UX Designer Serena Jolley for creating these notes in realtime

Salt Open vision, mission, goals, commitment

  • Vision: To establish the community-built Salt Open software as the leading platform for Infrastructure Automation and Management
  • Mission: The Salt Open core team unites a global open source community to collaborate, build, secure, deliver, maintain, and promote Salt.
    • Driver for this team is to and from the community
    • Has been used on a global scale
  • Values:
    • Communication – We seek community participation. We are open and transparent
    • Action – We act decisively and proactively, embracing what we learn from both our successes and our mistakes. We understand our mistakes and work to avoid repeating them.
    • Teamwork – We add value to the Salt community by helping each other solve problems to create quality human and digital experiences. We arbitrate for the benefit of the community
    • Fun+Respect – We respect and value inclusivity in our global community and strive to recognize, understand, and respond to its needs. We have fun working on this exciting project.
  • Salt Core team: Bryce, Cassandra (community manager), Chad, Daniel (leads the work on many of our more critical upgrades), Derek (Dedicated documentation writer), Dmitry, Frode, Gareth, Jarom (dedicated SRE), Joe (Windows expertise), Kirill (seasoned SRE and test engineer), Megan (senior developer), Pedro (senior member of the team, built much of our test infrastructure), Sage (release manager), Shane (Windows expertise), Tyler (works diligently on Salt Cloud), Wayne (keeps track of release quality), Tom (our founder), Moe (overall management)
  • Goals:
    • Merge fast and confidently
    • Give community more of a say in work and direction
    • Understand what is going on
    • Improve quality and code base stability
    • Ease and accelerate onboarding

Process: today’s reality vs. tomorrow’s ambition

  • Level Set: The Salt Method
  • Personas: Our method is anchored in our Personas that represent our users. We consider our community contributor persona, Chloe, as a first-class persona. Chloe represents everyone in our community
  • Salt Method phases:
    • Idea>>Concept>>Design>Code>Validate>Package>Promote>Deliver
    • Design to develop
      • Wireframe/ design testing
      • Prototype and MVP iteration testing
    • Development to delivery:
      • Code dev elopement feature work and fix defects
      • Validation and QA
      • Packaging and Certification, documentation is completed
      • Beta testing
    • Principles for Quality Assurance
      • Iterative process that’s more than just code testing
      • User feedback, design reviews, and MVP playbacks
      • Successful test runs are prerequisites to PR submission or merge
      • Migration testing occurs at package phase
      • Stop pipelines if test suite is failing
      • Performance Test occurs as part of package phase
      • Security testing is split between code analysis (throughout the release) and Pen testing
    • Automated test standards
      • PullRequest Test flow view
      • Test Suite Flow
      • Test Run Diagram
    • Issue flow
      • Reporting issues: If something is critical and prevents you from using Salt, but is not listed as critical based on the algorithm, please tag someone in it so we can make sure it gets looked at.
    • Security Testing – what are we changing?
      • CVE’s get their own release
      • Conducting annual pen testing
      • Complete code audit performed every one to two years
      • Security mailing lists

Open Discussion and Questions

  • How can a user update on a stable release cadence?
    • Published cadence (Feb, Jun, Oct) for Salt Open and Enterprise Product suite
    • Support updates: Mar-May, Jul-Sep, Nov
    • Content or new extensions: Feb-Nov
  • What did the release label SEP actually do? How do we decide to implement SEPs in light of community objections?
    • Simplify labeling
    • Learn and follow established standards
    • SEP are intended to solve an issue. SEPs garner feedback from across spectrum, not intended for individual veto.
    • Broad reaction to an SEP
    • SEPs can be promoted by any member of the community
    • We’ll establish community advisory board – let us know if you want to be a part of it – this board will discuss and promote issues
  • Q: Regarding the Salt Open – it sounds great but some time before I asked if Salt Core Team plans to write a docs about multi-syndic configuration that is implemented but undocumented. And the answer was “no” and basically idea was to “if you want something like this – we have a Salt Enterprise”. I could understand that if feature wasn’t implemented but it’s implemented already! I still very confused by this. Issue for the reference:
    • Moe will look into this particular issue
  • Q: There was a comment in Slack that it was impossible to use any major Salt release in a while without waiting for .1 release. Do you think Salt could benefit from spending a whole major release cycle for bug fixing only?
    • Moving away from the perception that a release is only stable in a .1 or .2 release
    • Currently talking about dedicating a full release to just addressing bugs to try and work through the backlog
  • Q: How do we use GitHub labels to gain insight into the release status and blockers?
    • We don’t effectively use GH labels today
    • We’re working to change that through use of project boards, milestones, and an overhaul of our labelling system. We plan to implement those changes gradually and throughout the magnesium release cycle
  • Q: Why does Salt want only one point release between each feature release? Why did we change to the single branch? What, if any, CI/CD pipeline does Salt have? How can we improve Triage?
    • We are not restricted to one point release
    • Change to single branch ensures we avoid branching challenges of the past, reduce maintenance burden and streamlines the contribution process. It is a critical step toward where we are heading with building an automated release foundation
    • We have a CI/CD pipeline
    • Triage requires a review and improvement cycle
  • Q: Could you please clarify your statement about “never doing releases with critical bugs”? For example, the most recent release (3001.1) was released with critical bugs, such as #57543 which appear to be labeled as “Magnesium”. Do you mean by your statement that you’re only referring to regressions or do you mean all critical bugs?
    • Meant regressions. If something is considered to be critical, we need to discuss/address them but this is meant to be high priority issues that have a large impact.
    • Constantly analyzing how critical bugs don’t get looked at and added – if something falls off the board we want to look into why.
    • Need to publish taxonomy in our labels and get more rigid on what the Critical label means.
  • Q: How can a contributor understand the big picture plan so they can contribute more? What is our product strategy? What is the release plan and schedule?
    • Big Picture: we are going to hold more frequent communication by Alex/Tom.
    • Release plans and schedule are published on the wiki
    • Suggestion by Max Arnold to hold public retro will be implemented. We will hold first post the next release cycle
  • Q: Do non-critical bugs only get fixed with feature releases? If so, what happens when it makes someone unable to use Salt for months? Why continue adding features when there are still bugs and we keep introducing more without resolving them? Do we release when they have outstanding bugs that are labeled as Critical? What does it matter if you release now and get a bunch of critical bugs fixed, and then release again in 4 weeks and fix more things?
    • Bugs can be fixed in any release. We prioritized based on impact. Issue that stop usage should be labelled correctly so we address them as top priority
    • Low effort PR pulls to address bugs needs to be flagged to be addressed (part of triage and new board system)