-
-
Notifications
You must be signed in to change notification settings - Fork 32
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
Revise testing policy with labels #57
Conversation
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
Updated. |
- `tests: deferred`, where the tests are required by the testing policy | ||
but it is intended to add these tests in a subsequent PR. The label should | ||
be removed (for example from a closed PR) once subsequent tests have | ||
been merged. |
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.
How do we deal with situations where the PR author considers that the current test suite is sufficient?
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.
I think this would come under tests: present
.
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.
Is this fail to merge without one of these labels being set, going to display a relevant error?
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.
How would you want to do this. It would require the GHE hooks to look at the PRs in the merged commits which I do not think we want.
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.
I think this would come under tests: present.
It may also be "tests: exempted". For example a refactor is specifically exempted.
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.
I agree with @t8m re automatic checks, because of all the churn (and because github has a 5s time limit on pre-receive hooks, where those checks need to be placed)
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.
I think this is a good start for now.
labels must be applied: | ||
|
||
- `tests: present`, to be added where suitable tests are included in the same PR. | ||
- `hold: tests needed`, where the testing policy requires tests but they are not |
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.
Do some of these tests labels need explicit statements by each approver (I agree with the label X).
(Like we do for trivial)
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.
I think it should be up to the approver to disagree with the choice.
It's been 18 days, so I'm now raising the vote on this. cc @openssl/otc
|
Vote: [+1] |
Vote [0] |
Vote: [+1] |
Voting +1 |
Vote: [+1] |
Vote +1
…________________________________
From: Pauli ***@***.***>
Sent: Tuesday, November 8, 2022 7:21 AM
To: openssl/technical-policies ***@***.***>
Cc: Shane Lontis ***@***.***>; Comment ***@***.***>
Subject: [External] : Re: [openssl/technical-policies] Revise testing policy with labels (PR #57)
Vote: [+1]
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/openssl/technical-policies/pull/57*issuecomment-1306209082__;Iw!!ACWV5N9M2RV99hQ!JZEsOB6_fFLxbduj79hUgn6xvEQpeLd9CKR7TSI9NOcaTCsjeAerbHftF6dsRyVbN2KIiElZko0ybfPodKsHAqgFBQ$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AJUSG6SEU35J2GIH7GI6K63WHFXE7ANCNFSM6AAAAAARKI3IBU__;!!ACWV5N9M2RV99hQ!JZEsOB6_fFLxbduj79hUgn6xvEQpeLd9CKR7TSI9NOcaTCsjeAerbHftF6dsRyVbN2KIiElZko0ybfPodKtlnDjDLw$>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Vote: [+1] |
1 similar comment
Vote: [+1] |
(Side Note: @hlandau it would be nice if you could follow the current coloring practice for the labels, i.e., reuse the existing red color for the |
Agreed, this is my plan: red for the hold, something visually distinct for the other test labels. |
Since the outcome of the vote is now a foregone conclusion, this vote can now be closed.
|
1b5713e
to
95becf1
Compare
Vote: [+0] |
I've immediately realized that we could avoid some labeling pollution by not requiring the |
First draft. Let me know your thoughts. I've tried to avoid overengineering this for now.