https://github.com/osquery/osquery logo
Join Slack
Powered by
I think there are two packaging things I’d like us...
# core
s
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
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
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
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
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
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
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
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
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
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
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
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
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
https://github.com/osquery/osquery/issues/7277 it's this issue, the code part
m
Stefano said he had a documentation PR for the path changes
s
docs can land in 5.0.1
m
ok, then it sounds like we can tag 5.0 now? Stefano it's fixed in code, just not in documentation?
s
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
ok — then holding off on 5.0 tag until later today
s
Sounds like we should wait
s
s
https://github.com/osquery/osquery/pull/7276 should sneak in before we go really stable too. (Another breaking change)
s
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
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
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
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
Open in Slack
PreviousNext
Powered by