Re: August/November update on qa.guix.gnu.org and related things

[Suhail <suhail@bayesians.ca>]

"Christopher Baines" <mail@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.