While T234743 is still unresolved, a workaround (that is also used by enwiki) is to restore the "reviewer" group that MediaWiki-extensions-FlaggedRevs defines, and assign the patrollers to this group as well.
|operations/mediawiki-config||master||+6 -2||Restore the 'reviewer' group for fawiki|
|Open||None||T234743 User rights validation is sometimes malfunctioning (with FlaggedRevs only?)|
|Resolved||Huji||T249643 Restore the "reviewer" group for fawiki|
Change 587301 had a related patch set uploaded (by Huji; owner: Huji):
[operations/mediawiki-config@master] Restore the 'reviewer' gropu for fawiki
@Urbanecm Are we supposed to schedule patches before they are +2ed (because I've got a couple)?
Thanks, I added two to SWAT deployments, as for this patch, we need someone to test this with admin rights, probably Huji themselves.
@Huji Yes, all config patches needs to. You basically need to schedule the patch at https://wikitech.wikimedia.org/wiki/Deployments in any SWAT window (except Puppet SWAT :-)) and then be available in #wikimedia-operations during the window you chosed. Everything else can be explained during the SWAT deployment. More detailed instructions can be found at this GCI taskhttps://www.mediawiki.org/wiki/Google_Code-in/Admins#Deploy_a_Wikimedia_site_configuration_change_(2018/2019).
Config patches can be scheduled as soon as they're created, backports need to have +2 in master. You don't need to do anything extra with code patches that aren't urgent. Does that make sense?
I was referring to config patches, I was under the impression that they need to be +2ed before scheduling for deployment and did not schedule them (now I have), so all's good. :)
That's what I thought too. Because I have submitted lots of non-urgent config patches, all of which were +2'ed and eventually deployed without me being involved with their scheduling or SWAT. So I was assuming that this patch would go through the same experience.
Eventually, it can happen someone who knows what the config patch will change and is at least somehow sure it is wanted by the community will deploy that patch without you being involved. However, that should be more an exception than a rule. I hope that makes sense.
Gotcha. With config patches, they're never merged without being deployed (and if they do, it's always a mistake). Thanks for scheduling your patches!
Thanks for the explanation. So should I work on scheduling this? Or make myself available for a particular SWAT window?
The best thing to do would be that you schedule the patch at https://wikitech.wikimedia.org/wiki/Deployments for a SWAT window of your choice, and be available in #wikimedia-operations IRC channel during that SWAT window.
Is is possible to list on the Deployment page when the train is blocked, I scheduled patches last time (and was on IRC) only to be informed that it is policy to not conduct SWAT deploys when the train is blocked. :/
[OT] Perhaps you want to join https://groups.google.com/a/wikimedia.org/forum/#!forum/sitereq-l and discuss this kind of stuff there? :-) IMO it's too hard to specify all the kind of conditions that may lead to a SWAT deployer refusing to do the window.
Ok, will do. But can you explain why in all other instances where I submitted a config patch, I never had to schedule it myself? Examples can be found here and even as recently as 9 months ago I had a patch that you +2 and got deployed without my involvement in scheduling.
Since you did not schedule it for SWAT, it sat there for more than a year until someone (Urbanecm in this case) found it randomly. You should have read Amir's comment to you here: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/430627/#message-387fdb008e056fa4b594e805d75f388b836d63d9 which was basically about this.
Change 587301 merged by jenkins-bot:
[operations/mediawiki-config@master] Restore the 'reviewer' group for fawiki
Mentioned in SAL (#wikimedia-operations) [2020-05-05T23:44:50Z] <catrope@deploy1001> Synchronized wmf-config/flaggedrevs.php: Restore the reviewer group on fawiki (T249643) (duration: 01m 06s)