On Mon, Dec 7, 2015 at 7:05 PM, Alec Warner <[email protected]> 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
