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 build...@fedoraproject.org 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-ow...@fedoraproject.org>; Sun, 3 Dec 2017 14:24:49
+0000 (UTC)
From: build...@fedoraproject.org
To: resiprocate-ow...@fedoraproject.org
Cc:
Subject: Broken dependencies: resiprocate
Message-Id:
<20171203142449.892dc480...@rawhide-composer.phx2.fedoraproject.org>
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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
