!blREBEDhVeXTYdjTVT:matrix.org

puma-contrib

28 Members
Contribute to Puma, the Ruby webserver - discuss contributing, changes, improvements, maintenance1 Servers

Load older messages


SenderMessageTime
30 Apr 2021
@msp-greg:matrix.orgmsp-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:matrix.orgmsp-gregAnd, nice refactor, much cleaner code...17:12:37
@msp-greg:matrix.orgmsp-gregIs 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:matrix.orgdentargI 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:39
@dentarg:matrix.orgdentarg* 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.orgwyhainesI 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:matrix.orgnateberkopecRunning a little behind on my own 5.3 schedule, it will be happening "very soon".13:25:09
@elenatanasoiu:matrix.orgElena Tanasoiu joined the room.17:24:18
5 May 2021
@tlynam:matrix.orgTodd 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:matrix.orgmsp-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:

  1. Unify socket type selection between clients (sockets), in-process Server instances, and IO.popen Puma instances.
  2. Have a generic method for creating a stream of clients, which can also be used for benchmarks.
  3. Improve logging when client streams are used. Some of the new 'integrations' tests are using hundreds of clients.
  4. Make.It.Stable.
03:37:44
@msp-greg:matrix.orgmsp-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:matrix.orgnateberkopec 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:matrix.orgnateberkopecI would also like a better divide (maybe we just need two folders) in Puma between unit and integration tests13:49:52
@nateberkopec:matrix.orgnateberkopec 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:matrix.orgnateberkopec"As a test author, I should be able to see all of our test Rack apps in one file, uninterrupted" #UserStory13:52:26
@msp-greg:matrix.orgmsp-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...

this new approach remains easy to understand

Three ways to help with this

  1. Document the code in the helpers/fixtures just like lib code.
  2. An overview document describing the test system should be added
  3. The folder with the test fixtures can be added to the docs shown at puma.io
  4. Remind people that reviewing existing tests is the easiest was to see the fixtures in use

I get to review PRs that are not so long

I think we'd all prefer that. But, refactoring a 1k line test file cannot be easily split in 100 line chunks.

divide unit and integration tests

Maybe later? I've never liked the term 'integration tests', as some of them simply require Puma running in another process.

should be in one place

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:12:46
@msp-greg:matrix.orgmsp-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...

this new approach remains easy to understand

Three ways to help with this

  1. Document the code in the helpers/fixtures just like lib code.
  2. An overview document describing the test system should be added
  3. The folder with the test fixtures can be added to the docs shown at puma.io
  4. Remind people that reviewing existing tests is the easiest was to see the fixtures in use

I get to review PRs that are not so long

I think we'd all prefer that. But, refactoring a 1k line test file cannot be easily split in 100 line chunks.

divide unit and integration tests

Maybe later? I've never liked the term 'integration tests', as some of them simply require Puma running in another process.

should be in one place

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
@kuei0221:matrix.orgChien-Wei Huang (Michael) joined the room.16:42:16
@alanhala:matrix.orgAlan Halatian joined the room.22:11:40
6 May 2021
@nateberkopec:matrix.orgnateberkopec wjordan landed a big change in Rack: https://github.com/rack/rack/pull/1748 13:42:51
@wjordan:matrix.orgwjordan
In reply to @nateberkopec:matrix.org
wjordan landed a big change in Rack: https://github.com/rack/rack/pull/1748
Hopefully 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:matrix.orgnateberkopechey it's a lotta lines, so it's big!22:28:59
@nateberkopec:matrix.orgnateberkopecwill release 5.3 tomorrow AM22:46:15
7 May 2021
@nateberkopec:matrix.orgnateberkopec5.3 out! Will try to get back on the usual 4 to 6 week release schedule now.14:50:50
10 May 2021
@nateberkopec:matrix.orgnateberkopec 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:matrix.orgmsp-gregYes. I'll clarify in a moment. Actually, only an issue with Ubuntu using TCP or SSL sockets...13:55:31
11 May 2021
@nateberkopec:matrix.orgnateberkopecif anybody is online and wants to get pulled into a security issue, dm me00:55:33
@nateberkopec:matrix.orgnateberkopec(the issue was fixed 😆)21:28:41
@nateberkopec:matrix.orgnateberkopec * (the issue was fixed 😆)21:28:46
13 May 2021
@klaibthe:matrix.orgklaibthe joined the room.19:20:37

There are no newer messages yet.


Back to Room List