On 05/12/17 01:48, Kevin Fenzi wrote: > On 12/04/2017 01:07 AM, Daniel Pocock wrote: >> >> Hi, >> >> I've opened a bug report[1] about automatically generated emails from >> Fedora Fedmsg and other parts of Fedora infrastructure. >> >> Maybe there are other components of Fedora where bug reports like this >> should be opened but that isn't completely clear to me. >> >> I'm sending this email to the community to ask a few things: >> >> - to see if other people have useful information to add to the bug report > > I do, and have done so. :) > >> - to see if anybody can suggest other components to file bug reports >> against, or help do so > > Well, the idea of FMN was to try and put all the notifications in one > place, so likely if there are any other places they should be moved to FMN. That would mean filing bug reports against those other places When somebody writes a comment in Bugzilla, I am receiving an email from Bugzilla and another email from FMN: two emails for each comment. I haven't seen this type of behavior in any other project. The emails from buildsys@xxxxxxxxxxxxxxxxx don't appear to come from FMN, here is a sample from the headers: Received: from rawhide-composer.phx2.fedoraproject.org (localhost [127.0.0.1]) by rawhide-composer.phx2.fedoraproject.org (Postfix) with ESMTP id 892DC48065D for <resiprocate-owner@xxxxxxxxxxxxxxxxx>; Sun, 3 Dec 2017 14:24:49 +0000 (UTC) From: buildsys@xxxxxxxxxxxxxxxxx To: resiprocate-owner@xxxxxxxxxxxxxxxxx Cc: Subject: Broken dependencies: resiprocate Message-Id: <20171203142449.892DC48065D@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> Date: Sun, 3 Dec 2017 14:24:49 +0000 (UTC) There are also various other bug reports indicating that FMN's default behavior seems to be spammy. Even if these are not intentional, it suggests that opting people in to things by default is high risk: https://github.com/fedora-infra/fmn/issues/64 https://github.com/fedora-infra/fmn/issues/162 >> >> - to find out if there is existing policy on this issue, a search of the >> wiki didn't reveal anything obvious > > Well, the policy is that when you are sponsored into the packager group > you get the default set of packager rules. You can remove them, disable > all notifications, add your own or whatever as you like. I don't think > opting in is a good move here as new packagers likely are the people who > need those notices the most. > That is a technical policy, I was thinking more about a high-level community-oriented policy on notifications / use of communications channels. > I could definitely see the welcome to packager email note this and point > people to where they can adjust things. > >> - to get any general feedback about how the Fedora community feels about >> use of email addresses. >> >> Note that I'm not just writing this to complain about the issue, I've >> previously done work on tools to help people build dashboards of their >> issues and I've blogged about some of those, including how you can get >> Github issues in iCalendar[2], Nagios issues in iCalendar[3], Debian >> issues in iCalendar[4]. Bugzilla (used by Fedora, Mozilla and GNOME, >> for example) already has native iCalendar support. Harsh Daftary did >> work on aggregating[5] things from these sources in a dashboard as a >> GSoC project. Putting this all together, even using the Mozilla >> Calendar/Lightning plugin, you can easily merge issues from many places >> and see them in priority[2] order which is far more comfortable than >> being bombarded by emails and trying to work out which is most >> important, which is already fixed by somebody else, etc. > > Perhaps you would like to write a FMN backend for this model? :) > (we have email and irc now, but adding a ical one should be definitely > possible I think). > iCalendar doesn't involve sending notifications: it is about representing the state of things. Does FMN keep state or is it only a mechanism for relaying notifications? I can see the state of all Bugzilla issues assigned to me by going to the advanced search, entering my email address as the bug assignee, running the search and in the results list, clicking the "iCalendar" link. The link can be refreshed, bookmarked or used in other programs to get a current snapshot of open issues at any time, it looks like this: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&email1=daniel%40pocock.com.au&emailassigned_to1=1&emailtype1=substring&list_id=8185597&query_format=advanced&ctype=ics and here is yours, you can quickly try putting it in Mozilla Lightning or GNOME Evolution (tasks) and see how it looks, when you open and close things in Bugzilla they will automatically appear/disappear from this feed: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&email1=kevin%40scrye.com&emailassigned_to1=1&emailtype1=substring&list_id=8185597&query_format=advanced&ctype=ics >From the perspective of FMN architecture, I suspect that some decision would need to be made about which component(s) keep the state and how it is transformed. Examples: - if a build breaks, should the build system talk to Bugzilla's API directly, opening a bug and closing it again next time the build succeeds? - or should the state of the last build be directly available as an iCalendar feed and interested parties have to monitor both the Bugzilla iCalendar the iCalendar URL from the build system? Most tools like Mozilla Lightning can monitor multiple task-list URLs like that but it is tedious for every developer to set that up in their client. - or can FMN be extended to take state from multiple sources (both the build system and Bugzilla) and merge those things into a single iCalendar file, the same way that Planet runs from time to time and merges multiple RSS feeds into one list? - or should some other system be built for that purpose and FMN just relays notifications? > Everyone is different... some people like email, some people like irc, > some people like syncing taskwarrior to their tasks, some people like > nothing and only want to run queries when they have time. > My observation is that the people who "like" email are simply not aware of the other options. There is a perception that it is easy and/or the lowest common denominator. It is very easy for script developers to write a couple of lines of code to generate an email. Over time email's inefficiency is a huge cost to the Fedora project and any other organization doing things this way. Think about it like this: somebody goes away for a 6 week extended vacation and they come back to find 1000 automated email messages waiting, I worked in one company where that was the way things were done. The consequences: - the emails are sorted chronologically, not in priority order, so the user doesn't know which emails to look at first - they don't know which emails have been fixed by somebody else - they don't know which emails somebody else is already investigating - if 50 of those emails relate to a single problem or incident, it is not obvious which email represents the root cause of the problem The person coming back to that inbox might spend 1 day just checking the emails. Or maybe 2-3 hours each day during the week after their vacation, without really working on them, just trying to work out which issues were still open, which emails are duplicates, prioritizing them, etc. Even when people don't go on vacation, they are losing a bit of time every day on such filtering chores. Add it all up and it is a huge cost to organizations. As a large organization, Fedora "loses" more time this way than a small organization. In contrast, another company I worked in had a strict policy against emails, things couldn't be released into production unless they worked with the dashboard. Any developer, sysadmin or manager could look at the dashboard in the morning and quickly see the top 3 issues nobody was working on. >> >> - can anybody comment on other tools like this that put the developers >> in control rather than bombarding our inboxes with things? > > You can control things at https://apps.fedoraproject.org/notifications/ > What I was asking with that question is whether people are aware of other tools outside Fedora that could be used by the project or by individual developers. >> - would anybody like to help contribute to things like this in future, >> for example, mentoring another GSoC project on the dashboard concept? > > I'm no developer, but perhaps someone else would like to. You could ask > on the infrastructure list. > People don't need to be developers to be part of the mentoring teams. It is just as important to have people who can help set requirements, test the work and give feedback. Most of the better GSoC students already know how to code and just need guidance about what to build and how to get it from their IDE to infrastructure. Sometimes a student will have two mentors, one an expert on coding and the other is an expert on the functional requirements. Regards, Daniel _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
