As raised in #32854, there's currently no formal mechanism for communicating security or stability issues with backports users. Information is spread amongst various QA and developers mailing lists and a simple user who wants to keep backports working isn't able to keep up-to-date in a convenient fashion. The backports-announce mailing list exists, has dozens of subscribers, seems to be a good communication mechanism, but has apparently never been used. It is now open to QA committers for manual announcements, but there should be a process for using it. Here are some questions for the process to address: 1. How often should there be posts to the list? For every backport push? Only for unusual ones (like #32854)? (There are currently very few backports, so an update for every one is probably reasonable right now.) 2. Do we want automated updates to go to the list for every backports push? What tooling will need to change for this? 3. Who is allowed to post to the list (for manual posts)? 4. Where should the existence of backports-announce be advertised? Wiki? Blog post? Message to specific other mailing lists? Elsewhere?
1, 2, 3: Can a post be automatically generated when a backport is pushed, (having the flag "validated_backport" set) simply using bug headline as subject, and a link to it in the body? Possibly it could also send message when a bug is created having the Component set to "Backport". Interested users could then as normal comment on the bug or set them as CC there to subscribe to it. On top of that the members of the list (users, packagers, testers) can post to the list as they see fit. 4: When it is decided and verified to work... A) Add and describe here how it works: https://wiki.mageia.org/en/Mailing_lists B) Forum and Blog post to announce it, link to header in that wiki page
CC: (none) => fri
A post could be automatically generated when a backport is pushed. The move script currently generates messages like this one: https://ml.mageia.org/l/arc/sysadmin-reports/2024-03/msg00008.html That's not really in a form suitable for end-users, though, but this is the most straightforward option & easy to implement. We could alter the message to drop the "renamed" section in mails sent to backports-announce. Or, further alter it to also include the rpm -qip for the src.rpm. Or tweak it further to make it more palatable for this purpose. I think sending bug updates to an -announce list is too prone to spurious messages. There often end up being long discussions about problems on bugs that end-users don't really care about, and -announce lists are expected to have a high SNR.
(In reply to Dan Fandrich from comment #2) > I think sending bug updates to an -announce list is too prone to spurious > messages. There often end up being long discussions about problems on bugs > that end-users don't really care about, and -announce lists are expected to > have a high SNR. Agree: I think only send when A) opened, B) pushed Interested users can subscribe directly to the bug in bugzilla, completely separate from this backport list.
Sending a message on opening might be OK as long as it's only bugs for QA approval and not every backport request that comes in. I'm not sure if Bugzilla can be configured to send on open only, either.
Blog post or wiki pages should only be written when the backport achieve an important milestone like the current bug#32854 that implements multi version support for php A notification in mail list should be enough for other backports
I think it is good to have a post when request is opened, so interested users can participate in testing and feedback. It is better that interested users do the testing as they probably know the software best, and it offloads QA. Blog post: agree, only on prominent achievements. I was thinking one posting informing about the list.
See also bug#32947 which proposes issuing advisories for backports and using the same mgaadv notification mechanism.
I believe every post to the ML and/or blog concerning a backport announcement should contain the standard warning that backports may not receive the same level of testing as updates, and may break a system. That way, users can't say they weren't warned if the worst does happen. I got caught once with Mandriva. I installed a new Firefox from backports, and it included a dependency that broke Gnucash. Fortunately I was only trying out Gnucash, and decided it wasn't for me, but for someone else it could have been catastrophic.
CC: (none) => andrewsfarm
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=32947
commit 7efb270a5fb53f3559690f1f258c10ab38574729 Author: Dan Fandrich <danf@...> Date: Tue Mar 26 20:59:54 2024 -0700 Fix backports-announce so mga-qa-committers members can send (mga#32929) --- Commit Link: https://gitweb.mageia.org/infrastructure/puppet/commit/?id=7efb270a5fb53f3559690f1f258c10ab38574729
commit 27dc546f61e92ac3292f1bd92a6e8173154aad23 Author: Dan Fandrich <danf@...> Date: Wed Mar 27 14:40:17 2024 -0700 Create search filter for sender_ldap_group (mga#32929) --- Commit Link: https://gitweb.mageia.org/infrastructure/puppet/commit/?id=27dc546f61e92ac3292f1bd92a6e8173154aad23