[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Process for reviewing patches as someone without commit access
From: |
Vagrant Cascadian |
Subject: |
Re: Process for reviewing patches as someone without commit access |
Date: |
Thu, 07 Sep 2023 09:19:22 -0700 |
On 2023-09-06, Maxim Cournoyer wrote:
> Simon Tournier <zimon.toutoune@gmail.com> writes:
>> On Wed, 06 Sep 2023 at 16:55, Christopher Baines <mail@cbaines.net> wrote:
>>
>>> Once we know what tags to use, I can have the QA frontpage do something
>>> similar to the "Mark as moreinfo" links, so it's easy to just click a
>>> button then send the email to change the state of a issue.
>>
>> That’s cool!
>>
>> Well, using emacs-debbugs and then
>>
>> C-u M-x debbugs-gnu-usertags guix-patches RET
>>
>> the list of usertags is:
>>
>> guix-patches for-core-updates
>> guix-patches reviewed-looks-good
>>
>> And if instead of guix-patches we consider guix then it reads,
>>
>> guix build-system
>> guix cross-compilation
>> guix for-core-updates
>> guix looks-good
>> guix patch
>> guix plz-work
>> guix powerpc64le-linux
>> guix ready-to-review
>> guix reproducibility
>> guix reviewed
>> guix reviewed-looks-good
>> guix test-tag
>> guix v1.3.0
>>
>> However, I do not know how to list all the bugs for the package
>> guix-patches that matches the usertag reviewed-looks-good. Anyway!
>
> Clicking on an entry in the above list shows them; I'm sure we could
> define a procedure to directly show the bugs associated with a usertag,
> which would be useful.
>
>> I think that the usertag ’reviewed’ is a good idea. That would be a
>> very good start. Then if it helps, we could add other usertags as
>> reviewed-julia for patches that the Julia team can merge.
>
> +1 for the 'reviewed' usertag (using the 'guix' user).
>
>> Discussing about idea, would it be possible that the QA infrastructure
>> automatically send a message to Debbugs for tagging? For example, the
>> usertag ’qa-ok’ or whatever other meaningful name. :-)
>
> +1 for that as well, maybe 'qa-passed'.
Overall, I like this!
The only concern is that it is maintaining QA information in multiple
places, the QA service itself, and trying to mirror it to the bug
tracker...
QA might fail with a later patch iterations, so it should also then go
and remove the qa-passed tag? Should it remove the tag when QA is
currently in an unknown state?
live well,
vagrant
signature.asc
Description: PGP signature
Re: Process for reviewing patches as someone without commit access, Christopher Baines, 2023/09/27