Suhail <suh...@bayesians.ca> writes: > "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?
Yep. >> 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 guess the result of the builds is unknown when they're scheduled. >> 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? Yeah, this is just me copying and pasting the code for the badge. I've changed the text to pending now. That's not as specific as "QA is waiting on the results of builds" but at least it hints at that. >> 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? Yes, although I think the documentation maybe needs looking at a bit to make it a bit more useful for patch review. >> 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. Yes, and while I think working on the docs is important, maybe QA can link and show various examples.
signature.asc
Description: PGP signature
