Lots of old patches: 1200 over 9 years. Taking a square distribution… 200 patches in the last year? that is, a 10 patchs per week. For the whole blender… Wow, that’s a problem!
My patch is not accepted for a long time, or not considered: why is the inspector to blame. And can this inspector really do it? Have you made a mega patch that rewrites half of the program? …
My patch was accepted by one of the verifiers, but not by the other: Mh…
My patch took a very long time to update to master: Hmm…
My patch: … Stop. Who else is working in this area? Did you agree on this beforehand? Did your patch stop merging properly because someone was doing more consistent work elsewhere? Was your work pre-agreed, or did someone who already did it have to redo their plans because of you?
The problem is that there are few specialists to check: Yes. And I don’t think that a quantitative increase in specialists will help. More complex review steps could help. For example, so that at the beginning the review would be carried out by those who are not a high-level specialist and can weed out beginners, like me a year ago (my first patch is still not accepted, in it I taught c ++, blender api, tracked changes in the api I was using added and removed a bunch of features depending on the change of vision, …) and if I could not waste the time of one of the two owner of the module with this patch, it would probably be so great
Another approach, not mentioned here, is introducing a QC & QA team, to not only do the testing of patches, but also do the work to make patches align with both the coding and design standards as well as pruning bad ideas. So, basically, would this QA & QC team be the first to deal with contributor patches, no matter what module the contribution would belong to. Having QA & QC team would also ensure the quality of BF dev patches. Actually, thinking about it, with a huge code base in Blender, it is quite surprising that there isn’t a QA & QC team.
I’ll troll a little, finally. All these open patches have been successfully handled by sending to the trash, sorry by archiving.
Well, if you don’t have a local copy of the patch, then you won’t be able to find it in this archive, even your own, so it was all just lost. Welcome to the wonderful world of open source.
The saddest thing is that it is unclear whether any conclusions have been drawn and whether something has changed…
Well, if you don’t have a local copy of the patch, then you won’t be able to find it in this archive, even your own, so it was all just lost. Welcome to the wonderful world of open source.
Why not? It’s not like they are that hard to find?
done! all patches are listed! Just search for your name find the diff you want click on it, full review is preserved, with an option to download the raw diff in the upper right corner.
Yeah, the problem lies right here. It doesn’t look like something is loading, at least in my Safari.
So I probably just go back as soon as Safari showed that the page is fully loaded.
To be fair, the First thought I had was “that wasn’t like that before…I know because I tried finding a diff and there wasn’t a list, just a suggestion to enter Dxxx (if I recall correctly.)”
I see it was added in the following commit, which came a month after the Gitea switch.
So I can see why someone would think that the diffs were almost impossible to find, if they were unaware of the update as I was.
All these rejected patches dilemma would be solved if we had a proper C++ plugin api
so much work wasted, so many enthusiastic project that will never see the light of day…
The transition to a new code hosting system may have left a lot of patches behind, and everything may feel like a new start, and this thread has been archived. Though this may feel like a solution, it really isn’t, is it?
You can port patches over. I didn’t because I had changed enough that it was easier to just start over while I learned how the new system worked. Learning the new system was a lot easier than it appeared, fortunately chat was there to help unconfuse me a couple times.
For the patch author, all they’d need is a git remote set-url origin git@.... and git push origin my-branch to send their work to Gitea. For Blender Foundation, due to the internal differences between Phabricator and Gitea, it would have been a huge job to convert all the patches.
If the patch authors aren’t around any more, it’s dead in the water anyway. If they are still around, they can just push to the new system.
