Is http-parser alive?

[janekolszak]

I'm sorry for this question, but is http-parser project alive?

I see many pull-requests ready for a merge and there are still some things that need attention.

[bnoordhuis]

It's alive, it's maintained, it's just not anyone's top priority. Many of the open pull requests require a major version bump and that is not expected to happen anytime soon. Others are bug fixes that will get merged once a new patch level or minor release is made, which isn't often. Hope that answers your question.

[ploxiln]

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.

[bnoordhuis]

#364 approved 2 months ago, forgotten

You overlook that's my pull request. If I'm in no rush to merge my own, I'm certainly in no rush to merge others.

The current process works well enough for us maintainers and I'm enough of an egotistical bastard that that is all I really care about. Probably not what you want to hear but that's how it is.

[ploxiln]

I certainly did recognize that it's your own pull request (in addition to already being "approved" for whatever that's worth). That makes it even more silly.

The upside is that no one should bother submitting any fixes, no matter how small and critical, because it appears to be all for naught. Even your own small critical fixes are not even merged to master, PRs and Issues just pile up indefinitely. (I don't demand response within the hour, or even within a week, I'm a very reasonable person. But, months, that's silly.)

Again, I don't think you should be accommodating, friendly, easy to work with, at the beck-and-call of anyone who opens an issue or PR, nothing of the sort. Just close shit after a couple of months, for your own benefit. The status-quo is just nuts.

[indutny]

All mentioned PRs just landed to master branch.

Unfortunately, my focus is not infinite and I can't keep in it all of the projects 😢 Sorry for this!

[ploxiln]

Thanks, it's appreciated.
This issue can be closed IMHO.