From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E578D1384B4 for ; Tue, 8 Dec 2015 00:27:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A4FEB21C075; Tue, 8 Dec 2015 00:27:32 +0000 (UTC) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C33A821C015 for ; Tue, 8 Dec 2015 00:27:31 +0000 (UTC) Received: by qkdb5 with SMTP id b5so6705518qkd.0 for ; Mon, 07 Dec 2015 16:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=HI2O2wXp/u3KHOwgcxSflB89OMsnMCw4sshJct+P84A=; b=J92L9arUIWvB2yIlmE9qsnRMW9r4Id0cMqV3AzvTRGn/Avk/mgCr3vudnOzvJPlcLL tahdYXLUEvQUbmkNBwJ/AgrYKHhlJVnF61qP5vvZ0IvcZXSdkr42NjLXHrAwTx4nPP76 0mlbCO4u4o0xXLftJClSjn0w9uHrf9/R3gNBmtEUcgsz8uARq3vBZSrphEgaPgbzc7Ch cGa3X9s0gCkP1xi+ramO/ooQPFa+yecT7OOp32Dpa6KhppVtoWLOK+tiPemLQ2DGPFyn XUOy5q6XtdlOnUos8BHdWSUdbjNk59ZRn5B23w+9AsEWEylWbPZ/qIV5R9a0SBcpwchG lOuA== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.129.39.17 with SMTP id n17mr410488ywn.36.1449534450917; Mon, 07 Dec 2015 16:27:30 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.129.89.7 with HTTP; Mon, 7 Dec 2015 16:27:30 -0800 (PST) In-Reply-To: References: <20151206153611.2a132d2c.mgorny@gentoo.org> Date: Mon, 7 Dec 2015 19:27:30 -0500 X-Google-Sender-Auth: 6yMzPyydk1vc0LbptKVhvWyCyJc Message-ID: Subject: Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 99bbc480-e926-4f15-aa0d-4a05a6896a95 X-Archives-Hash: f13fbda16a11c829476e2ab9c1bef2cf On Mon, Dec 7, 2015 at 7:05 PM, Alec Warner 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