-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vote on primordials in error path #1158
Conversation
@aduh95 Is there a public source code repository for the tool? It seems to be https://github.com/stduhpf/caritat but with some additional files. Maybe there's a tag/branch/fork I should be looking at? I did the |
Yes, it is https://github.com/stduhpf/caritat. |
Awesome, thanks. |
This comment was marked as off-topic.
This comment was marked as off-topic.
this is very very cool. Will dig more into implementation in a bit |
This comment was marked as off-topic.
This comment was marked as off-topic.
@aduh95 its not immediately obvious if we put higher scores for options we want my guess is that if I wanted to rank them from highest preference to lowest I could use 0-5 for the scores where 5 is the one I prefer the most? Can you confirm that is correct? |
@mhdawson that would works, absolutely. As long you put integers, you can use whichever scale that's more convenient for you (negative numbers also works btw): the largest score for the option(s) you prefer the most (5 in your example), the lowest score for the option(s) you prefer the less (0 in your example). |
@aduh95 thanks |
@nodejs/tsc Reminder that there's an ongoing vote on this PR, you are invited to participate; see the OP for instructions, don't hesitate to ask questions if you have any. |
@jasnell you mentioned on the issue you don't have a preference but there's one option you don't like. FWIW you can cast a vote that set all the options to |
Running into an EACCES when I'm trying to vote using |
I used the web ui to generate the encrypted ballot this time and after pushing I realize that it doesn't include the author info (reported in nodejs/caritat#5). Adding it manually. |
I am confused by the winning option. Does it explicitly support primordials? In other words, could this option be rephrased as |
To my understanding, it means - if someone volunteers to add primordials to error paths, we are likely to accept it if and only if there are no significant perf regressions. |
And the reciprocal would be – if someone opens a PR to remove primordials from error paths, it would be rejected, unless said primordials was causing a measurable perf regression. |
Does that mean writing benchmarks for error paths? |
Given that this vote has been completed, should this be moved out of draft mode and landed? |
The next step would be for me (or anyone that wants to beat me to it) to decrypt all the ballots, then I think it can be merged. Maybe we should also create a .json file similar to 2021-09-29-0.json so participation in this vote can be counted by the automation. |
I don't think there is any other way to make sure that the performance is not degraded. So IIUC, PRs like nodejs/node#41702 that attempt to add primordials to an error path would be blocked because we still don't have benchmarks testing the error path. |
I’m confused; what about code not in the error path? |
That's... interesting.
That was out of scope for this vote... I believe the intention is for more votes to follow. |
Interesting indeed. I thought that we were voting on the error paths because performance regressions that only happen there are not problematic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
For me I found it a bit difficult to be voting about the error path without having discussed if we should use for the main paths. As such I voted more conservatively than I might otherwise have. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I agree that we have not been concerned about the error cases performance a lot and as such it's probably fine. I just wonder why we added that option to our vote if we do not plan to actually handle it different from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested this with the tooling and it worked great. Thanks.
I've found the subject of voting in TSC comes quite often, and we often have recurrent discussions on what tool to use. I've decided to take upon me the creation of a tool to help us vote using CLI and GitHub UI. It might end up being a terrible idea, or a genius one, but at least we would have try. If it's successful, we can talk about officially adopt this tool for Node.js related votes.
The vote options were presented in #1104 (comment).
Use one of the following methods to case a vote (or abstain):
Vote using
npx
+gh
(requires Node.js 16+, and git)Requires
gh
(GitHub CLI tool) to be installed, and logged in to your GitHub account.If you want to abstain, you can use the
--abstain
flag (it will create a ballot with all the scores set to 0):Vote using
npx
(requires Node.js 16+, and git)Vote using
sh
(requires git, and OpenSSL CLI)Caution: LibreSSL CLI is not compatible, please use OpenSSL 1.1.1+.
Vote using PowerShell (requires git, and OpenSSL CLI)
Caution: LibreSSL CLI is not compatible, please use OpenSSL 1.1.1+.
Vote using the web
<your-github-handle>.json
for the file name.vote-primordials-error-path
branch.To abstain, set all scores to
0
before encrypting the ballot.This will encrypt a file containing your preferences, file that will be decrypted when doing the counting in two weeks or so.
The counting will be done using the Condorcet method.
Refs: #1104 (comment)
Bugs should be sent to: https://github.com/stduhpf/caritat