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

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

 



On Tue, Nov 28, 2017 at 01:16:50PM +0200, Arkadiusz Hiler wrote:
> On Mon, Nov 27, 2017 at 09:10:37PM +0530, Sagar Arun Kamble wrote:
> > 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.
> 
> It is true that I don't care that much about results tied to series I am
> not interested in, but I don't find this too distracting. They are
> nested nicely in the thread and are also very easy to distinguish
> visually.
> 
> > 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.

I had the same idea but then I thought that sometimes if I want to apply some series of patches
I would like to know what is a status of that patch (fail or not) so maybe sending that to
author only can be not really good idea.

-Ewelina
> > 
> > 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
> 
> In my mind the CI system should complement mailing list, not change it
> or require unnecessary, external interactions. By sending the result to
> intel-gfx we get the gist of the results here, with the direct links to
> the patchwork and intel-gfx-ci grids provided (so no need to hunt for
> those).
> 
> The results also stores nicely in the online mailing list archives if we
> send it to the intel-gfx@fdo.
> 
> Searchability and easy categorization is an added bonus if you subscribe
> to dozen or so mailing lists.
> 
> Cheers,
> Arek
> 
> > 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?
> _______________________________________________
> 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