Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages

[Rich Freeman]

On Mon, Dec 7, 2015 at 7:05 PM, Alec Warner <antarus@g.o> wrote:
> 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.

I'd offer another option - just send them email and let them deal with
it.  That will also tick people off, but again I wouldn't fret it.  By
all means stick a header in the mail or something to make filtering
easy.  It is far more sensible for users to filter emails than to
build a fancy filtering system into every application that might send
mail.

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

It isn't murky at all.  Nobody should ever commit something that
simply breaks something else.  Sometimes it is unforseen, and that
might be ok if it is rare, but the committer can still go and revert
their commit and sort things out.

If you want to make a commit that will break 100 packages you have
many valid options available to you.

1.  You could go fix those 100 packages yourself so that they never
break, ideally posting notice somewhere that you're going to do it.
2.  You could create a blocker and bugs against those 100 packages
asking their maintainers to fix it ahead of time, with a deadline.
3.  After doing #2 if some packages still aren't fixed then mask them,
and make your commit.

If you do any of the above you'll get zero emails from the CI system,
as you aren't breaking the tree.  Of course #3 is undesirable since
you're making a smaller unbroken tree, but as long as you give fair
warning it is acceptable.

Breaking the tree is just never correct.  Sometimes it is hard to
catch and we need to bear with things since we're only human.  But, if
the CI system sends out an email, something HAS gone wrong (either
with the tree or the CI system).

>
> 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' ;)

I guess you can do that, but do you propose CCing the bug to everybody
who made a commit in the time range?  An email is definitely more
lightweight.  I am also concerned that those bugs will just tend to
stay open if people avoid ownership of the issue.  Who do you assign
the bug to (it isn't fair to make the package maintainer of the
affected package clean up somebody else's failures)?

I don't think this is a bad idea, but if email alerts are something
that will happen and bugs are something that won't happen, then I'd
prefer the email to nothing.

This is really a fairly lighthanded solution to the problem.

-- 
Rich