Concerned about the pace of merges

[peacechen]

The rate of PR merges has been quite slow, even for relatively trivial fixes. A short, non-comprehensive list of issues and PR's that can and should be fixed have been languishing for weeks or months:
#117
#149
#144

We're using this table in a production environment and needed those fixes (and others) yesterday. I've pinged numerous times on PR's and it's still taken week(s) to get them merged. What can be done to improve that? I'd prefer that my fork stay in sync with this repo so that I can continue to contribute, but at this rate my fixes will move too far ahead and I won't be able to.

[matthewoestreich]

I thought you had permissions to push code? Do you not?

[matthewoestreich]

I've just been rather busy lately. I was laid off during covid and have been trying to keep my head above water.

I'm open to suggestions on how to improve the pace of merges if it is an issue.

[peacechen]

I'm saddened to hear that you were laid off. Best wishes with your job search. Contact me if you'd like additional job connections.

I wasn't aware that I had permission to push to this repo. I'll try doing so. Do you prefer to merge PR #144 or should I cherry pick and commit directly to this repo?

[matthewoestreich]

My take is that we need more people to help with things like this. That was one of the major reasons this fork was created. It's supposed to be a maintained community fork, so we need to allow the community to help maintain it. The tricky part is the "core" team (whoever that may be) still needs to be on the same page. Aka we don't want bad code pushed. Imo the fixes you have provided are crucial and need to be addressed. @Domino987 has been finishing up a thesis I believe so he has been extremely busy lately.

We want to make sure this repo doesn't go stale, so thank you for bringing this up.

[peacechen]

It's returning "Access denied" when I push to this repo. I don't recall receiving a collaborator invite for this project.

[Domino987]

Hi,
thank you for your contributions so far.

So I see your concerns but as far as I can see there is only one PR and the rest are issues which I did not had time to fix yet.

I can see how not merging for a few weeks might seems slow, but as already mentioned, we are currently a little bit preoccupied and we do the best we can. Also we want to make sure not to break anything and test anything merged prior to merging.

As you well know we are doing this in our free time and we spare as much time as we can.

The big problem with adding more people to merge/release permissions, that this would probably lead to you merging your own PRs, without feedback, which could lead to problems further down the road.

I see that we already merged 5 PRs from you. So I would suggest that you keep adding stuff you need/propose as PRs and I will dedicate more time to try to get them merged faster.

I hope all of you stay safe during those times and @oze4 I hope you will find a good opportunity soon. If you need anything, let me know.

[peacechen]

Thanks and good luck with your thesis.

The other PR's were on hold because new commits to my fork would've piled onto the other PR. I just submitted a fresh PR for #117, and have another for #149 once that one is merged.

Github's PR system is limiting because we can have only one outstanding PR per branch. While I could create multiple branches, we need all these fixes ASAP. We don't have access to them all together if they're on separate branches.

I'm all for code reviews, but that falls apart when no one is reviewing. What do you think about opening up a development branch where people can push commits quickly while waiting for review? The other part of the equation is publishing updates to npm which is a similar bottleneck.