"Christopher Baines" <m...@cbaines.net> writes: > There isn't much documentation for QA
Understood. Is the preferred place to ask questions regd the QA service this mailing list? > I think it's fair to say that these shouldn't be styled the same as > failed builds, so I've changed the styling now. The neutral blue works better; thank you. On a related note, the specific build status on data.qa.guix.gnu.org for the "now blue" entries is "Scheduled". Why does that get presented as "Unknown" in QA? IMO, either "Scheduled" or "Pending" (in case it's important to maintain a distinction from the build status of individual jobs as on data.qa.guix.gnu.org) would be clearer than "Unknown". > I've also added a new issue status for when QA is waiting on builds to > happen to provide more information. This being "Investigate"? Out of curiosity, and in a similar vein as above, why not simply "Scheduled" or "Pending"? Or is it that it has had "Scheduled" build jobs for far too long and thus requires someone else with more privileged access (than myself) to investigate the cause? I.e., Investigate is a verb and thus makes me wonder what the object is (what needs to be investigated) and who the subject is (by whom)? Shouldn't the QA issue status be an adjective instead? > So yeah, QA isn't currently pointing out anything for you to do on > this issue. Okay, thank you for the clarification. > There's also some content in the manual that might be useful when > reviewing patches: > > https://guix.gnu.org/en/manual/devel/en/html_node/Packaging-Guidelines.html > https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html Perhaps linking to these from the "Mark patches as reviewed" section on QA would be helpful? > But there's no pre-requisites to reviewing Guix patches, so the best > way to learn is to start looking to review things. I imagine some of the "common things to check" will get automated in the near future (e.g. whether or not the changes are adding to the lint warnings), whereas some others will stay manual (e.g. are things "well written"). Personally, for such subjective measures (i.e., the latter) I find having some examples of "what good looks like" readily available quite helpful. In case the intent is to make it easier for newcomers to the project (i.e., those who've not yet internalized this knowledge) to contribute, providing such prototypical examples by linking to commits, descriptions etc in the existing source tree would help. -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties. This email may contain information that is privileged, confidential and/or exempt from disclosure. No waiver whatsoever is intended by sending this e-mail which is intended only for the named recipient(s). Unauthorized use, dissemination or copying is prohibited. If you receive this email in error, please notify the sender and destroy all copies of this email.
