Open Hour 2020-NOV-12

January 23, 2021 - slangadmin


Meeting Notes

General News

Point Release: Nov. 18th, Wed.

  • Fix or revert for the memory leak planned, with point-release on November 18th
  • There will be a community retrospective after the point release, during the Open Hour on Nov. 19th

Working groups, community calendar, and general community news and updates

  • All Zoom Meeting IDs will change date is TBA
  • Working Group Captains will be informed and any documentation will be updated
  • Community Calendar will be moving to Office 365 date is TBA
  • salt-users, salt-packagers, salt-announce will stay public Google Groups

Checkout the SaltStack community Google calendar for upcoming events and streams.

Do you want to get more involved in salt and the SaltStack community? Get involved:

Docs Working Group

Existing SEPs

All PRs in the SEPs repo represent open discussions on Salt Enhancement Proposals.

Discussion Q&A

From IRC: MTechnology: “Could someone /please/ reconsider the naming scheme? Dropping the .0 from .0 releases is a pain in the butt to deal with.”

Wayne was able to catpure most of the real time conversation in IRC

  • wayne: There’s a lot of administriva, and we need people/help to get those SEPs to that point
  • sage: there’s a lot of opportunity for improving visibility about where in the process
  • MTecknology: I’ll bring that up 🙂
  • sage: I saw that request in IRC… I think we have a reason we decided to do that?
  • wayne: Not that I’m aware of – at least 3000 vs 3000.0 – a big reason we changed was a huge change vs the date-based
  • gareth: clarification – is the ask just to do 3003.0 vs. 3003?
  • wayne: yes (at least IIUC)
  • pedro: We do use 3000.0 on the bootstrap script to pin to minor versions, but that doesn’t change the actual Salt version
  • Barney: MTecknology what’s the problem with the lack of .0?
  • pedro: (it’s actually a workaround for not having the .0 in the version number)
  • sage: we may need more information about the why/pain points to make a different decision

From IRC: lordcirth__: It is rather inconsistent to not write the .0 Though I’ve not had a specific technical problem as a result – yet. From IRC: Edgan: I could see if he is trying to break the version down into it’s components he would have to have to have a if minor_version == ” then don’t .{{ minor_version }} But if you treat it like a single string, {{ version }}, you wouldn’t have this problem.

(general discussion)

  • Pedro: we are PEP 440 compliant (with the version)
  • Sage: Maybe we just need some more communications around it
  • dwoz: prefers continuing to do things as we are today (i.e. major, then major.patch)
  • wayne: I don’t see a compelling reason to not add the .0, at least if there’s a reason it causes some pain.
  • sage: I’ll check to see if there’s any confusion around the versioning
  • Sage: On working groups – we’ve discussed some more specific project plan/documentation around the working groups
  • sage: We’ve also looked at forming a kubernetes WG (discussion around Kubernetes WG, w/gareth)
  • sage: I have some discussions next week with VMWare kubernetes groups next week, that would be super exciting to get some more things going with that

From IRC: myii– waynew: Here’s one situation where the lack of .0 is a pain: # Handle version number when installing a .0 release with git, where the .0 is not present in the version number in PyPI ( ^ Bootstrap handles 3002.0 fine for stable but not for git. (stable vs. git-based installations).

  • gareth: does this go back to the discussion we had in the past?(discussion, not really)
  • sage: I think we can just discuss where we are today, and maybe where we need to move forward?
  • sage: do we need a SEP?
  • dwoz: I’d love bryce’s take, we can probably go back and fix old ones
  • sage: that would be a big change, needs communication
  • dwoz: probably not worth doing it retroactively
  • gareth: opening a SEP – would we have arguments /against/ adding the .0?
  • sage: I think this is good for a SEP, we should also do blog post & other communication
  • megan: we will need to add some code changes

From IRC: MTecknology: I got distracted… I don’t know specifics about many of the issues, but part of it is indeed breaking it down into it’s components. $current_employer considers it a violation of policy for everything to not have the exact same version. I would expect whole string matching to be sufficient, but apparently it’s causing a problem for many home-grown scripts. I’ve heard (2nd hand) that this is a problem for some home-grown scripts at other companies as well. It’s also just confusing. Sometimes “3002” means “3002.0” and other times it means “3002.x”. Even the current repo layout, it’s not obvious what means what.