On 24/11/20 4:40 AM, Neil C Smith wrote:
FWIW I remain in favour of running the whole thing from a git repo
with GH issues and PRs used to manage verification, like everything
else. However, I'm no longer in a position to work on that.
If the current process is 1.5 months (half a release!) behind, it's
not working.
Looking at updating the process as two parts
1. Agreeing (VOTE?) on a new verification policy
2. Implementing infrastructure as needed
If a VOTE is negative, then done.
For a new policy that has some automatic verification, then that could
be done immediately without any infrastructure change and would reduce
the current burden (if all the backlog is new stuff, then it actually
doesn't change anything).
Setting up a place (new repo, or whatever, for reporting verification
issues) seems like could be done easily. And further implementation as
possible and/or resources available.
I have no idea how (behind the scenes, responsible party...) a VOTE is
called. I've always thought of Jiří Kovalský as Mr. Plugin 😎
At the same time, I have some concerns about
non-committers having verification permissions.
+1
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail:dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
