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 |
> |