| 1 |
Dnia 8 grudnia 2015 01:05:26 CET, Alec Warner <antarus@g.o> napisał(a): |
| 2 |
>On Sun, Dec 6, 2015 at 6:36 AM, Michał Górny <mgorny@g.o> wrote: |
| 3 |
> |
| 4 |
>> Hello, |
| 5 |
>> |
| 6 |
> |
| 7 |
>Hi! |
| 8 |
> |
| 9 |
> |
| 10 |
>> |
| 11 |
>> As you have seen multiple times, I'm running a minimalistic CI |
| 12 |
>service |
| 13 |
>> for Gentoo that checks the repository for major issues using |
| 14 |
>pkgcheck. |
| 15 |
>> So far it's automation is limited to sending a mail to dedicated |
| 16 |
>> gentoo-automated-testing@l.g.o mailing list on breakage |
| 17 |
>> changes. From there, I compare the results to recent git log and mail |
| 18 |
>> the developers at fault, pointing out the bad commit. |
| 19 |
>> |
| 20 |
>> A few developers have already subscribed to the mailing list to check |
| 21 |
>> if they haven't caused any new breakages and fix them quickly. For |
| 22 |
>> others, it's pretty much just me caring to check, which also means |
| 23 |
>that |
| 24 |
>> when I'm not around things are left broken. |
| 25 |
>> |
| 26 |
>> |
| 27 |
>So this sort of brings up a point of responsibility. |
| 28 |
> |
| 29 |
> |
| 30 |
> |
| 31 |
>> Automating the blaming process has been suggested multiple times |
| 32 |
>> already but I so far considered it not worth the effort. Mostly |
| 33 |
>because |
| 34 |
>> many of the issues are indirect, and trying to automatically figure |
| 35 |
>> them out from combination of the pkgcheck report and recent commits |
| 36 |
>> would be hard, and could cause false positives. For example, some of |
| 37 |
>> the depgraph breakages happen because of package.mask changes -- |
| 38 |
>> figuring that out automatically wouldn't be easy, and the script |
| 39 |
>could |
| 40 |
>> blame an irrelevant commit in the package. |
| 41 |
>> |
| 42 |
>> However, it was suggested recently that I could make it mail |
| 43 |
>> the maintainers of the affected packages. Even though most often it's |
| 44 |
>> not them who are at fault, it was suggested that they'd prefer to |
| 45 |
>know |
| 46 |
>> that their packages are broken. |
| 47 |
>> |
| 48 |
> |
| 49 |
>I think there are a few issues: |
| 50 |
> |
| 51 |
>1) Not everyone cares. I think you can either go for an opt-in approach |
| 52 |
>(hard..you need to keep state) or offer clear opt-out / filtering |
| 53 |
>instructions (link in the bottom of the email that points at the |
| 54 |
>opt-out |
| 55 |
>instructions on wiki.) Either decision will piss people off; I wouldn't |
| 56 |
>fret it as long as you pick one. |
| 57 |
|
| 58 |
Opt-out: reopen your developer bug and ask to be retired ;-). |
| 59 |
|
| 60 |
> |
| 61 |
>2) Unclear ownership of the problem. One guy makes a commit, 100 |
| 62 |
>packages |
| 63 |
>break. Who is responsible? Its really murky. This is really the |
| 64 |
>toughest |
| 65 |
>problem to me. |
| 66 |
|
| 67 |
So far I kept the commit author the only one responsible. However, this doesn't really work without CC-ing the maintainers of broken packages. |
| 68 |
|
| 69 |
Long story short, developer removes old version of X, breaking a dozen packages. I report this to him, he reverts the commit and... usually everything is left as-is waiting for another developer to do the same mistake. CC-ing other package maintainers could at least be a helpful reminder 'you require old version of X'. |
| 70 |
|
| 71 |
> |
| 72 |
>3) Problems are not stateless (e.g. many are transient as they are |
| 73 |
>fixed |
| 74 |
>later by developers.) Is the email I got 8 hours ago still relevant? |
| 75 |
>What |
| 76 |
>we normally see in items like this is a framework to manage |
| 77 |
>"incidents". So |
| 78 |
>what you might see is an incident App. The CI infrastructure detects a |
| 79 |
>problem and opens an incident. At incident open, you trigger a |
| 80 |
>notification |
| 81 |
>(said email). Typically incidents can be claimed (a human takes |
| 82 |
>ownership |
| 83 |
>and fixes the incident) or perhaps a future run of the automation |
| 84 |
>detects |
| 85 |
>that the incident is fixed and closes the incident. |
| 86 |
|
| 87 |
That's a good point I missed. Though otoh I already keep previous list of failures and commit id. It wouldn't be hard to add list of mails there. |
| 88 |
|
| 89 |
> |
| 90 |
>The problem of course with 3 is that you are very much re-inventing a |
| 91 |
>bunch |
| 92 |
>of functionality that is already in bugzilla; which leads to the |
| 93 |
>argument |
| 94 |
>of 'why not open bugs for breakages' ;) |
| 95 |
|
| 96 |
The infra was already against automated bug filling. That's why repository QA failures are reported with manual confirmation. But they're not the highest priority, so the delay caused by that is less problematic than for gentoo-ci. |
| 97 |
|
| 98 |
> |
| 99 |
>-A |
| 100 |
> |
| 101 |
> |
| 102 |
>> |
| 103 |
>> So what do you think? Would it be fine to mail the package |
| 104 |
>maintainers |
| 105 |
>> whenever their packages break? Would it be a problem if I just CC-ed |
| 106 |
>> all the maintainers on the gentoo-automated-testing mails? Please |
| 107 |
>note |
| 108 |
>> that the breakages are catched per-package, and the script wouldn't |
| 109 |
>be |
| 110 |
>> able to respect restrict="" or hand-written maintainer descriptions |
| 111 |
>;-). |
| 112 |
>> |
| 113 |
>> -- |
| 114 |
>> Best regards, |
| 115 |
>> Michał Górny |
| 116 |
>> <http://dev.gentoo.org/~mgorny/> |
| 117 |
>> |
| 118 |
|
| 119 |
-- |
| 120 |
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
Archives