 | puma-contrib | 38 Members |
| Contribute to Puma, the Ruby webserver - discuss contributing, changes, improvements, maintenance | 1 Servers |
| puma-contrib | 38 Members |
| Contribute to Puma, the Ruby webserver - discuss contributing, changes, improvements, maintenance | 1 Servers |
| Sender | Message | Time |
|---|---|---|
| 30 Apr 2021 | ||
 msp-greg | wjordan: Do you have time to rebase and cleanup 'Refactor drain on shutdown' https://github.com/puma/puma/pull/2600? CI is a bit more stable re intermittent failures, it's likely to pass this time... | 15:04:20 |
| msp-greg | And, nice refactor, much cleaner code... | 17:12:37 |
| msp-greg | Is there a preferred way to accept PR's? Personally, I've never liked seeing 'Merge pull request...' in the commit log. I also thought that one of the options, maybe 'Create a merge commit', didn't place the commits at the top of the commit list, but maybe by their actual date. Not sure. Anyway, what does everyone think? I've used 'Squash and merge', but that does squash. There's also 'Rebase and merge'... | 20:42:27 |
 dentarg | I think squash is the right thing for a project with Puma. The whole PR as one commit that can be easily reverted if it causes problems. And GitHub puts and clear reference to the PR number in the commit title where the change was discussed. | 21:00:39 |
| dentarg | * I think squash is the right thing for a project like Puma. The whole PR as one commit that can be easily reverted if it causes problems. And GitHub puts and clear reference to the PR number in the commit title where the change was discussed. | 21:00:50 |
| 1 May 2021 | ||
 @wyhaines:matrix.org | I know that I have just lurked so far, but for what it's worth, I second the vote for squash and merge. | 01:21:11 |
| 4 May 2021 | ||
 nateberkopec | Running a little behind on my own 5.3 schedule, it will be happening "very soon". | 13:25:09 |
 Elena Tanasoiu joined the room. | 17:24:18 | |
| 5 May 2021 | ||
 Todd Lynam | Hi, I hope everyone is well. I'm wondering if someone knows how reloading ENV's during a hot restart would work in terms of how a user would update the ENV's for Puma to pick up? I've spent my career basically using Heroku so I don't know how environment variables work. Would someone update a file like /etc/environment? I don't understand how Puma will be able to see the new ENV's during a restart. Like when I update my ~/.zshrc file, I need to run source ~/.zshrc. Would we need to do something like this? Here's here we'd retrieve the new ENV's https://github.com/puma/puma/pull/2611/files#diff-602f49141abce5814cc6115eb1c4e070adcd5bf7db662a97e0d6205b2ea5402dR546 | 03:16:55 |
| msp-greg | nateberkopec: Re the test fixtures, test_puma_server.rb is 1,315 lines and 81 tests. It's the first candidate for conversion, and also being split into several files. I'm sure the fixtures will be updated for that. A few goals of the new test framework/fixtures:
| 03:37:44 |
| msp-greg | wjordan: Considering that you just worked on test_puma_server.rb... Collect all the tests that are testing the env passed to the app and place them in one test file. The default is to put the whole env in the body (with code to handle objects), and have an assert method that checks that the header 'key/value' exists once in the body? If think that would simplify the code a lot... | 03:52:35 |
| nateberkopec | msp-greg: 100% onboard. My only concerns are a) this new approach remains easy to understand and use for new contributors b) I get to review PRs that are not so long 😆 | 13:49:30 |
| nateberkopec | I would also like a better divide (maybe we just need two folders) in Puma between unit and integration tests | 13:49:52 |
| nateberkopec | also re: that one lambda: IMO all of our various "test rack apps" should be in one place. It's fine if we want to define them as lambdas or blocks and not always load them as files/config.rus, but they should have their own "place" that they go, not buried deep in a different class. | 13:51:41 |
| nateberkopec | "As a test author, I should be able to see all of our test Rack apps in one file, uninterrupted" #UserStory | 13:52:26 |
| msp-greg | Several points above... I try to respond to all. Part of the reason I mentioned GH 'Discussions' is it's somewhat easier to use when reading/composing long posts...
Three ways to help with this
I think we'd all prefer that. But, refactoring a 1k line test file cannot be easily split in 100 line chunks.
Maybe later? I've never liked the term 'integration tests', as some of them simply require Puma running in another process.
No strong feeling about that. Many of the apps generate a 'normal' body. Some them are designed to be aids for testing, like dumping the rack env to the body, since there isn't a easy way (or a need) to have it available thru the api. I think we can remove several and create just a few generic types for 'body' tests. Generally, the reason I wanted to move fixtures into the repo is that the test system changes/fixtures will evolve. There are several ideas I have for changes to what I've done, but I started asking myself questions about added complexity for what may be very infrequent test needs. I kept coming back to 'there needs to be more people contributing to this'... | 14:12:46 |
| msp-greg | * Several points above... I try to respond to all. Part of the reason I mentioned GH 'Discussions' is it's somewhat easier to use when reading/composing long posts...
Three ways to help with this
I think we'd all prefer that. But, refactoring a 1k line test file cannot be easily split in 100 line chunks.
Maybe later? I've never liked the term 'integration tests', as some of them simply require Puma running in another process.
No strong feeling about that. Many of the apps generate a 'normal' body. Some them are designed to be aids for testing, like dumping the rack env to the body, since there isn't an easy way (or a need) to have it available thru the api. I think we can remove several and create just a few generic types for 'body' tests. Generally, the reason I wanted to move fixtures into the repo is that the test system changes/fixtures will evolve. There are several ideas I have for changes to what I've done, but I started asking myself questions about added complexity for what may be very infrequent test needs. I kept coming back to 'there needs to be more people contributing to this'... | 14:14:23 |
 Chien-Wei Huang (Michael) joined the room. | 16:42:16 | |
 Alan Halatian joined the room. | 22:11:40 | |
| 6 May 2021 | ||
| nateberkopec | wjordan landed a big change in Rack: https://github.com/rack/rack/pull/1748 | 13:42:51 |
 wjordan | In reply to @nateberkopec:matrix.orgHopefully doesn't change _too_ much, just clarifies an existing implicit distinction moving forward... the part relevant to Puma is that sending out an array-of-strings response body in a single write/writev syscall now has a more clearly-defined interface in the spec. | 14:20:32 |
| nateberkopec | hey it's a lotta lines, so it's big! | 22:28:59 |
| nateberkopec | will release 5.3 tomorrow AM | 22:46:15 |
| 7 May 2021 | ||
| nateberkopec | 5.3 out! Will try to get back on the usual 4 to 6 week release schedule now. | 14:50:50 |
| 10 May 2021 | ||
| nateberkopec | msp-greg: So you think https://github.com/puma/puma/issues/2624#issuecomment-836719949 this is an ubuntu (or other linux distros) problem only? | 13:52:36 |
| msp-greg | Yes. I'll clarify in a moment. Actually, only an issue with Ubuntu using TCP or SSL sockets... | 13:55:31 |
| 11 May 2021 | ||
| nateberkopec | if anybody is online and wants to get pulled into a security issue, dm me | 00:55:33 |
| nateberkopec | (the issue was fixed 😆 | 21:28:41 |
| nateberkopec | * (the issue was fixed 😆) | 21:28:46 |
| 13 May 2021 | ||
 klaibthe joined the room. | 19:20:37 | |