[Intel-gfx] [QUERY] How many CI mails is too many?

Sagar Arun Kamble sagar.a.kamble at intel.com
Mon Nov 27 15:40:37 UTC 2017


I feel we generally tend to ignore the results mails for series that we are not actively involved on (although we might be
interested in series itself). Also if number of revisions some series can undergo is high, this tendency can grow.

How about the option of sending the results mails to only author and all committers.
Ideally, author should include at lease one committer and in that case we can possibly avoid mail to all committers.

Another option would be no results mails at all and enforce authors to ensure all green at https://patchwork.freedesktop.org/project/intel-gfx/series/?ordering=-last_updated

Thanks
Sagar

On 11/27/2017 8:24 PM, Arkadiusz Hiler wrote:
> Hey all,
>
> For some time already CI sends out 1-2 mails per series per (re)run, i.e. BAT
> results and "full IGT" results (if BAT has not failed).
>
> Recently we have added 32bit build check, and if that fails it sends out
> additional mail In-Reply-To the series.
>
> I am working on adding some static checks to the CI (spare and checkpatch at the
> moment, more may come in the future), which may generate even more commotion on
> the mailing list.
>
> How much of CI noise is too much and how you would like to have the results
> grouped?
>
> Couple of options to start the discussion:
>
>   1. Group all static checks (and the 32bit build?) into one mail:
>      - just one additional mail,
>      - may be hard to read in case of catastrophic failure,
>      - we can send it only when something actually fails.
>
>   2. Send out the results as a part of BAT results:
>      - even less noise than (1),
>      - BAT results already feel cluttered, this may decrease readability.
>
>   3. Have each check as a separate mail, but send it only if the check fails:
>      - noisy: may result in many mails, depending how many checks fail,
>      - easier to read and easier to follow on patchwork.
>
> Any opinions? Any other ideas?
>



More information about the Intel-gfx mailing list