public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alec Warner <antarus@gentoo.org>
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages
Date: Mon, 7 Dec 2015 16:05:26 -0800	[thread overview]
Message-ID: <CAAr7Pr-7te6HXa5OAL0WdOS-Mu8Gt7qONhY-n05HbiPeXGO+7A@mail.gmail.com> (raw)
In-Reply-To: <20151206153611.2a132d2c.mgorny@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 3417 bytes --]

On Sun, Dec 6, 2015 at 6:36 AM, Michał Górny <mgorny@gentoo.org> wrote:

> Hello,
>

Hi!


>
> As you have seen multiple times, I'm running a minimalistic CI service
> for Gentoo that checks the repository for major issues using pkgcheck.
> So far it's automation is limited to sending a mail to dedicated
> gentoo-automated-testing@lists.gentoo.org mailing list on breakage
> changes. From there, I compare the results to recent git log and mail
> the developers at fault, pointing out the bad commit.
>
> A few developers have already subscribed to the mailing list to check
> if they haven't caused any new breakages and fix them quickly. For
> others, it's pretty much just me caring to check, which also means that
> when I'm not around things are left broken.
>
>
So this sort of brings up a point of responsibility.



> Automating the blaming process has been suggested multiple times
> already but I so far considered it not worth the effort. Mostly because
> many of the issues are indirect, and trying to automatically figure
> them out from combination of the pkgcheck report and recent commits
> would be hard, and could cause false positives. For example, some of
> the depgraph breakages happen because of package.mask changes --
> figuring that out automatically wouldn't be easy, and the script could
> blame an irrelevant commit in the package.
>
> However, it was suggested recently that I could make it mail
> the maintainers of the affected packages. Even though most often it's
> not them who are at fault, it was suggested that they'd prefer to know
> that their packages are broken.
>

I think there are a few issues:

1) Not everyone cares. I think you can either go for an opt-in approach
(hard..you need to keep state) or offer clear opt-out / filtering
instructions (link in the bottom of the email that points at the opt-out
instructions on wiki.) Either decision will piss people off; I wouldn't
fret it as long as you pick one.

2) Unclear ownership of the problem. One guy makes a commit, 100 packages
break. Who is responsible? Its really murky. This is really the toughest
problem to me.

3) Problems are not stateless (e.g. many are transient as they are fixed
later by developers.) Is the email I got 8 hours ago still relevant? What
we normally see in items like this is a framework to manage "incidents". So
what you might see is an incident App. The CI infrastructure detects a
problem and opens an incident. At incident open, you trigger a notification
(said email). Typically incidents can be claimed (a human takes ownership
and fixes the incident) or perhaps a future run of the automation detects
that the incident is fixed and closes the incident.

The problem of course with 3 is that you are very much re-inventing a bunch
of functionality that is already in bugzilla; which leads to the argument
of 'why not open bugs for breakages' ;)

-A


>
> So what do you think? Would it be fine to mail the package maintainers
> whenever their packages break? Would it be a problem if I just CC-ed
> all the maintainers on the gentoo-automated-testing mails? Please note
> that the breakages are catched per-package, and the script wouldn't be
> able to respect restrict="" or hand-written maintainer descriptions ;-).
>
> --
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>
>

[-- Attachment #2: Type: text/html, Size: 4595 bytes --]

  parent reply	other threads:[~2015-12-08  0:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-06 14:36 [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages Michał Górny
2015-12-06 14:54 ` Dirkjan Ochtman
2015-12-06 15:31 ` Michael Orlitzky
2015-12-06 16:00   ` Michał Górny
2015-12-06 16:09     ` Michael Orlitzky
2015-12-06 16:49       ` Michał Górny
2015-12-06 17:25         ` Michael Orlitzky
2015-12-06 17:49         ` Andreas K. Huettel
2015-12-08  7:01           ` Michał Górny
2015-12-06 16:52       ` Rich Freeman
2015-12-06 17:26         ` Ian Stakenvicius
2015-12-06 18:58           ` Rich Freeman
2015-12-08  0:05 ` Alec Warner [this message]
2015-12-08  0:27   ` Rich Freeman
2015-12-08  2:19     ` Anthony G. Basile
2015-12-08  3:21       ` Rich Freeman
2015-12-08  6:59   ` Michał Górny
2015-12-08 19:11 ` Daniel Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAr7Pr-7te6HXa5OAL0WdOS-Mu8Gt7qONhY-n05HbiPeXGO+7A@mail.gmail.com \
    --to=antarus@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox