#700 Fix the report SPAM in test list
Closed: Fixed 2 years ago by kparal. Opened 2 years ago by kparal.

This is what I see when I try to search for some recent conversation in test list:

report_spam.png

99% of emails is some kind of report. We're killing the readability of our mailing list. Nothing can be found in the archives, because they're flooded with report spam. We're discouraging testers from joining. Who would want to be subscribed to such a miserable list and be bombarded with automatic reports all day?

I myself have created an email filter a long time ago that basically deletes anything called "report". I suppose many people did that as well. I don't expect that more than a couple people actually read that stuff occasionally, and no one reads it all, or even one tenth of it. So why are we killing our community and our sanity, where is the cost-benefit rationale here?

I propose we create a separate list called test-reports. All reports go there. We announce it, anyone interested can subscribe. The default Reply-To is set to the test list, so people can easily highlight and discuss something interesting they noticed in there. We update our documentation to also link to test-reports, so that newcomers find it.

I'd also support having a consolidated report that gets sent to the test list. But at most one per day. So if somebody invests their time into picking interesting parts of various reports and creating a consolidated one, sure, let's accept it in test list. But that can wait for some glorious future. At this very moment, all reports would go to test-reports, and test list would receive zero reports.


Metadata Update from @kparal:
- Issue set to the milestone: Fedora 37 (was: Fedora 36)

2 years ago

Now that F36 is out, I'd like to focus on this. Can I please get some feedback here?

I think you're kind of overplaying the problem here, but I don't mind the idea.

Consolidated reports are not easy, because these are different reports from different systems that run as part of, or in response to, compose/test processes; there isn't some long-lived Unified Report Generation Daemon spitting them out. We'd need to write a whole extra thing to consolidate the existing reports, and that doesn't seem worth the effort.

I think you're kind of overplaying the problem here, but I don't mind the idea.

Shrug. I get extremely angry (you might have noticed :-)) every time I have to deal with that report spam in some way, e.g. through archives.

Consolidated reports are not easy, because these are different reports from different systems that run as part of, or in response to, compose/test processes; there isn't some long-lived Unified Report Generation Daemon spitting them out. We'd need to write a whole extra thing to consolidate the existing reports, and that doesn't seem worth the effort.

Yes, I know. I agree it's probably not worth the effort at the moment. I don't think that should be an excuse for flooding our list, though. That's why I proposed a separate list.

If there's no objection in the next few days, I'll request a new mailing list test-reports next week, and then I'll try to figure out where the existing reports come from and switch them into the new mailing list (if you have any pointers, that would be very welcome).

Sure, no objections.

You can change where the 'compose check reports' go in https://pagure.io/fedora-infra/ansible/blob/main/f/inventory/group_vars/checkcompose . Or, since I have commit privileges, I can. :D Just ping me when the list exists and I can change it.

The 'compose reports' come from this script. To change where they go, send a PR to change the TOMAIL value.

I'm not sure what generated the "updates-testing report" mails, but there aren't so many of those at least.

Oh, for the 'updates-testing report' mails, looks like this fedora_test_announce_list value is what would need changing. Those mails are generated by Bodhi.

From https://pagure.io/fedora-infrastructure/issue/10819#comment-807206 :

Thanks. I wonder if we should do this for devel too?

I wasn't even aware there are some reports in the devel list. Now I see that there are compose check reports (example). Is there something else?

My focus was just the test list. If you think we should also move those reports out of the devel list, I guess we can. But what exactly would you want to do? Tell devel list users to subscribe to test-reports list if interested? Or create devel-reports? (I don't think that's a good idea, honestly). Or change test-reports name into something more generic, like distro-reports, or just reports? Even currently our test list receives some reports which are not really QA-related, like these releng's compose reports, so test-reports is not completely accurate (on the other hand, I don't think it matters that much).

Tell me what you think. I'd personally keep test-reports list and move all the reports from test list into it, as the first step. Then, possibly, if devel users want, remove also the reports from devel list and let interested people subscribe to test-reports. But that's optional, in the future, because devel list is not as flooded as ours with those reports.

Well, @kevin had the same idea. How it looks rather depends on where you're standing. The naming is (like usual) the hardest part. Calling it just reports@ sort of oversells it a bit, I think - then you'd tend to think all Fedora-related reports would be found there, and we'd probably be missing some. But I didn't have any other great ideas. Kevin?

The compose reports and compose check reports are both sent to test@ and devel@ , but the updates-testing reports are sent only to test@ . I don't know of any frequently-generated reports that are only sent to devel@ - there's things like the FTBFS removal warning mails, but I think those are important and infrequent enough to stay on the main list.

I'm fine with just using 'test-reports'.

The things that currently go to the test list, also go to the devel list. I'd be ok with moving most of those to test-reports too, but I still think the daily rawhide report is useful on devel (people reply to it with questions/comments/answers).

Commit f91294e5 relates to this ticket

Moar PRs!
https://pagure.io/pungi-fedora/pull-request/1110
https://pagure.io/pungi-fedora/pull-request/1111
https://pagure.io/pungi-fedora/pull-request/1112

I'll wait over the weekend, if test-reports populates correctly, and then announce the change on Monday. Should I use both test-announce and devel-announce for it? Thoughts?

I'd say yes, announce in both places please. :)

Currently large emails are being held and I don't seem to be able to fix it:
https://pagure.io/fedora-infrastructure/issue/10827

Announced in test-announce and devel-announce.

I also added a link onto our QA homepage:
https://fedoraproject.org/wiki/QA#Mailing_lists

I think we can close this. Thanks everyone involved.

Metadata Update from @kparal:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Log in to comment on this ticket.

Metadata
Attachments 1
Attached 2 years ago View Comment
Related Pull Requests
  • #1153 Merged 2 years ago
  • #1112 Merged 2 years ago
  • #1111 Merged 2 years ago
  • #1109 Merged 2 years ago