You really aught to close more PRs that you never intend to merge. See for example #276 - if you think it's dumb, close it.

Or, a stranger set of examples - pull requests which have been approved by multiple maintainers for many months, but then after that review work, forgotten about instead of merged:

simplify parsing M-SEARCH method, group P methods #323 opened a year ago, approved by multiple maintainers 6 months ago, forgotten
Fix FALLTHROUGH warning in switch of GCC7 #357 approved 3 months ago, forgotten
Ignore Upgrade header outside of 101 response. #364 approved 2 months ago, forgotten

It doesn't make sense to wait until just before release to merge approved pull requests - this causes more merge conflicts and prevents testing of the combination of all the changes before release (by other people preparing pull requests and various other third parties that might use master).

There are also a large number of Makefile update/fix pull requests. This project should probably admit that it does not want to maintain a makefile for building and installing a library on any system, the Makefile is only really used for building and running tests. All major projects incorporate the main source file into their own build system. You should probably admit that you have no interest in reviewing Makefile changes and close all those PRs.

I want to stress that I understand that it's not beneficial to merge just anything into a stable and depended-on project like this, and that maintenance takes time and the maintainers are generally busy. But even considering that, a lot of your treatment of this project still doesn't make sense. It should take less than two months to decide whether a small PR should be merged or rejected.

If you've already decided to merge it, merge it. If not, reject it. Save everyone, including yourself, time and effort.

Uh oh!

Uh oh!

Is http-parser alive? #372

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions