On 05/12/17 23:53, Kevin Fenzi wrote: > On 12/05/2017 01:56 AM, Daniel Pocock wrote: >> 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. > This is a bit of an oddity as we don't control bugzilla, so I guess in > this case we should not be sending anything via FMN by default since we > cannot supress the bugzilla email. Yes, every Bugzilla I've ever used enables emails by default so unless somebody is going to disable that in Bugzilla, it should probably be disabled in FMN >> The emails from buildsys@xxxxxxxxxxxxxxxxx don't appear to come from >> FMN, here is a sample from the headers: > yep, this is known. There are plans to re-write that script, but no one > has stepped up to do it yet. > ...snip... It is always useful to have small tasks like tweaking that script for people to demonstrate their skills when applying for GSoC, is this tracked in Bugzilla somewhere already? >> That is a technical policy, I was thinking more about a high-level >> community-oriented policy on notifications / use of communications channels. > I don't know of any. > ...snip... Where would be the next step to start or propose a policy like that? >> >> 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? > it's only sending notifications based on fedmsg's it's gotten. > ...snip... >From an architecture perspective that is quite OK and a lot easier to maintain. Assuming it will continue to be like that, it means an iCalendar solution would have to be something parallel to FMN. >> 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? > It would need to be something else... FMN just sees a specific discrete > fedmsg and notifies the user about it. OK, so that eliminates the third option in that list but the other options are all possible. > >> 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. > I find the idea interesting and may look more at it over the holidays. > > I think it would be possible to build some kind of 'dashboard' setup, > and indeed the Fedora hubs effort seems like it kind of ties into this, > so perhaps thats where it would be useful to try and get more traction? > > Perhaps those more involved in that project could chime in on the > current state? It would be interesting to see if there are any similarities between that and the dashboard work Harsh already did in Debian. Regards, Daniel _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
