Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: Gentoo Dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages
Date: Tue, 08 Dec 2015 00:05:36
Message-Id: CAAr7Pr-7te6HXa5OAL0WdOS-Mu8Gt7qONhY-n05HbiPeXGO+7A@mail.gmail.com
In Reply to: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages by "Michał Górny"
1 On Sun, Dec 6, 2015 at 6:36 AM, Michał Górny <mgorny@g.o> wrote:
2
3 > Hello,
4 >
5
6 Hi!
7
8
9 >
10 > As you have seen multiple times, I'm running a minimalistic CI service
11 > for Gentoo that checks the repository for major issues using pkgcheck.
12 > So far it's automation is limited to sending a mail to dedicated
13 > gentoo-automated-testing@l.g.o mailing list on breakage
14 > changes. From there, I compare the results to recent git log and mail
15 > the developers at fault, pointing out the bad commit.
16 >
17 > A few developers have already subscribed to the mailing list to check
18 > if they haven't caused any new breakages and fix them quickly. For
19 > others, it's pretty much just me caring to check, which also means that
20 > when I'm not around things are left broken.
21 >
22 >
23 So this sort of brings up a point of responsibility.
24
25
26
27 > Automating the blaming process has been suggested multiple times
28 > already but I so far considered it not worth the effort. Mostly because
29 > many of the issues are indirect, and trying to automatically figure
30 > them out from combination of the pkgcheck report and recent commits
31 > would be hard, and could cause false positives. For example, some of
32 > the depgraph breakages happen because of package.mask changes --
33 > figuring that out automatically wouldn't be easy, and the script could
34 > blame an irrelevant commit in the package.
35 >
36 > However, it was suggested recently that I could make it mail
37 > the maintainers of the affected packages. Even though most often it's
38 > not them who are at fault, it was suggested that they'd prefer to know
39 > that their packages are broken.
40 >
41
42 I think there are a few issues:
43
44 1) Not everyone cares. I think you can either go for an opt-in approach
45 (hard..you need to keep state) or offer clear opt-out / filtering
46 instructions (link in the bottom of the email that points at the opt-out
47 instructions on wiki.) Either decision will piss people off; I wouldn't
48 fret it as long as you pick one.
49
50 2) Unclear ownership of the problem. One guy makes a commit, 100 packages
51 break. Who is responsible? Its really murky. This is really the toughest
52 problem to me.
53
54 3) Problems are not stateless (e.g. many are transient as they are fixed
55 later by developers.) Is the email I got 8 hours ago still relevant? What
56 we normally see in items like this is a framework to manage "incidents". So
57 what you might see is an incident App. The CI infrastructure detects a
58 problem and opens an incident. At incident open, you trigger a notification
59 (said email). Typically incidents can be claimed (a human takes ownership
60 and fixes the incident) or perhaps a future run of the automation detects
61 that the incident is fixed and closes the incident.
62
63 The problem of course with 3 is that you are very much re-inventing a bunch
64 of functionality that is already in bugzilla; which leads to the argument
65 of 'why not open bugs for breakages' ;)
66
67 -A
68
69
70 >
71 > So what do you think? Would it be fine to mail the package maintainers
72 > whenever their packages break? Would it be a problem if I just CC-ed
73 > all the maintainers on the gentoo-automated-testing mails? Please note
74 > that the breakages are catched per-package, and the script wouldn't be
75 > able to respect restrict="" or hand-written maintainer descriptions ;-).
76 >
77 > --
78 > Best regards,
79 > Michał Górny
80 > <http://dev.gentoo.org/~mgorny/>
81 >

Replies