Re: Process for reviewing patches as someone without commit access

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 2350 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]