Hello, here are the minutes of today's heroes meeting: status reports: - Per mostly working on tickets - countdown.o.o ported to python 3 by cboltz - elections.o.o migrated to 15.4 - created some merge requests in Salt - discussion about all the additional domains belonging to openSUSE (opensuse.*) - decision: redirect most requests to www.o.o (instead of historically download.o.o) - gitlab runners are currently horribly slow: needs testing of the whole setup/workflow chain, which might not be quickly to solve. - bind in 15.4 no longer does chroot, which broke some things including query log rotation (and filled some disks) - upgrade of galera cluster went surprisingly very smooth. No data loss and quick DB upgrades (new DB version) - mailman3: - held messages in the queues should be deleted automatically for *-auto lists, because: more or less nobody cares anyway. - for human lists, the story is a bit more complicated - but over all, having more than 100 held messages in one list, it's not realistic to asume that a human will clean up the list of held messages manually -> configure *-auto messages to discard messages right away (can be changed for debugging at any time) -> implement an automatism that will delete all but the last 100 held messages in a list. This should leave a chance for human moderators to look at least for the most common held messages. - work on discourse is progressing: the import of old forum messages is - honestly - a nightmare because of the changed locale settings inside the DB. Idea: only migrate content starting 2011. - /blog.php and /content.php articles won't be migrated Machine upgrades - most machines are already migrated to Leap 15.4, and some to Tumbleweed (see https://progress.opensuse.org/issues/113285 for details) - wiki update worked for the english wiki, but produced funny errors on the other languages. Needs time to analyze and fix the problems Nextcloud - ask on the project mailing list about feedback / needs - if feedback is positive, provide a PoC for testing - including some of the public plugins Google MX - it's still kind of a game of luck if Emails from *@opensuse.org get delivered to Google accounts. Other mail providers seem to be either more relaxed or not so evil (depending on your view). Seems like we can not do much about this (other than asking people to switch to a collaborative Mail provider). HA setup for static / "rendered" content: - really static content (like static.o.o, shop.o.o) already gets served by multiple machines - we'll also do this for "rendered" content like jekyll-generated pages (news.o.o, get.o.o etc.) - it will be generated on one machine, and then rsync'd to multiple webservers Regards, Christian Boltz -- Und wer auf NTFS Verzeichnisse von Linux aus schreibend zugreifen will, der ist es ebenfalls selber Schuld, wenn er damit mehr Schaden anrichtet [...] und findet den schuldigen bereits am frühen morgen in seinem Badezimmer (spätestens). Mich grinst der Typ auch so manchen morgen blöde an. ;-) [Helmut Scholl in suse-linux]
Christian Boltz wrote:
Hello,
here are the minutes of today's heroes meeting:
Christian, as always, thanks!
status reports: - Per mostly working on tickets
Yeah. 154 entries to 71 tickets, but low hanging fruit I'm afraid.
bind in 15.4 no longer does chroot, which broke some things including query log rotation (and filled some disks)
I admit, I was very annoyed by that one. (grumpy old grey beard).
- mailman3: - held messages in the queues should be deleted automatically for *-auto lists, because: more or less nobody cares anyway.
Hmm, no, I don't agree - I'm sorry if I failed to make my point clear. We have to consider 'admin-auto' a key destination for error messages. Not everyone cares as much about their "baby" as others, but if we just throw away the cries, no one will ever know.
- for human lists, the story is a bit more complicated - but over all, having more than 100 held messages in one list, it's not realistic to asume that a human will clean up the list of held messages manually -> configure *-auto messages to discard messages right away (can be changed for debugging at any time)
I am hesitant about that. "send error message" -> "discard" - that is not a sound policy.
-> implement an automatism that will delete all but the last 100 held messages in a list. This should leave a chance for human moderators to look at least for the most common held messages.
Unfortunately, we don't have enough human moderators. Instead we (I) should finish that ticket about "rejecting mails from non-subscribers", and figure out what to do with the last few.
Nextcloud - ask on the project mailing list about feedback / needs - if feedback is positive, provide a PoC for testing - including some of the public plugins
I guess I missed that item - as for POC, I have a calendar instance still running, but on my private setup. Overall, I find it a good idea to offer more services to our members, but we have to keep in mind how much they are used. -- Per Jessen, Zürich (18.8°C) Member, openSUSE Heroes
Hello, Am Donnerstag, 7. Juli 2022, 23:05:48 CEST schrieb Per Jessen:
Christian Boltz wrote:
here are the minutes of today's heroes meeting: Christian, as always, thanks!
Thanks for the flowers, but I only typed small parts of the meeting minutes into the pad ;-)
- mailman3: - held messages in the queues should be deleted automatically for *-auto lists, because: more or less nobody cares anyway.
Hmm, no, I don't agree - I'm sorry if I failed to make my point clear.
We have to consider 'admin-auto' a key destination for error messages. Not everyone cares as much about their "baby" as others, but if we just throw away the cries, no one will ever know.
Agreed, and that's why we have admin-auto. However, the more interesting question is why mails to admin-auto go into the moderation queue and if that makes sense - see below.
- for human lists, the story is a bit more complicated - but over all, having more than 100 held messages in one list, it's not realistic to asume that a human will clean up the list of held messages manually -> configure *-auto messages to discard messages right away (can be changed for debugging at any time)
I am hesitant about that. "send error message" -> "discard" - that is not a sound policy.
Well, if that error message goes into the moderation queue, it's about as visible as it would be in /dev/null ;-) I would _guess_/expect that admin-auto accepts mails from non-subscribers (no idea if we have a restriction on @*.i.o.o senders) - and if something goes into the moderation queue, there's probably a good reason and a rule for that in the mailman config. For example, I remember that the forums sometimes included the database password in mails, and I'd guess that we might have a filter rule for these mails to put them on hold. Redirecting these mails with the database password to /dev/null instantly doesn't sound too bad to me ;-) (Please correct me if my guess about the admin-auto config is wrong.)
-> implement an automatism that will delete all but the last 100 held messages in a list. This should leave a chance for human moderators to look at least for the most common held messages.
Unfortunately, we don't have enough human moderators. Instead we (I) should finish that ticket about "rejecting mails from non-subscribers", and figure out what to do with the last few.
Right, that makes sense - ideally mails should get handled instantly (either accepted or rejected). Ending up in the moderation queue is probably the worst case for the sender _and_ the moderators. Regards, Christian Boltz -- [ X-Mailer: Microsoft Outlook Express 6.00.2800.1106 ] Damit ist deinem Kmail der Preis für die gruseligste Halloween-Maske dieses Jahres sicher. [Andreas Koenecke zu Martin Mewes in suse-linux]
On 07/07/2022 23.05, Per Jessen wrote:
Christian Boltz wrote:
Hello,
here are the minutes of today's heroes meeting:
Christian, as always, thanks!
Indeed! No way I could attend, I'm travelling and not alone. Reading this is nice. ...
-> implement an automatism that will delete all but the last 100 held messages in a list. This should leave a chance for human moderators to look at least for the most common held messages.
Unfortunately, we don't have enough human moderators.
Maybe I can volunteer for that? Not for moderating humans, but with those queued messages. When I return from my trip, not now. Or other "low hanging fruit" but time consuming. Low hanging because I don't think I'm good enough for many things you do.
Instead we (I) should finish that ticket about "rejecting mails from non-subscribers", and figure out what to do with the last few.
... -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
participants (3)
-
Carlos E. R. -
Christian Boltz -
Per Jessen