Managing PRs - using Draft status

[p-bakker]

Just a quick notification to all: I've started to convert some PRs to draft status, so the backlog of active PRs that are actually to be reviewed and considered for merging is smaller and thus more manageable.

Hope this helps the maintainers to better manage things. If it doesn't, we'll revert course

See #1384 (comment) for the request from @gbrail to do this

At the moment we're below 20 non-DRAFT PRs, but still some quite old ones that I need to weed through

[gbrail]

Yes -- there is a "bottom 2/3" of PRs that are really old and I can't see a path to merging any of them -- either I don't have the expertise in some of the 10 different types of Java interop that would be needed to understand if they'll break things, or they're just really old and need an update. Any ideas how to address those?

…

On Sun, Sep 8, 2024 at 12:40 AM Paul Bakker ***@***.***> wrote: Just a quick notification to all: I've started to convert some PRs to draft status, so the backlog of active PRs that are actually to be reviewed and considered for merging is smaller and thus more manageable. Hope this helps the maintainers to better manage things. If it doesn't, we'll revert course See #1384 (comment) <#1384 (comment)> for the request from @gbrail <https://github.com/gbrail> to do this At the moment we're below 20 non-DRAFT PRs, but still some quite old ones that I need to weed through — Reply to this email directly, view it on GitHub <#1616>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I27Y2EGWFGXKVPVVFDTZVP5OHAVCNFSM6AAAAABN2XZCECVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXGE2TCMBXGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[p-bakker]

Lets start with the non-interop ones:

• Set optimization level to -1 when generating debug information #119 & load() doesn't update global scope with -require option set #85 any comments on their merits? Yes they need a rebase, but the changes make sense to me, just not sure what else besides a rebase it'll take to get them merged
• Add a setting to CompilerEnvirons to allow the 'use strict' directive… #354 Can you check my comment on that one? I think we can close that one as Not Planned

Then for the Java Interop ones:

• fix unnecssary synchronized issue for NativeJavaPackage.getPkgProperty: #601 Is there still merit to this one? I know you wanted to get rid of synchronization? If there's still merit, the MR needs to be updated
• Improve4 JavaMembers with cache and lazy load for improve the performance #619 This one seems ready for merge, if rebased? All your comments seem to have been addresses I think
• RFC: Add generic type support and improve java.util.{List,Map} handling #827 Seems to still have merit and @rPraml is still active, so I think we can work on moving this forward
• Should ScriptableObject.sealObject also prevent modifications of parent and prototype #1085 & Allow freezing of NativeJavaObject and subclasses #1541 The merit of both these is still being discussed (albeit on a slow schedule :-) )

[gbrail]

And in addition -- I have worked on projects that have a "waiting" status, so that maintainers / reviewers can basically flag, "I'm not looking at this until you answer my last question" kinds of things. They also nag the person who should answer the question, and nag maintainers if they don't look at something that they are not waiting for information on. Not sure how much of that is default GitHub and how much is an add-on. Anyone else have experience with that?

…

On Sun, Sep 8, 2024 at 12:40 AM Paul Bakker ***@***.***> wrote: Just a quick notification to all: I've started to convert some PRs to draft status, so the backlog of active PRs that are actually to be reviewed and considered for merging is smaller and thus more manageable. Hope this helps the maintainers to better manage things. If it doesn't, we'll revert course See #1384 (comment) <#1384 (comment)> for the request from @gbrail <https://github.com/gbrail> to do this At the moment we're below 20 non-DRAFT PRs, but still some quite old ones that I need to weed through — Reply to this email directly, view it on GitHub <#1616>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I27Y2EGWFGXKVPVVFDTZVP5OHAVCNFSM6AAAAABN2XZCECVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXGE2TCMBXGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[p-bakker]

Got a pointer to a project that uses such a setup? Couldn't find any reference to something like that

[tonygermano]

Possibly a bot that changes who to nag (author or maintainers) based on the presence or absence of a tag on the PR?