https://github.com/osquery/osquery logo
Powered by
#core
Title
# core
s

seph

08/25/2021, 12:58 AM
I think there are two packaging things I’d like us to do before 5.0 goes stable. So, I’ve set a 5.0.1 milestone to hold those. This way we can cut a 5.0.0 release/tag for the beta. Note that I do not expect 5.0.0 to ever become stable, but instead to serve as a fresh iteration point. I know there are folks excited to test it
m

Mike Myers

08/25/2021, 5:11 PM
Let's not add anything that delays 5.0. We can create a signed standalone 
osqueryd
for macOS at any point after tagging 5.0.
Just a reminder, we originally discussed 5.0 immediately following 4.9, but it has now been more than a full release cycle
◦ Plain macOS signed osqueryd binary: so we'll add a codesign step in the GitHub action ◦ We are fixing the default service paths on Linux and the documentation to reflect that That's it and we can tag 5.0 right?
No new wishlist items added before this release, that's what I want us to commit to
s

seph

08/25/2021, 5:31 PM
We always intended to distribute a signed bare osqueryd. But we didn’t realize it wouldn’t work this way until we tried 🙂
I think: 1. we should cut a 5.0.0 today. 2. I don’t expect it to become stable 3. I think we should aim for a 5.0.1 or 5.0.2 as stable. 4. But I’m sure people want to start playing with 5.0.0
TBH I’m not sure I feel like there’s much wiggle room for me on any of those?
m

Mike Myers

08/25/2021, 5:37 PM
I feel like we can do the two things today from your 5.0.1 milestone
then it just becomes 5.0 unless there's osmething wrong with it
s

seph

08/25/2021, 5:37 PM
Sure. But I’m kinda assuming we’ll find some bug. It’s a lot of churn.
Would you rather we cut a 5.0.0 now, and then itearated and planned on a 5.0.1, or for me to hold off and we can cut a 5,0.0?
(Note that Stefano disagrees with something in that milestone, and he may be right)
m

Mike Myers

08/25/2021, 5:38 PM
I just talked to the guys and they really think the two tasks can be knocked out today
then a 5.0 tag would be good
s

seph

08/25/2021, 5:39 PM
Yes. I’d bet any of the cmake folk can handle the bare osquery one in a couple hours
But what would you prefer? Cut a 5.0.0 now, or hold till tomorrow?
I may not manage release notes today. But I think they can merge post
m

Mike Myers

08/25/2021, 5:40 PM
Bug discovering: that's entirely possible, my goal is just to keep the release from creeping any further. 5.0 checklist (notes) can be done after the tag, right?
Prefer to cut a 5.0 today but I was going to say later today, we have two PRs to merge that are in progress
s

seph

08/25/2021, 5:41 PM
We’ve done the changelog both before and after. Downside to after, is that it doesn’t show up in any built packages. Downside to before is that it’s more work 🙂
I’m going to be surprised if there are no bugs that merit another release in this line. So I see an early 5.0.0 as a way to get testing turned around faster. But I think you’re the person feeling the most urgency. so I can defer to you
m

Mike Myers

08/25/2021, 5:42 PM
I can try to help with that then. It's a two step process, first you auto-gen from commit comments and then we clean up / add details right
s

seph

08/25/2021, 5:43 PM
Yes. And the tooling to auto gen is checked in and documented. Mostly, I’m trying to get another thing done for kolide this afternoon.
m

Mike Myers

08/25/2021, 5:46 PM
Well we need at least the PR to unbreak service paths in Linux from Stefano, then we can tag 5.0 whereupon it'll have working pre-release packages for people to test. Changelog and the additional GH Action for signing the standalone osqueryd on macOS will go in before a 5.0.1 tag.
s

seph

08/25/2021, 5:47 PM
Another service path bug? I know I merged one PR for that.
I’m pretty happy to cut 5.0.0 whenever you feel like you want it. And I’m expecting we’ll need a 5.0.1
s

Stefano Bonicatti

08/25/2021, 5:47 PM
https://github.com/osquery/osquery/issues/7277 it's this issue, the code part
m

Mike Myers

08/25/2021, 5:47 PM
Stefano said he had a documentation PR for the path changes
s

seph

08/25/2021, 5:48 PM
docs can land in 5.0.1
m

Mike Myers

08/25/2021, 5:48 PM
ok, then it sounds like we can tag 5.0 now? Stefano it's fixed in code, just not in documentation?
s

Stefano Bonicatti

08/25/2021, 5:48 PM
we haven't updated any paths in the code.. and so service files internally are referring to the wrong paths for osqueryd, plus a couple of other incorrect default paths. What we have fixed yesterday was where CMake was installing those service files.
m

Mike Myers

08/25/2021, 5:49 PM
ok — then holding off on 5.0 tag until later today
s

seph

08/25/2021, 5:49 PM
Sounds like we should wait
s

sharvil

08/25/2021, 5:49 PM
s

seph

08/25/2021, 6:12 PM
https://github.com/osquery/osquery/pull/7276 should sneak in before we go really stable too. (Another breaking change)
s

Stefano Bonicatti

08/25/2021, 6:17 PM
There will be other breaking changes soon after 5.0, because it's stuff we didn't manage to do now; I don't see it as a 5.0 blocker. If we can sneak it, fine, but I wouldn't stop for it.
s

seph

08/25/2021, 6:18 PM
There will be other breaking changes soon after 5.0, because it’s stuff we didn’t manage to do now
Do you have something in mind? We generally try really hard not to break things
s

Stefano Bonicatti

08/25/2021, 6:21 PM
I'm really trying to make a difference between things that will break osquery and things that might/will break something for the customer using it. I don't want to delay this release; spec changes or similar can be delayed, we already did that anyway.
So I wasn't meaning anything that would break osquery.
Ok let me rephrase; there are other things that we know we want to do that will maybe break stuff for the customer if merged (meaning the customer has to change something). I know we sort of called 5.0 as the breaking changes release but we didn't got all of them there; It's fine, we have inserted other breaking changes on other versions anyway. I don't want to stop a release for them.
s

seph

08/25/2021, 6:28 PM
I think I’m mostly in alignment. That PR specifically, was originally just going to hide some columns. But if it squeeks in, we can drop the columns and option. But I kinda don’t want to drop options randomly, we’d instead just noop them. So I think it’s all about code cleanliness.
Anyhow…. Draft changelog. I didn’t wordsmith at all yet. https://github.com/osquery/osquery/pull/7284/files
2 Views
Powered by