-
Notifications
You must be signed in to change notification settings - Fork 150
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
Proposal - Cleanup the modules failing often #955
Comments
Isn't it the purpose of the "maintainers" field? |
Oh, yeah. My bad. Let me adjust the proposal to cover the second part only. |
If this is going to block releases, it may be worth collecting alternative contact information, since GitHub notifications can be overwhelming (and thus ignored or dealt with in delayed batches) by some folks. |
+1 to the suggestion. |
Adding Release-agenda to mention it in the next meeting so we can move it forward |
Since the CITGM has been red for years, maybe a better approach would be just starting from a clean slate, and gradually add modules back while strictly keeping it green. A red CI in the normally green CI is much more noticable, and I feel the approach of trying to remove modules until it's green had not been working well for a long time until this day... |
Ref #959 |
We discussed this in the WG meeting today. Suggestion is that someone opens a pull request documenting the procedure. Once the PR is accepted and merged, we can close this. |
When performing a release, we usually compare the citgm run against the previous CI. This, however, does hide modules that are failing often. Instead of comparing 100 failures with 101 failures and proceeding with the release, we should lower this number the much as we can, otherwise, the citgm will become meanless.
I think we should:
This should help the releasers a lot (plus reducing the citgm time).
cc: @nodejs/releasers
The text was updated successfully, but these errors were encountered: