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
Hi Lydia,
> No, they are created independently.
Yes somebody also told me these files are created by Wikibase from the
database. I also posted this question in (sorry for the cross posting):
https://mstdn.degu.cl/@daniel/111957447287243556
> I'd be interested in hearing more about wh
Hi all,
I wonder if the Wikidata RDF dump (in
https://dumps.wikimedia.org/wikidatawiki/entities/) is generated directly from
the JSON dump.
If this is the case, what tool used?
Best Regards,
Daniel
___
Wikidata-tech mailing list -- wikidata-tech
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
So I just tried that on Factgrid's Sandox item
https://database.factgrid.de/wiki/Item:Q24
with
Q24[TAB]Swikidatawiki[TAB]""
and various variants thereof but this did not result in any edits.
Perhaps someone else here knows how to do that?
Cheers,
Daniel
On Fri, Mar 31, 2023 at 4:42 P
of these provide for fertile ground to engage relevant
communities, and It would be very helpful to have similar
visualizations (e.g. change as a function of some parameter) for any
part of Wikidata, including but not limited to geodata.
Best,
Daniel
On Sat, Dec 17, 2022 at 10:57 PM Tassos Noulas
with filters per season or club.
Is anyone here thinking in such directions?
Another request would be to have parametrized URLs based on QID and
perhaps type or language, e.g.
http://www.wiki-atlas.org/English/museums/Q7877613 or some such.
Best,
Daniel
On Sat, Dec 17, 2022 at 2:36 AM Aidan Hogan wrote
are closer to my way of
celebrating.
Cheers,
Daniel
On Mon, Sep 12, 2022 at 9:38 AM Léa Lacroix
wrote:
> Hello all,
> As a reminder, we would love to receive more contributions to Wikidata's
> 10th birthday collaborative video!
> The deadline is on Sunday, September 18th, and you wi
On Sat, Jun 18, 2022 at 2:54 AM Samuel Klein wrote:
> Is there any sort of list of mothballed bots looking for good homes /
> maintainers?
I think basically every bot in the list would benefit from (more) maintainers:
IRC bots:
https://wikitech.wikimedia.org/wiki/Category:Bots
on wiki bots:
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
connected in some way but no luck there
yet.
Best,
Daniel
On Wed, Jan 26, 2022 at 6:12 PM Olaf Simons
wrote:
> Hi Haddad,
>
> I remain puzzled by the railway network - this is too bright for me. This
> search produces a person, and a series of events in chronological sequen
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
?
More details via
https://github.com/WDscholia/scholia/issues/1640#issuecomment-908575849
Thanks for any pointers,
Daniel
___
Wikidata mailing list -- wikidata@lists.wikimedia.org
To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
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
Hi all,
the newest version of the LOD cloud is just a week old,[1] but the
underlying information for Wikidata is out of date by several years.[2]
Has anyone looked into streamlining the data submission process?
Best,
Daniel
[1] https://lod-cloud.net/
[2] https://lod-cloud.net/dataset
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
1 - 100 of 5670 matches
Mail list logo