- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 12 2019
FYI, I've merged a change yesterday that should've fixed the problem from now on.
Scheduled to be deployed during European Mid-day SWAT on Tuesday, February 12.
Scheduled to be deployed during European Mid-day SWAT on Tuesday, February 12.
Scheduled to be deployed during European Mid-day SWAT on Tuesday, February 12.
Change 489972 merged by Marostegui:
[operations/puppet@production] dbstore1003: Enable notifications
Script run is done and 1142 drafts were purged. However, we still have slow query issue mentioned earlier.
Change 489972 had a related patch set uploaded (by Marostegui; owner: Marostegui):
[operations/puppet@production] dbstore1003: Enable notifications
In T211117#4945583, @kostajh wrote:One concern in implementing this feature is how the configuration is going to be managed. As noted in this task, there is a desire to move configuration into on wiki (e.g. Mediawiki:HelpPanelLinks). We could envision a three column layout, column A for title, column B for label, column C for "context", containing data like platform=*,editor=ve,action=*,namespace=2,3. We'd have to provide some documentation at the top of the wiki config page to make it clear how this should all work.
Change 489971 had a related patch set uploaded (by Tulsi Bhagat; owner: Tulsi Bhagat):
[operations/mediawiki-config@master] Enable Rollbackers User Group Right on azwiki
In T18691#4933489, @Msftwikipmey wrote:@osorio-juan-microsoft and I work on a wiki that has a lot of traffic coming directly into sections instead of pages, so we are working on a design that will mitigate the issues mentioned in T18691#1098570.
[..]
I'm not a designer, but personally I think this looks like a promising approach. Thanks for sharing!
Out of professional curiosity: Are you planning to measure the impact of this change on users' reading/linking behaviour in any way?
Mentioned in SAL (#wikimedia-operations) [2019-02-12T06:33:25Z] <kart_> Finished fourth manual run of unpublished draft purge script (T203059)
Change 489969 had a related patch set uploaded (by Eileen; owner: Eileen):
[wikimedia/fundraising/crm@master] Adjust different on omnirecipient repair - then I can kick it off & catch a few more
Mentioned in SAL (#wikimedia-operations) [2019-02-12T06:14:42Z] <marostegui> Deploy schema change on db1099:3318 T210713
Change 489968 merged by jenkins-bot:
[operations/mediawiki-config@master] db-eqiad.php: Depool db1099:3318
I am just following up to check if all the relevant data was deleted. I can see that
I get the idea of server-side HTML rendering to avoid delays. But I am kinda questioning whether the advantage of splitting code outside of PHP into separate service and all the complexities that follow from that.
Change 489968 had a related patch set uploaded (by Marostegui; owner: Marostegui):
[operations/mediawiki-config@master] db-eqiad.php: Depool db1099:3318
@Jdlrobson I just want to be sure of the following:
Mentioned in SAL (#wikimedia-operations) [2019-02-12T06:04:30Z] <kart_> Fourth manual run of unpublished draft purge script (T203059)
Yes, judging from our preliminary test, if we get uncontested use of the server or even a certain chunk of it maybe (not sure if possible?) it would be enough. Note that an interesting scenario that we want to test in foreseeable future involves cluster setup, so we'd want at least 2 hosts (not sure whether they have to be on 2 separate hardware machines) with requirements close to what wdqs hosts have. It could splitting cloudvirt host into two VMs exclusively used by these test hosts would be ok. Not sure if virtualization that we do now allows such kind of fixed resource allocations (probably also I/O resources need to be taken care of?)
Change 489966 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[mediawiki/extensions/ExternalGuidance@master] Eventlogging integration
One change could be to not group when there's only one item in each group, like in https://tools.wmflabs.org/svgtranslate-test/File:Cathedral.svg
please review the following.
Will do! thanks for the feedback!
@Jdrewniak & @alexhollender I'm not sure if this is a feature or a bug, but the "Learn more" link appears right justified when I check it with a phone aspect ratio but left justified when I check it with a tablet or desktop. I am happy to document the test for tablets or desktop, but when I click the hamburger with a phone emulation, the link goes off screen to the right so I cannot verify it. Let me know how you'd like me to proceed.
Such fun.
It's not urgent for me, but I think it's also not far from being done. I've brought the patch up to date with the latest feedback from @davidwbarratt, but the tests are currently failing due to some npm inconsistency — probably not too hard to fix, I'll look at it now and see if we can merge soon.
Change 489958 merged by jenkins-bot:
[WrappedString@master] Limit hhvm version to 3.18
Change 489954 merged by jenkins-bot:
[php-session-serializer@master] Limit hhvm version to 3.18
Change 489953 merged by jenkins-bot:
[css-sanitizer@master] Limit hhvm version to 3.18
Change 489958 had a related patch set uploaded (by Reedy; owner: Reedy):
[WrappedString@master] Limit hhvm version to 3.18
Change 489955 merged by jenkins-bot:
[mediawiki/libs/XMPReader@master] Limit hhvm version to 3.18
Change 489957 merged by jenkins-bot:
[IPSet@master] Limit hhvm version to 3.18
Change 489956 merged by jenkins-bot:
[at-ease@master] Limit hhvm version to 3.18
Change 489957 had a related patch set uploaded (by Reedy; owner: Reedy):
[IPSet@master] Limit hhvm version to 3.18
Change 489956 had a related patch set uploaded (by Reedy; owner: Reedy):
[at-ease@master] Limit hhvm version to 3.18
Change 489955 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/libs/XMPReader@master] Limit hhvm version to 3.18
Change 489954 had a related patch set uploaded (by Reedy; owner: Reedy):
[php-session-serializer@master] Limit hhvm version to 3.18
Change 489953 had a related patch set uploaded (by Reedy; owner: Reedy):
[css-sanitizer@master] Limit hhvm version to 3.18
Change 489952 had a related patch set uploaded (by Eileen; owner: Eileen):
[wikimedia/fundraising/crm@master] WIP - Adjust Benevity import to reflect changed csv from Benevity
I've updated deploy.sh to use composer etc. directly.
Just a quick note to say I've grabbed the file & these are the changes
@Niharika Oh, sorry. I thought the tool creates a new file with a new name added. I didn't notice that translations are added to the same image file name using switch-translations. Thanks for notifying.
Status: ✅ PASS
OS: macOS Mojave
Browser: Chrome DevTools Device Emulator (iPhone X)
Do we want to just pin the HHVM version(s) we want testing against? As I'm guessing this is some issue with HHVM 4 vs HHVM 3
Change 489949 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[mediawiki/event-schemas@master] Set maxLength on patternlike fields in tewst/event/0.0.2
I think a good example we could build off of would be https://status.discordapp.com/ as it has the basics and explains why an issue happens. We could easily expand something like this to fit the needs of Wikimedia. Discord uses an external provider, however the look of the page itself is quite easy to understand.
Status: ✅ PASS
OS: macOS Mojave
Browser: Chrome DevTools Device Emulator (iPhone X)