daniel moved this task from Incoming (Needs Triage) to Done on the
MW-Interfaces-Team board.
daniel added a comment.
I think this should be fixed now, can you confirm?
TASK DETAIL
https://phabricator.wikimedia.org/T359149
WORKBOARD
https://phabricator.wikimedia.org/project/board/6931
daniel added a project: MW-Interfaces-Team.
TASK DETAIL
https://phabricator.wikimedia.org/T359149
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Ifrahkhanyaree_WMDE, Jdforrester-WMF, daniel, Lucas_Werkmeister_WMDE,
Aklapper, Jakob_WMDE
daniel added a project: MW-Interfaces-Team.
TASK DETAIL
https://phabricator.wikimedia.org/T353199
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: tstarling, Ericliu1912, Winston_Sung, JTannerWMF, ABorbaWMF, matmarex,
Aklapper, Tgr, Stang
daniel added a comment.
Working on a fix
TASK DETAIL
https://phabricator.wikimedia.org/T359149
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: daniel, Lucas_Werkmeister_WMDE, Aklapper, Jakob_WMDE,
Danny_Benjafield_WMDE, Astuthiodit_1
daniel added a comment.
In T333966#8758611 <https://phabricator.wikimedia.org/T333966#8758611>,
@Ladsgroup wrote:
> Not yet (that's why I didn't merge the revert on master), It should be easy
to reproduce though, messages from extensions are not being added to the fi
daniel added a comment.
In T333966#8755748 <https://phabricator.wikimedia.org/T333966#8755748>,
@Ladsgroup wrote:
> Okay, it fixed it in group0 so it should unblock the train but I haven't
merged the path on master (force merging on master is even worse than force
merging on
daniel closed subtask T195069: Factor PageStore and PageRecord out of WikiPage
as Resolved.
TASK DETAIL
https://phabricator.wikimedia.org/T196087
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Tgr, gerritbot, Aklapper, daniel
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T174022
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Magol, Lokal_Profil, AfroThundr3007730, Agabi10, Liuxinyu970226, TomT0m,
Smalyshev, -jem-, Aklapper
daniel added a comment.
In T138208#7727286 <https://phabricator.wikimedia.org/T138208#7727286>,
@Ladsgroup wrote:
> At least it can avoid connecting to non-dump hosts.
I thought we did that... maybe @ArielGlenn has an idea.
TASK DETAIL
https://phabricator.wikimedia.or
daniel added a comment.
In T138208#7727264 <https://phabricator.wikimedia.org/T138208#7727264>,
@Ladsgroup wrote:
> Possibly but also keeping the connection open? Maybe it needs to buffer,
close the connection and then compress given that it's cpu intensive and slow?
Wik
daniel added a comment.
In T138208#7727235 <https://phabricator.wikimedia.org/T138208#7727235>,
@Ladsgroup wrote:
> Most notably the top of the snapshot is not the dumper, it's bzip2. Does it
keep connection open while compressing?
Isn't it compressing the stream on the f
daniel added a comment.
For the record, I don't remember what specifically went into the decision to
rely on ISO-639-1. I have tried to gather some information around the topic.
here are some thoughts and observations:
- Allowing both ISO-639-1 and ISO-639-3 would mean we'd end up
daniel added a comment.
In T138208#7625170 <https://phabricator.wikimedia.org/T138208#7625170>,
@Ladsgroup wrote:
> I think we have different perspectives and it might be because I'm coming
from SRE? I personally think dumps are actually the environment, not the code.
daniel added a comment.
In T138208#7612881 <https://phabricator.wikimedia.org/T138208#7612881>,
@Ladsgroup wrote:
> Thanks, that was the missing piece. My suggestion would be to set an
environmental variable in calling mw scripts (if it's not set already). phpunit
does a simi
daniel added a comment.
In T138208#7568960 <https://phabricator.wikimedia.org/T138208#7568960>,
@ArielGlenn wrote:
> As I feared, fetchText.php calls
MediaWikiServices::getInstance()->getBlobStore()->getBlob() which gets a db
replica connection on its own, with no opp
daniel edited projects, added Platform Team Workboards (MW Expedition); removed
Platform Engineering.
TASK DETAIL
https://phabricator.wikimedia.org/T287650
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper, eprodromou, daniel
daniel triaged this task as "Medium" priority.
daniel edited projects, added Platform Team Workboards (MW Expedition); removed
Platform Engineering.
TASK DETAIL
https://phabricator.wikimedia.org/T287713
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailp
daniel triaged this task as "Medium" priority.
daniel edited projects, added Platform Team Workboards (MW Expedition); removed
Platform Engineering.
TASK DETAIL
https://phabricator.wikimedia.org/T287714
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailp
daniel added a comment.
I agree: keep using WikiPage::prepareContentForEdit() until Id5ba40a21
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/701074> lands, then start
using that. Feedback on that patch would be appreciated.
I'm sorry for the confusion that was
daniel added a project: Platform Engineering Code Jam.
TASK DETAIL
https://phabricator.wikimedia.org/T235901
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: daniel, Nikki, Infovarius, Premeditated, Alicia_Fagerving_WMSE, Marsupium
daniel moved this task from Untriaged to Code Jam on the Platform Engineering
Roadmap Decision Making board.
daniel added a comment.
Tagging as a potential PET Code Jam activity.
TASK DETAIL
https://phabricator.wikimedia.org/T235901
WORKBOARD
https://phabricator.wikimedia.org/project
daniel added a project: Platform Engineering Roadmap Decision Making.
TASK DETAIL
https://phabricator.wikimedia.org/T235901
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Nikki, Infovarius, Premeditated, Alicia_Fagerving_WMSE, Marsupium
daniel added a comment.
`flavor=dump` is used primarily for updating WDQS, right? In that case, the
data is polled because it is know to have changed. So caching seems pointless...
TASK DETAIL
https://phabricator.wikimedia.org/T285795
EMAIL PREFERENCES
https://phabricator.wikimedia.org
daniel added a project: Platform Team Workboards (MW Expedition).
TASK DETAIL
https://phabricator.wikimedia.org/T283654
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Lucas_Werkmeister_WMDE, daniel
Cc: toan, dang, Lucas_Werkmeister_WMDE, Aklapper
daniel added a comment.
IIRC the output of Special:EntityData is cacheable in the web cache layer.
Cache fragmentation should be considered when deciding on language parameters.
Maybe the cache should be bypassed if a parameter is present. Or if more than
one language is requested
daniel added a comment.
> Scavenging the production logs, we found that Special:EntityData requests
for rdf documents were possibly the culprit.
Did the code change, or is it just someone is spidering Special:EntityData,
hitting that code an awefull lot?
TASK DETAIL
ht
daniel added a comment.
We discussed it, and I commented on the patch. The support the general idea
(represent language links as objects, not strings, in ParserOutput and
OutputPage). The devil is in the detail, though.
TASK DETAIL
https://phabricator.wikimedia.org/T204792
EMAIL
daniel added a project: Platform Team Workboards (MW Expedition).
daniel added a comment.
Putting this on the expedition board, since the proposed patch overlaps with
refactoring work we are doing.
TASK DETAIL
https://phabricator.wikimedia.org/T204792
EMAIL PREFERENCES
https
daniel edited projects, added Platform Team Workboards (Clinic Duty Team);
removed Platform Engineering.
daniel triaged this task as "Low" priority.
daniel added a comment.
Not high prio for the PET team, but if anyone wants to take it on, please do
:)
TASK DETA
daniel added a project: Platform Engineering Roadmap Decision Making.
daniel added a comment.
Tagging this for roadmapping in the light of T247223: Some Meta-Wiki user
pages fatal due to OOM from Babel loading too many localisation caches (from
cdb/src/Reader/DBA.php) <ht
daniel added a comment.
Yea, it's not good to use a base class for this. It should be a trait, or
just be removed.
TASK DETAIL
https://phabricator.wikimedia.org/T279063
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: daniel, Pchelolo
daniel added a comment.
In T275251#6949064 <https://phabricator.wikimedia.org/T275251#6949064>,
@Jdlrobson wrote:
>> One long standing issue with the search box on commons is that namespace
prefixes do not work. You can't type in "User:..." to search user pages.
daniel added a comment.
Another fun wrinkle to all this:
One long standing issue with the search box on commons is that namespace
prefixes do not work. You can't type in "User:..." to search user pages. Since
the search box always hits entitysearch, it won't find anythi
daniel added a comment.
In T275251#6947445 <https://phabricator.wikimedia.org/T275251#6947445>,
@Jdlrobson wrote:
> I understand and I'm saying that this could be implemented using an
abstracted PHP interface which provides a contract for the format in the
response, without h
daniel added a comment.
In T275251#6945709 <https://phabricator.wikimedia.org/T275251#6945709>,
@Jdlrobson wrote:
> Please no more UI components.. that would be a maintenance disaster as
Wikidata would need to do this for every skin (we plan to use this same Vue
compone
daniel added a comment.
I'm unconvinced that hooking into SearchHandler is the Right Thing. The
endpoint is `/v1/search/title`, making that do anything but title
auto-completion would be confusing, it would break the contract. I'd also argue
that we will still want title auto-completion
daniel added a subscriber: Naike.
daniel added a comment.
In T214362#6921322 <https://phabricator.wikimedia.org/T214362#6921322>,
@Addshore wrote:
> It looks like we would be able to use the ParserCache for this one T270710:
Allow values other than ParserOutput to
daniel added a subscriber: tstarling.
daniel added a comment.
@tstarling rememberd that we were discussing this exact thing when he worked
on NameTabelStoreFactory:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/455487/4
I think his suggestion at the time was to gave a newFromSpec
daniel added a comment.
NameTableStore can become newable. The fact that it 's not is just an
oversight from my point of view. I'd be reluctant to make it // stable to
extend//, though.
NameTableStoreFactory is conceptually questionable - different NameTableStore
instances may be used
daniel added a comment.
Thank you for your response, @brennen!
In T277362#6922054 <https://phabricator.wikimedia.org/T277362#6922054>,
@brennen wrote:
> 1. Deployers have no way to know in the moment that something is only a
deprecation warning with no other con
daniel added a subscriber: thcipriani.
daniel added a comment.
In T277362#6920796 <https://phabricator.wikimedia.org/T277362#6920796>,
@WMDE-leszek wrote:
> It is indeed very unfortunate that there has not been automated tests for
this functionality. It would have given the i
daniel added a comment.
In T277362#6919927 <https://phabricator.wikimedia.org/T277362#6919927>,
@Legoktm wrote:
> It just pushes the problem onto someone else, by stopping their development
and forcing them drop everything just to unbreak their repo
I was not aware this
daniel added a comment.
For context - the description is of T275531
<https://phabricator.wikimedia.org/T275531> is indeed rather short, and the
real background is in T273284 <https://phabricator.wikimedia.org/T273284>. The
idea is that we to avoid data corruption such as T26
daniel added a comment.
> I also notice that MediaWiki core has again hard-deprecated code that is
still used in Wikimedia-maintained code even though the stable interface policy
forbids this
This was of course not intentional - the policy asks for hard deprecation to
happen as s
Daniel-Barrows added a comment.
Relevant discussion has been archived at
https://www.wikidata.org/wiki/Wikidata:Bot_requests/Archive/2017/2#Take_care_of_disambiguation_items
TASK DETAIL
https://phabricator.wikimedia.org/T139912
EMAIL PREFERENCES
https://phabricator.wikimedia.org
daniel added a comment.
@Lucas_Werkmeister_WMDE wrote:
> so for a RevisionRecord belonging to a non-local wiki, calling getId()
without arguments will now trigger a call to wfDeprecatedMsg(). But
wfDeprecatedMsg() is apparently enough to make unit tests fail, and also cause
warni
daniel renamed this task from "Wikidata API fails with timeout when asking for
5 RC redirects" to "RecetChanges query API fails with timeout when asking for 5
RC redirects in on Wikidata".
TASK DETAIL
https://phabricator.wikimedia.org/T245989
EMAIL
daniel lowered the priority of this task from "High" to "Medium".
TASK DETAIL
https://phabricator.wikimedia.org/T113034
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Addshore, Ladsgroup, kchapman, Lucas_Werkmeist
daniel added a comment.
In T214362#6653148 <https://phabricator.wikimedia.org/T214362#6653148>,
@Addshore wrote:
> It's a shame that this has made its way into the "icebox" of the
#platform_engineering_roadmap_decision_making
<https://phabric
daniel added a project: User-Daniel.
TASK DETAIL
https://phabricator.wikimedia.org/T237991
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Keegan, Cparle, Multichill, matthiasmullie, Ramsey-WMF,
AntiCompositeNumber, Tgr, Addshore, Jarekt
daniel removed daniel as the assignee of this task.
TASK DETAIL
https://phabricator.wikimedia.org/T67267
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: PokestarFan, Jc3s5h, Wikidata-bugs, Lydia_Pintscher, daniel, JohnLewis,
Akuckartz
daniel removed daniel as the assignee of this task.
daniel added a project: User-Daniel.
TASK DETAIL
https://phabricator.wikimedia.org/T194736
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper, Agabi10, TomT0m, Smalyshev, -jem
daniel added a project: User-Daniel.
daniel removed daniel as the assignee of this task.
TASK DETAIL
https://phabricator.wikimedia.org/T205459
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Cparle, Aklapper, gerritbot, daniel, Naike
daniel edited projects, added Platform Team Workboards (Clinic Duty Team);
removed Platform Team Workboards (External Code Reviews).
TASK DETAIL
https://phabricator.wikimedia.org/T260232
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc
daniel added a comment.
The fix for T255056 <https://phabricator.wikimedia.org/T255056> should
address this as well.
TASK DETAIL
https://phabricator.wikimedia.org/T257196
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: daniel,
daniel closed this task as a duplicate of T255056:
MediaWikiIntegrationTestCase::setTemporaryHook needs to support new style hooks
.
TASK DETAIL
https://phabricator.wikimedia.org/T257196
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc
daniel added a comment.
In T254688#6406171 <https://phabricator.wikimedia.org/T254688#6406171>,
@Lydia_Pintscher wrote:
> Ok thanks. That special page is rather important for Wikidata and turning
it off completely is not an option I fear.
My idea was to turn of the "
daniel added a comment.
In T254688#6405484 <https://phabricator.wikimedia.org/T254688#6405484>,
@Marostegui wrote:
> The only workaround we've found is sadly, using `FORCE`, `USE` or `IGNORE
INDEX` on the queries to bypass those issues. Sometimes issues get fixed by
running an
daniel added a comment.
In T254688#6395860 <https://phabricator.wikimedia.org/T254688#6395860>,
@Lydia_Pintscher wrote:
> Hard to tell without the context of when this is happening for users. Does
anyone know?
The query in question is generated by
https://www.wikidata
daniel added subscribers: Lydia_Pintscher, daniel.
daniel edited projects, added Platform Engineering; removed Platform Team
Workboards (Clinic Duty Team).
daniel added a comment.
Back to the inbox for triage. This isn't actionable as it is. We'd probably
have to design a new schema
daniel added a comment.
might be related to T253289: Remove USE INDEX usertext_timestamp and other
references from code <https://phabricator.wikimedia.org/T253289>
TASK DETAIL
https://phabricator.wikimedia.org/T257002
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings
daniel added a comment.
> The original core test still throws errors that seem related to Wikibase
You mean this one? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/475065
As I noted there:
> The "dangerous" methods on DatabaseUpdater are no lo
daniel added a comment.
For reference, Brad used PooLCounter to impose a limit on
Special:Contributions recently, see
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/551909
TASK DETAIL
https://phabricator.wikimedia.org/T252091
EMAIL PREFERENCES
https://phabricator.wikimedia.org
daniel edited projects, added Wikidata; removed Core Platform Team Workboards
(Clinic Duty Team).
daniel added a subscriber: Addshore.
daniel added a comment.
Untagging CPT, tagging #wikidata
<https://phabricator.wikimedia.org/tag/wikidata/> . Pinging @Addshore to have a
look.
TASK
daniel added a comment.
In T251457#6105089 <https://phabricator.wikimedia.org/T251457#6105089>,
@Jdforrester-WMF wrote:
> UBN patches, and particularly train-blocking UBN patches, should not wait
for SWAT, but be deployed immediately (in line with
https://wikitech.wikimedia
daniel added a comment.
In T251457#6104041 <https://phabricator.wikimedia.org/T251457#6104041>,
@LarsWirzenius wrote:
> https://gerrit.wikimedia.org/r/593757 has been merged, but has it been
deployed (I assume it will need to be backported to the 1.35.0-wmf.30 branch as
wel
daniel added a comment.
> Using IETF language tags seems like the most useful solution to me
I dimly recall a similar discussion from years ago. IIRC, IETF is extensible,
and we came up with a way to encode item IDs in language tages, something like
`qid-36163` (by fortunate coincide
daniel added a comment.
While I was chatting with @Krinkle on IRC, he found out that
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/582022 caused
Database::lock() to be treated as a write operation now. This was not the case
before, and indeed should not be the case. This means the error
daniel added a comment.
In T251457#6099971 <https://phabricator.wikimedia.org/T251457#6099971>, @Tgr
wrote:
> MediaWiki automatically wraps the entire request in a transaction if it
encounters a write which does not do its own transaction handling. So something
unrelated
daniel added a comment.
> I'm not entirely sure I understand it correctly, but
PageEditStash::getAndWaitForStashValue uses ILoadBalancer::getAnyOpenConnection
and by chance acquires a connection where a transaction was already open for
edit?
Yes. the question is,
daniel added a comment.
@Pchelolo can you provide the rest of the stack trace? This is triggered via
SpamBlacklistHooks, and I want to understand why that is being executed inside
the DB transaction.
TASK DETAIL
https://phabricator.wikimedia.org/T251457
EMAIL PREFERENCES
https
daniel added a comment.
In T251457#6098793 <https://phabricator.wikimedia.org/T251457#6098793>,
@Krinkle wrote:
> @daniel How did it work before? What needed to change? What actually
changed?
I'm not aware of any changes in that area.
TASK DETAI
daniel added a comment.
So, PageEditStash::parseAndCache() parses the page while holding the lock.
PageEditStash->getAndWaitForStashValue() waits for that lock, and it apparently
does so within the DB transaction that will be used to write the new revision.
If parsing takes l
daniel added a comment.
In T251457#6098675 <https://phabricator.wikimedia.org/T251457#6098675>,
@Pchelolo wrote:
> It's PageEditStash. See my comment above.
Saw it and already edited my comment ;)
TASK DETAIL
https://phabricator.wikimedia.org/T251457
EMAIL PREFERENCE
daniel added a comment.
In T251457#6098402 <https://phabricator.wikimedia.org/T251457#6098402>,
@Pchelolo wrote:
> @daniel I don't think this is that lock showing up here. Reading the code,
it seems like if that lock was taken, we should've seen a bunch more queries in
this tr
daniel added a comment.
Interesting. RevisionStore::insertRevisionRowOn() does uses GET_LOCK when it
detects the auto-increment value of the revision table to be out of sync. This
was introduced as a fix for T202032: Duplicate ar_rev_id values in several
wikis <ht
daniel added subscribers: DannyS712, daniel.
daniel added a comment.
Pinging patch author @DannyS712
TASK DETAIL
https://phabricator.wikimedia.org/T251457
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: daniel, DannyS712, Jdforrester
daniel edited projects, added Core Platform Team Workboards (Clinic Duty Team);
removed Core Platform Team.
TASK DETAIL
https://phabricator.wikimedia.org/T251457
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Liuxinyu970226, brennen
daniel added a comment.
In T157651#6075764 <https://phabricator.wikimedia.org/T157651#6075764>,
@Krinkle wrote:
> @daniel I noticed a patch that makes some methods inaccesible to
extensions. Does that mean this structure test is no longer needed? Or are
there some dangerou
daniel added a comment.
It seems like all essential patches are merged. Can this be closed now?
TASK DETAIL
https://phabricator.wikimedia.org/T157651
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Demian, Jdforrester-WMF, kostajh
daniel added a comment.
In T249598#6073487 <https://phabricator.wikimedia.org/T249598#6073487>,
@daniel wrote:
> Oh wait, this patch also belongs here, right?
> https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/507898
Actually, I think that patch is wr
daniel added a comment.
Oh wait, this patch also belongs here, right?
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/507898
TASK DETAIL
https://phabricator.wikimedia.org/T249598
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
daniel closed this task as "Resolved".
TASK DETAIL
https://phabricator.wikimedia.org/T249603
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: RhinosF1, Tgr, Aklapper, aaron, gerritbot, Reception123, Catrope, Krinkle,
kchapman,
daniel closed subtask T249603: DatabaseUpdater: protect methods for direct
database modification as Resolved.
TASK DETAIL
https://phabricator.wikimedia.org/T157651
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Demian, Jdforrester-WMF
daniel added a comment.
Looks like this is done, can the ticket be closed?
TASK DETAIL
https://phabricator.wikimedia.org/T249598
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Jdforrester-WMF, Aklapper, Krinkle, kchapman, Pablo-WMDE
daniel closed subtask T228088: BetaCluster: ExternalStoreException - Unable to
store text to external storage as Resolved.
TASK DETAIL
https://phabricator.wikimedia.org/T242717
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Krinkle
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T249603
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: RhinosF1, Tgr, Aklapper, aaron, gerritbot, Reception123, Catrope, Krinkle,
kchapman, Pablo-WMDE
daniel claimed this task.
TASK DETAIL
https://phabricator.wikimedia.org/T157651
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Demian, Jdforrester-WMF, kostajh, WMDE-leszek, Addshore, Anomie, alaa_wmde,
daniel, Ladsgroup, Pablo-WMDE
daniel removed a project: Core Platform Team Workboards (Clinic Duty Team).
daniel added a comment.
Wikibase problem is apparently fixed, untagging CPT.
TASK DETAIL
https://phabricator.wikimedia.org/T248459
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
daniel added a comment.
Note the the solution that was just merged is quite far from what is
discussed in the task description. If further work is desired here, please
re-open.
TASK DETAIL
https://phabricator.wikimedia.org/T240083
EMAIL PREFERENCES
https://phabricator.wikimedia.org
daniel moved this task from Waiting for Review to Done on the Core Platform
Team Workboards (Clinic Duty Team) board.
daniel closed this task as "Resolved".
TASK DETAIL
https://phabricator.wikimedia.org/T240083
WORKBOARD
https://phabricator.wikimedia.org/project/board/41
daniel closed subtask T249584: Call LoadExtensionSchemaUpdates later as
Resolved.
TASK DETAIL
https://phabricator.wikimedia.org/T157651
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Jdforrester-WMF, kostajh, WMDE-leszek, Addshore
daniel closed this task as "Resolved".
daniel added a comment.
It's done, as far as I know
TASK DETAIL
https://phabricator.wikimedia.org/T198557
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Anomie, DannyS712, Jdfor
daniel closed subtask T198557: Remove the ability to write pre-MCR fields,
limit the ability to read pre-MCR fields to migration scripts as
Resolved.
TASK DETAIL
https://phabricator.wikimedia.org/T198492
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
daniel added a comment.
Note: the above patch apparently missed on occurrence of dropTable()
TASK DETAIL
https://phabricator.wikimedia.org/T205094
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: daniel, Addshore, Aklapper
daniel added a subtask: T249584: Call LoadExtensionSchemaUpdates later.
TASK DETAIL
https://phabricator.wikimedia.org/T157651
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: kostajh, WMDE-leszek, Addshore, Anomie, alaa_wmde, daniel
daniel closed this task as a duplicate of T249584: Call
LoadExtensionSchemaUpdates later.
TASK DETAIL
https://phabricator.wikimedia.org/T249599
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper, aaron, gerritbot, Krinkle, Ladsgroup
daniel moved this task from Inbox to Ready on the Core Platform Team Workboards
(Clinic Duty Team) board.
daniel triaged this task as "High" priority.
TASK DETAIL
https://phabricator.wikimedia.org/T249603
WORKBOARD
https://phabricator.wikimedia.org/project/board/4149/
EMAIL P
daniel added a parent task: T249603: DatabaseUpdater: protect methods for
direct database modification .
TASK DETAIL
https://phabricator.wikimedia.org/T249598
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper, Krinkle, kchapman
daniel added a subtask: T249598: Wikibase schema updaters must not modify
database directly.
TASK DETAIL
https://phabricator.wikimedia.org/T249603
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: RhinosF1, Tgr, Aklapper, aaron, gerritbot
1 - 100 of 5223 matches
Mail list logo
