Re: [QUERY] How many CI mails is too many?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 27, 2017 at 02:54:02PM +0000, 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.

I'd vote for number 3. And let's see how noisy that gets and maybe
that end up in a good thing because we will start seeing what causes noise
and possibly work to avoid those.

> 
> Any opinions? Any other ideas?
> 
> -- 
> Cheers,
> Arek
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux