Almost forgot about this, did a PR get added?
One thing I don’t get about how Blender is managed from this point out is how anything manages to get merged - there’s 1400 PRs outstanding! Most are waiting for review and/or have file conflicts.
…What has to happen for this to actually get into a build?
I don’t think there’s a PR. If there was I’d think it would be promoted here in this very forum topic.
How many PRs are outstanding is not really a good measure of how hard it is to get something merged. Abandoned plans just never really get explicitly abandoned and abandoned (for whatever reason) PRs just stay around in ‘outstanding’ state. So if you come back in a few years there will probably be 2800 ‘outstanding PRs’. Such is the nature of open source.
Better to look at what actually gets merged, a lot of what gets merged starts out as a PR. ( blender/blender - blender - Blender Projects )
I guess you maybe sort of meant it sarcastically? But that’s what needs to happen.
As far as I can see skimming through this topic nobody actually did the work of actually creating a PR on projects.blender.org. Some people tried to get up to speed but got bogged down some way or other (I can’t blame them. I have a few halfbaked PRs in my own blender fork. Often real life interferes and you need to stop working on something for some months and it’s hard to pick up again).
No I wasn’t being sarcastic (pessimistic, perhaps).
The reason I mention it is that it creates the need for an additional step as you outlined, which wouldn’t be necessary on a smaller project with a short PR list (the PR list itself becomes a more useful tool for committers). So this is just ignorance on my part working with a large OSS team. The additional step being:
I’ve worked with and authored PRs for smaller projects. But this ^ is the mystery for me on a very large OSS project. How do we get the attention of those core devs without being a pest? Spamming and annoying devs who do this for free isn’t the best etiquette.
I haven’t seen any negative reactions to this addition, but as far as I’m aware no committer has weighed in at all one way or the other, yet.
(It’d also be good to have at least one other than myself to confirm that this looks good, but I assume the one doing the merge will and should be contributing on this front.)
I guess the TL;DR to the above is–what’s the process to actually get a PR merged? Perhaps get a developer (I assume this means committer) to create a thread on Feature & Design Feedback - Developer Forum to get it reviewed?
Step one is actually creating a PR. When there is no PR there is nothing to
see the relevant chapter of the developer handbook:
Then when there is a PR , it’s often easiest to ask if someone wants to review on chat.blender.org . Creating another thread here seems unnecessary, just link the PR in this thread.
Been some time now.. but I think I’d be more comfortable if @David_Easley were the one submitting the PR for this.
Hey! I am actually planning on re-visiting this next week. I got partway through the process to make the PR last time, ran into some hurdles and got bogged down with work again. I’ve got a few weeks off starting the middle of next week, and getting this over the finish line (or at least fully submitted as a PR) has been burning a hole in my queue and I fully intend to get it sorted soon.
Sorry about the delays! Been a very busy 12 months for me.
Update: Taking a look at it this weekend 
PR cut
Awesome - looking forward to this!
Glad it hasn’t become irrelevant, haha!
I made some tweaks under the hood (particularly for getting the active step index, using a pre-existing BLI function now), if you get the chance to build the current PR versions could you check your add-on still works like you expect?
Or do you have a repo out there for the add-on? I could fetch it and add it to my local version to test.
Yeah I should start getting the plugin to the public domain, I’ll have to see what kind of state I left it in. It won’t be a big repo but I’m sure it needs some polish. I didn’t even have it in Git since it was just a test that kind of turned into a mini project…
I’ll try to do another test within the next few days, at least.
Just did a really fast build and test for now, but… it still works!
I’ll definitely need to improve a few things (for one, the font is tiny on the higher DPI monitor I have now so I guess I need some way to configure that) but this looks really good so far. Changes show up automatic, undo and redo hotkey presses update the list.
I do recall, I’ll need to filter out those MemInternal things which show up ‘randomly’ but that shouldn’t be a big deal. Hopefully you remembered to expose that ‘skip’ parameter so I can use that to ignore those entries.
Glad it still works! Based on PR feedback, I’m likely switching “skip” to “is_substep” instead, so you can look for that after I push my next commit.
Sure, I’ll give that a look as soon as I can.
Juggling a lot of projects right now though - if you don’t hear back from me in a few days don’t mind pinging me as a reminder. 
I want to do what I can to support this to the end…
Everything is still working, but having trouble reproducing the is_substep/MemInternal entries to be able to confirm that I’m getting the is_substep flag. Just fussing around in Blender for a short time doing random stuff doesn’t seem to be triggering it. So that’s making it hard to test whether I’m handling it correctly yet.
Might need to let it log to console during a real project to get enough use to see it happen.
On the bright side though I figured out I don’t even really need my undo/redo handlers at all. This draw callback is all that’s really needed (of course..):
def register():
global draw_handler
draw_handler = bpy.types.SpaceView3D.draw_handler_add(
draw_callback, (), 'WINDOW', 'POST_PIXEL'
)
But I’ll leave them in anyway since it’ll help with debug logging..