daniel edited projects, added Core Platform Team Kanban; removed Core Platform Team Backlog (Later).
TASK DETAILhttps://phabricator.wikimedia.org/T198341EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: gerritbot, Tgr, Jdforrester-WMF, Anomie
daniel added a subscriber: BPirkle.daniel added a comment.
@BPirkle want to look into this? No need to drop other stuff if you are busy. This is just something that's coming up, and seems like something you could take on.TASK DETAILhttps://phabricator.wikimedia.org/T198557EMAIL PREFERENCES
daniel added a project: Release-Engineering-Team (Kanban).
TASK DETAILhttps://phabricator.wikimedia.org/T198342EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Aklapper, aude, Addshore, Anomie, Jdforrester-WMF, Tgr, gerritbot, daniel, EvanProdromou
daniel added a comment.
In T213318#4938904, @Anomie wrote:
Would this affect how SDC works? Wikibase's editing is already weird, with JS-based editing on the view page, and seems unlikely to truly fit in with a future core MCR editing model. This proposal seems like it might extend that weir
daniel added a comment.
The MediaInfoContent class can just override the isValid() method, call $this->getMediaInfo()->getDescriptions(), and return false of that is not empty. This will prevent any MediaInfo to be stored if it has any descriptions set.
Other code that can provide a h
daniel added a comment.
In T214692#4939599, @Jdforrester-WMF wrote:
Aha, it was the jump from MediaInfoContent up to the MediaInfo class that confused me. Yeah, this works, but will presumably need us to remove all existing descriptions from production before deploying as otherwise those pages
daniel added a comment.
For reference: https://www.mediawiki.org/wiki/Wikibase/DataModel/Primer#StatementsTASK DETAILhttps://phabricator.wikimedia.org/T213318EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Cparle, Niedzielski, Anomie, Mholloway
daniel removed a project: Release-Engineering-Team (Kanban).daniel added a comment.
@daniel: sorry, I don't see how/why this should go on the releng-kanban board?
@greg it sholdn't - it should be on the CPT Kanban board. No idea what happened there, sorry :)TASK D
daniel added a comment.
@Smalyshev My understanding (which may be dated or incomplete) is this: there would be no PHP rendering, JS rendering would need to happen either in the browser on on the server. If the server supports SSR, you can read with a non-JS browser. If the server does not support
daniel added a comment.
In T213318#4954262, @dbarratt wrote:
Another solution to this problem would be to require Docker and Kuberneties which are both free and trivial to setup (especially if we distribute MediaWiki and all of it's services with Helm)
Wikibase could require that. MediaWik
daniel added a comment.
In T213318#4954287, @dbarratt wrote:
I wasn't aware of that. Could we update the Principles page to reflect that?
I suppose so. That page isn't really authoritative, and hasn't seen substantial updates since 2013 as far as I can tell.
The platform r
daniel added a comment.
In T213318#4955529, @Smalyshev wrote:
Having both 1 and 2 at the same time would be awesome, but I guess I'd also be fine with saying "you can have 1 but lose support for 2 or you can have 2 but then you need to have install beyond 1". By which I mean, if t
daniel added a comment.
In T213318#4955519, @dbarratt wrote:
Are our target demographics (and the reason why we are targeting them) documented somewhere?
I'm not aware of any concise and authoritative documentation of this, no. There are tons of discussions around this, on wikitech-l and
daniel added a comment.
In T213318#4955592, @dbarratt wrote:
On the other hand (at least for those employed by the Foundation), this is real money that is being used by our "customers" (our donors), so I think it's important to know what our Product strategy is (I assume we have o
daniel updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTIONAny code that accesses rev_text_id and ar_text_id fields is unable to make use of MCR. In order to enable for MCR support, all references to these fields have to be removed from the code. They should be replaced with
daniel added a comment.
In T198341#4962428, @BPirkle wrote:
Task description refers to "RevisionStore::newRevisionRecordFromRow()". Should that be "RevisionStore::newRevisionFromRow()"?
Yes, sorry about that. I'll fix the description.TASK DETAILhttps://phabricator.w
daniel added a comment.
In T198557#4961828, @BPirkle wrote:
I'm happy to, but it appears that I cannot edit or claim the task.
That's odd, there should not be any restrictions to that effect. @Aklapper can you have a look? Thanks!TASK DETAILhttps://phabricator.wikimedia.org/T1
daniel moved this task from Inbox to Backlog on the TechCom-RFC board.daniel added a comment.
Moving to backlog, since we are waiting for feedback from the RFC's author.TASK DETAILhttps://phabricator.wikimedia.org/T214362WORKBOARDhttps://phabricator.wikimedia.org/project/board/52/
daniel moved this task from Waiting for Review to Doing on the Core Platform Team Kanban board.daniel edited projects, added Core Platform Team Kanban (Doing); removed Core Platform Team Kanban (Waiting for Review).
TASK DETAILhttps://phabricator.wikimedia.org/T198706WORKBOARDhttps
daniel added a comment.
In T214362#4970942 <https://phabricator.wikimedia.org/T214362#4970942>,
@Addshore wrote:
> We can continue to generate constraint check data on the fly when missing
in GETs and simply not put it in the storage.
you could trigger a job in that
daniel added a comment.
> Any of the patches require a +1 from all of people who contributed to the
files otherwise will be legally in trouble (we can't just change license of a
file)
Note quite. It requires a +1 from a legal representative of the copyright
holder. The copyrigh
daniel added a comment.
In T138708#5017062 <https://phabricator.wikimedia.org/T138708#5017062>,
@jeblad wrote:
> Note that "click 'sign this' icon next to a statement" imply a
fundamentally insecure and broken process. You don't sign something after i
daniel added a comment.
In T198341#5019920 <https://phabricator.wikimedia.org/T198341#5019920>,
@BPirkle wrote:
> Question on one occurrence of these fields: is the maintenance script
fixT22757.php still relevant?
Looks like T22757 <https://phabricator.wikimedia.org
daniel added a comment.
In T218127#5020863 <https://phabricator.wikimedia.org/T218127#5020863>,
@Anomie wrote:
> In T218127#5020389 <https://phabricator.wikimedia.org/T218127#5020389>,
@Lucas_Werkmeister_WMDE wrote:
>
> > Then why are we even using the `Mes
daniel added a comment.
> includes/Revision/RevisionStore.php (I'll touch only getQueryInfo(). All
other references are either gated directly, or are in private functions with
all calls gated)
getQueryInfo() should have proper gating as well. If you think it does not,
le
daniel added a comment.
In T198341#5021347 <https://phabricator.wikimedia.org/T198341#5021347>,
@BPirkle wrote:
> rev_text_id references that will be removed/refactored in this task:
>
> - includes/Revision/RevisionStore.php (I'll touch only getQueryInfo(). All
daniel added a comment.
In T198341#5024626 <https://phabricator.wikimedia.org/T198341#5024626>,
@Anomie wrote:
> Here's one place where Daniel and I differ: I'd put most of these in one
patch instead of having 10+ single-file changes.
Ok, compromise: one patch
daniel edited projects, added Core Platform Team Kanban (Waiting for Review);
removed Core Platform Team Kanban (Doing).
TASK DETAIL
https://phabricator.wikimedia.org/T198706
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: ArielGlenn
daniel added a comment.
In T198341#5025722 <https://phabricator.wikimedia.org/T198341#5025722>,
@BPirkle wrote:
> Should compressOld.php and trackBlobs.php be in the same patch, as they
both suffer from the " processing multiple blobs per revision" problem?
daniel added a comment.
The patch in question should only chnange the behavior of *failing*
DataUpdates. If no DataUpdates fail, the new behavior should be exactly the
same as the old.
TASK DETAIL
https://phabricator.wikimedia.org/T218456
EMAIL PREFERENCES
https
daniel added a comment.
That raises the question why that job fails.
But it also raises the question how the new RefreshSecondaryDataUpdate could
have caused that. The intent behind the new code is to retry all updates that
failed during saving.
TASK DETAIL
https
daniel added a comment.
Is it possible that you are seeing something fail during the retry, but the
cause for the retry was something else?
TASK DETAIL
https://phabricator.wikimedia.org/T218456
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To
daniel added a comment.
In T218456#5033420 <https://phabricator.wikimedia.org/T218456#5033420>,
@Addshore wrote:
> @daniel I guess that is actually
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/466981/ for the retry
strategy? Which doesn't appear to be merged yet.
daniel added a comment.
Note that per the data model specification
<https://www.mediawiki.org/wiki/Wikibase/DataModel#Quantities>, the unit can be
any URI (or rather, any IRI):
> The unit specifies a physical quantity that the number refers to. It is
represented as a IRI rathe
daniel added a comment.
In T198341#502 <https://phabricator.wikimedia.org/T198341#502>,
@BPirkle wrote:
> To make sure I'm heading in the right direction:
>
> - Postgres currently uses columns in specific tables
(pagecontent.textvector and page.title
daniel added a comment.
In T198341#5046362 <https://phabricator.wikimedia.org/T198341#5046362>,
@Anomie wrote:
> Yes, we //could// do something like that. Probably we wouldn't even need to
change the triggers, just the SeachPostgres code to join
revision↔slots↔content↔
daniel added a comment.
In T198341#5049455 <https://phabricator.wikimedia.org/T198341#5049455>,
@Anomie wrote:
> In T198341#5046541 <https://phabricator.wikimedia.org/T198341#5046541>,
@daniel wrote:
>
> > And let's look into fixing postgres later. And b
daniel added a subtask: T218812: Provide the ability to have time-delayed or
time-offset jobs in the job queue.
TASK DETAIL
https://phabricator.wikimedia.org/T48643
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Addshore, Aklapper
daniel added a comment.
Looking at the code in the patch, it seems like the error is triggered when
a) an ID is known and b) the revision is found but c) no entity could be
loaded. Back then, this would have indicated a serious problem, like corrupt
serialization or some such.
With
daniel renamed this task from "Remove support for legacy pre-MCR schema" to
"Remove support for writing to the pre-MCR schema".
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T198557
EMAIL PREFERENCES
https://phabricator.wikimedi
daniel moved this task from Inbox to Under discussion on the TechCom-RFC board.
daniel added a subscriber: Krinkle.
daniel added a comment.
Moving to under discussion. @mobrovac and @Joe said they had further
questions. @Krinkle has some ideas as well.
TASK DETAIL
https
daniel added a comment.
@Krauss can you post the rest of the backtrace? As it is, I can't tell
whether it's the same problem or not.
TASK DETAIL
https://phabricator.wikimedia.org/T200072
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
daniel added a comment.
In T200072#5422925 <https://phabricator.wikimedia.org/T200072#5422925>,
@Krauss wrote:
> **Context**: It is a "closed" corporative Mediawiki (no way to use URL
here). I changed my LocalSettings.php adding some namespaces, editing, and
changi
daniel removed projects: Multi-Content-Revisions, Core Platform Team.
daniel added a comment.
> Maybe if we could tag such changes or select changes by slot, it would
solve the issue.
The problem with selecting changes by is that changes can affect multiple
slots. Not at the moment w
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T198492
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper, Anomie, Jdforrester-WMF, Tgr, daniel, darthmon_wmde, DannyS712,
Nandana, Lahi, Gq86
daniel added a parent task: T214308: Force usage of MCR aware database schema.
TASK DETAIL
https://phabricator.wikimedia.org/T200918
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper, aude, Addshore, Anomie, Jdforrester-WMF, Tgr
daniel added a subtask: T200918: Make sure code that accesses the text table or
uses rev_text_id triggers warnings before switching to write-new.
TASK DETAIL
https://phabricator.wikimedia.org/T214308
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To
daniel renamed this task from "MCR schema migration stage 3: drop support for
legacy fields (wmf production)" to "MCR schema migration stage 3: stop using
legacy fields".
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T183487
EMAIL
daniel renamed this task from "Make sure code that accesses the text table or
uses rev_text_id triggers warnings before switching to write-new" to "Make sure
code that accesses legacy pre-MCR fields triggers warnings before switching off
WRITE_OLD (compat) mode.".
daniel added a comment.
Quick fix for the error: just remove the check that triggers the error. Could
be converted to a warning, or just a debug message.
However, this doesn't solve the conceptual problem of breaking all existing
references to the old entity ID, internal and ext
daniel added a comment.
>> However, this doesn't solve the conceptual problem of breaking all
existing references to the old entity ID, internal and external.
>
> Agreed, but that' longer-term problem. Still high, but not user-facing, at
least to viewers.
I
daniel added a comment.
In T231276#5458596 <https://phabricator.wikimedia.org/T231276#5458596>, @Yann
wrote:
> The file is a big file (708.4 MB) from
https://archive.org/details/20190830_20190830_1349
> This may partly explain that (time out?).
That seems unlikely. Lo
daniel added a comment.
In T231276#5458915 <https://phabricator.wikimedia.org/T231276#5458915>,
@Cparle wrote:
> @Urbanecm the patch prevents the fatal error, but there are other errors
if, for example, a user tries to edit a caption.
The new "actual" ID needs to
daniel added a comment.
In T231276#5458962 <https://phabricator.wikimedia.org/T231276#5458962>,
@Cparle wrote:
>> The new "actual" ID needs to be forced into the Entity data, I commented
on the patch to that effect.
>
> On @Urbanecm 's patch
daniel added a comment.
@Ladsgroup any chance to fix the problematic tests in Wikibase?
I'd like to create a revert of the revert, but it should be blocked on the
patch that fixes the wikibase tests...
TASK DETAIL
https://phabricator.wikimedia.org/T231799
EMAIL PREFERENCES
daniel added a comment.
In T231799#5459077 <https://phabricator.wikimedia.org/T231799#5459077>,
@Lucas_Werkmeister_WMDE wrote:
> Are you sure that it’s the Wikibase tests that are problematic? The core
change could also be incomplete.
Could be. I was hoping someone on the
daniel added subscribers: Simetrical, Krinkle.
daniel added a comment.
pinging @Krinkle and @Simetrical for the original patch.
TASK DETAIL
https://phabricator.wikimedia.org/T231799
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
daniel added a comment.
In T198492#5469772 <https://phabricator.wikimedia.org/T198492#5469772>,
@Jdforrester-WMF wrote:
> Hey there, should this be moved to 1.35? The cut is a couple of weeks away?
If it needs to go out in 1.34, is there anything I can do to help get it out of
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T198492
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper, Anomie, Jdforrester-WMF, Tgr, daniel, darthmon_wmde, DannyS712,
Nandana, Lahi, Gq86
daniel renamed this task from "Drop rev_text_id and ar_text_id when running
update.php" to "Create a maintenance script to drop rev_text_id and ar_text_id
from the database.".
daniel edited projects, added MW-1.35-release; removed MW-1.34-release.
daniel updated the tas
daniel edited projects, added MW-1.35-release; removed MW-1.34-release.
daniel added a comment.
In T198557#5469771 <https://phabricator.wikimedia.org/T198557#5469771>,
@Jdforrester-WMF wrote:
> Hey there, should this be moved to 1.35? The cut is a couple of weeks away?
If it ne
daniel added a project: MW-1.34-release.
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T214308
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: WDoranWMF, kchapman, Aklapper, CCicalese_WMF, Fjalapeno
daniel renamed this task from "Remove support for writing to the pre-MCR
schema" to "Remove the ability to write pre-MCR fields, limit the ability to
read pre-MCR fields to migration scripts".
TASK DETAIL
https://phabricator.wikimedia.org/T198557
EMAIL
daniel added a comment.
My rationale for suppressing the undo link when direct editing is disabled
was that action=edit is for direct editing.
But Wikibase overrides the action handle specifically for undos, right? I
recall working on that code...
That's what I get for lumping
daniel added a comment.
In T198492#5471347 <https://phabricator.wikimedia.org/T198492#5471347>,
@Anomie wrote:
> update.php is the standard mechanism for schema changes, and I don't think
we ever have any other maintenance scripts perform actual schema changes. I
don
daniel added a comment.
In T198492#5481746 <https://phabricator.wikimedia.org/T198492#5481746>,
@tstarling wrote:
> No, it was never true. update.php has been used to drop fields since MW
1.5, 14 years ago, but there was no backlog of undropped fields at that time.
updat
daniel removed a project: Wikidata.
daniel added a comment.
In T214308#5499106 <https://phabricator.wikimedia.org/T214308#5499106>,
@Lucas_Werkmeister_WMDE wrote:
> Why is this tagged #Wikidata
<https://phabricator.wikimedia.org/tag/wikidata/>? Is Wikibase incompatibl
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T200918
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper, aude, Addshore, Anomie, Jdforrester-WMF, Tgr, gerritbot, daniel,
darthmon_wmde, DannyS712
daniel added a comment.
The link cache is for the title -> id lookup. Seems to me like you need the
opposite here. The batch interface would be Title::newFromIDs (note the
plural), but that does no caching.
Is there a concrete ask for the CPT team here?
TASK DETAIL
ht
daniel added a comment.
In T230862#5503781 <https://phabricator.wikimedia.org/T230862#5503781>,
@Cparle wrote:
> So say we add a 'structured-data-mediainfo' tag to every revision that has
a `mediainfo` slot - would that be adequate? @EBernhardson ?
I assume th
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T198341
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: holger.knust, daniel
Cc: BPirkle, tstarling, gerritbot, Tgr, Jdforrester-WMF, Anomie, aude,
Aklapper, daniel
daniel added a subtask: T233350: ActiveAbstract: remove dependency on pre-MCR
database schema.
TASK DETAIL
https://phabricator.wikimedia.org/T198343
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Pchelolo, Clarakosi, ArielGlenn, Aklapper
daniel removed a subtask: T233350: ActiveAbstract: remove dependency on pre-MCR
database schema.
TASK DETAIL
https://phabricator.wikimedia.org/T198341
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: holger.knust, daniel
Cc: BPirkle, tstarling
daniel created this task.
daniel added projects: Multi-Content-Revisions (Tech Debt), CPT Initiatives
(MCR Schema Migration), Core Platform Team Workboards (Purple), Shape
Expressions, Wikidata.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
The extension should not
daniel added a subtask: T233356: Flow: remove dependency on pre-MCR database
schema.
TASK DETAIL
https://phabricator.wikimedia.org/T198342
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Daimona, Nikerabbit, BPirkle, Aklapper, aude
daniel added a subtask: T233357: ReplaceText: remove dependency on pre-MCR
database schema.
TASK DETAIL
https://phabricator.wikimedia.org/T198342
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Daimona, Nikerabbit, BPirkle, Aklapper, aude
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T198341
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: holger.knust, daniel
Cc: BPirkle, tstarling, gerritbot, Tgr, Jdforrester-WMF, Anomie, aude,
Aklapper, daniel
daniel removed daniel as the assignee of this task.
TASK DETAIL
https://phabricator.wikimedia.org/T198343
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Pchelolo, Clarakosi, ArielGlenn, Aklapper, aude, Anomie, Jdforrester-WMF,
Tgr
daniel removed holger.knust as the assignee of this task.
daniel added a subscriber: holger.knust.
TASK DETAIL
https://phabricator.wikimedia.org/T198341
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: holger.knust, BPirkle, tstarling
daniel closed subtask T233350: ActiveAbstract: remove dependency on pre-MCR
database schema as "Resolved".
TASK DETAIL
https://phabricator.wikimedia.org/T198343
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Pchelolo,
daniel closed subtask T233355: WikimediaMaintenance: remove dependency on
pre-MCR database schema as "Resolved".
TASK DETAIL
https://phabricator.wikimedia.org/T198341
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: holger.knus
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T200918
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper, aude, Addshore, Anomie, Jdforrester-WMF, Tgr, gerritbot, daniel,
darthmon_wmde, DannyS712
daniel edited projects, added Core Platform Team Workboards (Clinic Duty Team);
removed Core Platform Team Workboards (Purple).
daniel raised the priority of this task from "Normal" to "High".
daniel added a comment.
Bumping to high, because this blocks 1.34
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T198343
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Pchelolo, Clarakosi, ArielGlenn, Aklapper, aude, Anomie, Jdforrester-WMF,
Tgr, gerritbot, daniel
daniel added a comment.
Remaining review: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/539607
TASK DETAIL
https://phabricator.wikimedia.org/T198343
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Pchelolo, Clarakosi, ArielGlenn
daniel edited projects, added Core Platform Team Workboards (Clinic Duty Team);
removed Core Platform Team Workboards (Purple).
TASK DETAIL
https://phabricator.wikimedia.org/T200918
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper
daniel raised the priority of this task from "Normal" to "High".
daniel moved this task from Inbox to Waiting for Review on the Core Platform
Team Workboards (Clinic Duty Team) board.
daniel added a comment.
bumping to high, since this blocks 1.34
daniel added a project: MW-1.34-release.
TASK DETAIL
https://phabricator.wikimedia.org/T200918
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper, aude, Addshore, Anomie, Jdforrester-WMF, Tgr, gerritbot, daniel,
Hook696, Daryl-TTMG
daniel added a comment.
Blocked on T228675 <https://phabricator.wikimedia.org/T228675> which needs
review from the #language-team
<https://phabricator.wikimedia.org/tag/language-team/>.
TASK DETAIL
https://phabricator.wikimedia.org/T198343
EMAIL PREFERE
daniel added a project: MW-1.34-release.
TASK DETAIL
https://phabricator.wikimedia.org/T198343
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Pchelolo, Clarakosi, ArielGlenn, Aklapper, aude, Anomie, Jdforrester-WMF,
Tgr, gerritbot
daniel updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T200918
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper, aude, Addshore, Anomie, Jdforrester-WMF, Tgr, gerritbot, daniel,
Hook696, Daryl-TTMG
daniel lowered the priority of this task from "High" to "Normal".
TASK DETAIL
https://phabricator.wikimedia.org/T200918
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Aklapper, aude, Addshore, Anomie, Jdforrester
daniel added a comment.
I recall that we had long discussions about this when initially deciding on
the data model. In technical terms, the question was whether we would allow
only a single literal value for a spelling variant, or a list or set of words.
Allowing a list or set would enable
daniel closed this task as "Resolved".
daniel claimed this task.
daniel added a comment.
All subtasks are resolved. I just went over the remaining open patches for
this task and abandoned a few obsolete ones. There are only two patches
remaining open, one for the Duplicator extensi
daniel added a comment.
In T199121#5683594 <https://phabricator.wikimedia.org/T199121#5683594>,
@ArielGlenn wrote:
> In T199121#5682911 <https://phabricator.wikimedia.org/T199121#5682911>,
@Nuria wrote:
>
>> I see this ticket is resolved but the dumps
daniel added a comment.
In T199121#5684250 <https://phabricator.wikimedia.org/T199121#5684250>,
@ArielGlenn wrote:
> In T199121#5684237 <https://phabricator.wikimedia.org/T199121#5684237>,
@daniel wrote:
>
>> In T199121#5683594 <https://phabricator.wi
daniel added a comment.
In T199121#5684558 <https://phabricator.wikimedia.org/T199121#5684558>,
@ArielGlenn wrote:
> As usual no one has given anyone any decision making powers so I'll claim
it :-P I should make a task, announce it on the mailing lists, give a 2 mont
daniel created this task.
daniel added projects: Wikidata, Structured Data Engineering,
Multi-Content-Revisions (New Features), CPT Initiatives (MCR),
Structured-Data-Backlog, Core Platform Team.
TASK DESCRIPTION
TextPassDumper does a streaming read of an XML document and at the same time
daniel reopened this task as "Open".
daniel added a comment.
Re-opening due to T238959 <https://phabricator.wikimedia.org/T238959>
TASK DETAIL
https://phabricator.wikimedia.org/T174031
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
daniel added a comment.
@CCicalese_WMF I overlooks this. We use this mode in production, but nothing
else does. The tests for this class use the default schema, so they'll pass as
long as the default is 0.10. This is unfortunate, since it means that support
for the 0.11 schema outp
201 - 300 of 5375 matches
Mail list logo
