CI mail filtering (was Re: Manner in which kde-gtk-config development is conducted)

[Ahmad Samir]

On 21/03/2020 22:38, Ben Cooksley wrote:
> On Sun, Mar 22, 2020 at 3:08 AM David Edmundson
> <david at davidedmundson.co.uk> wrote:
>>
>> You're absolutely right that mistakes were made and have reason to be
>> frustrated.
>>
>> kde-gtk-config is now maintained by new developers.
>> Plasma has a new influx of new people which is good to see and
>> something we need to foster carefully.
>>
>> Overall these new devs are doing a super job and we want to encourage them.
>>
>> Ultimately there are two parties at fault:
>>   - brand new developers who didn't know the rules. KDE has a lot of
>> rules and they're certainly not all written down in a consistent
>> location.
>>
>>   - the more "senior" Plasma people (me, Kai, Aleix, etc) who do know
>> the rules, not paying due attention to something that's now under
>> Plasma's umbrella
>>
>>> which means that the repository is no longer eligible to form
>>> part of a KDE release module and should be moved to Playground
>>
>> I think this is an overreaction that punishes the wrong people. Users.
> 
> The reaction is intended to force the hand of Plasma as a collective
> group to pay attention to the notifications from the CI system - which
> it delivers to the plasma-devel mailing list.
> I know that some people do pay attention to these, but it is evident
> that others do not or have active filtering in place to ensure they
> don't see them.
> 

The traffic of CI mail can be a bit daunting, and failure mails could simply go unnoticed, so I 
suggest some "reverse filtering", i.e. I've just created a filter in Thunderbird:
From: CI System <noreply at kde.org>
X-Jenkins-Results: FAILURE

(in TBird you can create customise message headers and add a new one).

I don't care as much about success reports, (and I haven't yet dug in the mails to create a filter 
to cull mails about successful builds that have some unit tests failure).

I suggest that if you commit regulary to a KDE repo to make a habit of checking the results of the 
unit tests on the CI every now and then (jenkins has a nice web interface). Unit tests could pass 
locally and fail on the CI for some reason.

[...]


My, beginner-dev, 2 p's,

-- 
Ahmad Samir