This is what I see when I try to search for some recent conversation in test list:
<img alt="report_spam.png" src="/fedora-qa/issue/raw/files/4584d1bf0f7b9e50875074fc9650e61866d7ffa3f52d2931d27a3d8178f133b0-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)
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.
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.
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.
TOMAIL
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.
Requested the new mailing list: https://pagure.io/fedora-infrastructure/issue/10819
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?
reports@
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).
test-reports list should be configured now. Here are PRs to redirect the reports: https://pagure.io/fedora-infra/ansible/pull-request/1153 https://pagure.io/pungi-fedora/pull-request/1109
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)
Login to comment on this ticket.