Please close open PRs which will not be merged about assimp HOT 7 CLOSED

Hi, it is impossible to merge all the PRs, Some of them are not updated and I cannot update them all by myself. And doing the merge takes time. If my only job would be to merge all the PRs I would fully agree. But currently, I am trying to find the time only in the evening.
And there are some PRs where I am waiting for feedback. Shall I close these PRs when the people have invested their time to provide a solution? Doing a review takes time as well. Then the CI finds issues and so the PR is stalling again.

I understand your frustration: it is so easy to merge PR's, so many open issues and nothing happens, and a lot of idle in the project. It is the same for me. When I only have 1 hour per day for this project I can't fulfill your requirements, sorry.

from assimp.

One example: #5308

I have already approved the PR. But it needs some love: rebase it. Caused of the kind of PR I am not able to do this automatically, I have to do it manually. The developer seems not to have the time as well.

from assimp.

Please feel free to share other ideas to optimize the way PRs get merged. Sorry for beeing so rude.

from assimp.

There are a few issues you mentioned here and reddit, and I think you need to deal with them separately.

1. Unfinished. You cannot do anything with that. People should submit a PR for finished work. If it's not finished, it's a bug farm and nobody needs that. I also think it's a bit amateur to submit unfinished work to what I presume is a release branch. If it's WIP, work in another branch.
2. "findings in code" and "original author" is unclear to me. If you mean the original author of the PR and they're not responding, sorry. Follow your work through to integration and QA it. If they don't respond, it's out. If you mean the original author was someone that wrote a specific importer that was included in assimp, I think that falls on you a bit. You may not be the original author, but now the "owner" of that bit of code. Maybe look for another "owner" if you don't have the bandwidth, but I think I don't think a PR should necessarily be taken because it "appears safe". It needs to be verified.
3. Rebase: This is life. The person that submitted the PR needs to rebase if they want to ensure their code is pulled properly. Otherwise, it's a local fix.
4. The PR has to make sense for the project. I think this is self evident.
5. I think people need to accept with any open source project that they may need to do a local fix. I, myself, use a newer version of zlib than assimp in my engine and I've made so many changes to how assimp builds to use my project's zlib that it's scary for me to update to a newer version. Not because it's hard, but because I forgot what I did and too lazy to diff some files. Someday I'll sit down and do it. I don't mean that as a complaint, merely re-enforcement of issue 3 and a little of 4. A local fix is, sometimes, just good enough. If someone submits a PR and walks away.. maybe there's a little bit of this going on?
6. I think I would otherwise agree with @tellypresence .. if people walked away, close them. If it was important, they can re-open.

from assimp.

I guess I could comment on "optimize" the way PRs get merged. You mentioned you have 1 hour per day. Two real things come to mind:

1. Schedule a day to do PRs.. like Monday I do PRs. That's built into my schedule, that's what I do that day. No PRs, I can do something else. Presumably these PRs are good and you want them. This may actually help improve cadence and you can feel like you're accomplishing things faster.
2. Recruit someone to help out. You're human. You have a life. You're not a slave to a project, and you don't have to carry 100% of the load. You only have to get someone that will follow your roadmap.

from assimp.

Github has the merge queue feature to help with this. I proposed we use it but it got no traction
#5180

from assimp.

I had raised this because it seemed a backlog of PRs might have been delaying a hotfix for breakage in the X importer (#5332). The hotfix PR (#5372) has been merged so the urgency has passed.

I'm wondering if there's some way to make it easier to manually test changes to assimp importer code in an OpenGL implementation, to reduce the burden of visually checking that importer code hasn't broken after modification. One of the unfortunate aspects of this regression was that unit tests wouldn't have been that useful in catching the problem -- asserting on the number of meshes wouldn't have helped (model still had 2 meshes) and asserting on model containing animation wouldn't have helped (model still had animation). One of those times were an old-school manual, visual check in an OpenGL viewer was the only reliable way to catch the problem, which was immediately obvious to a human but not to even a decent set of unit tests.

from assimp.