[02:27:27] if it's a lot of writes, then I'd swap it [02:51:39] It potentially is [02:51:57] well, 10k captchas takes a long time [02:52:04] And is only gonna get worse with daily runs... and delete on solve etc [02:52:20] Will do it later :) [17:00:36] anomie: running a bit late. should be there in 2-3 minutes [17:00:42] ok [19:52:51] AaronSchulz: could I get you to take a look at beta? Started seeing atal error: Call to undefined method __PHP_Incomplete_Class::hasReached() in /srv/mediawiki/php-master/includes/libs/rdbms/loadbalancer/LoadBalancer.php on line 494 errors right after https://gerrit.wikimedia.org/r/#/c/336578/3 went out [19:55:09] AaronSchulz: https://logstash-beta.wmflabs.org/goto/c6a6a3654fc213f87d72075df4111d8e [19:57:09] ok [19:59:09] thcipriani: is it still there? Looks like a an issue with the old class in APC [20:00:24] AaronSchulz: hrm, still seeing the error come up [20:01:21] editing in beta still not working :\ [20:01:23] thcipriani: https://gerrit.wikimedia.org/r/#/c/337073/1 in any case [20:03:03] works for me [20:23:54] AaronSchulz: patch just deployed to beta, editing works again -- thanks for the quick fix :) [22:30:03] dr0ptp4kt: if you have any immediate questions re watchlist tagging feel free to ask me here :) [22:31:25] hi addshore ! you're not sleeping? [22:31:34] not yet ;) [22:31:49] having a late night working! (also I'm 1 hour behind Berlin) [22:42:40] aha. ok, so for this tagged watchlist thing, how does it work? [22:43:23] addshore ^ the thing we're talking about is whether this tagged watchlist thing might work properly as a storage mechanism for reading lists. got the wikipedia for android app? you'd see in there what the reading lists look like. [22:44:42] I do have the app *loads it* [22:44:46] people have rightly noted that watchlists and private reading lists serve different purposes. which is true. but if the storage abstraction is generic enough, i sort of wonder if it would be possible for the user managing her reading lists inside the wikipedia for android app to just use tagged watchlists transparently [22:46:12] So I kind of feel that the multiple watchlists direction would fit this better [22:46:44] that's *multiple* watchlists instead of *tagged* watchlists, right? [22:47:00] I'm pretty sure there is some discussion in that IRC log that I linked in the email re multiple watchlists too [22:47:32] * dr0ptp4kt looking at email [22:47:48] so, one direction is 1 watchlist, and items on the watchlist can have tags, eg. 'to-read' or 'user-warning' etc... [22:48:26] another is multiple watchlists, you can have a main watchlist, but another watchlist nammed 'to-read' or 'user-warnings' or something similar [22:48:32] For those specific use cases both work [22:49:12] I mean, there is also no real reason they couldn't happen simultaneously,a nd have multiple watchlists that have taggable items.... [22:50:11] And then there was also some discussion somewhere talking about multiple lists, but not necessarily watchlists, so removing the watchlist specific stuff [22:50:39] loads of discussion, but no real direction ;) and any movement has really been blocked (on the thing linked in the email) :) [22:54:14] i see. ok, so one other option you may recall from a different rfc discussion is use of a key-value storage mechanism that is authenticated on a per-user basis. that can achieve something similar, although it has the same requirement that the schema that different clients would use has to be consistent if it's to be cross platform. [22:55:07] ooh, I don't recall that rfc discussion! (might have missed it) [22:55:51] So TCB / WMDEs work on watchlists has been mainly refactoring so far [22:55:53] with the watchlist you have nice things like db triggers and jobs that can keep things up to date. of course the challenge on the client is you might have to react to that, which is a challenge. but with key-value, you might have to intentionally deal with things like redirects or other changes, which is a different challenge. [22:56:04] i'll see if i can find that rfc [22:57:15] addshore: it's this one: https://phabricator.wikimedia.org/E237 [22:57:21] and moving forward I essentially see WMDEs work there to be focused around making watchlists easier to manage & cleanup (and potentially revisiting either automatically expiring watchlist items) [22:57:33] * addshore gives it a quick read [22:59:41] So the comment at https://phabricator.wikimedia.org/E237#2836 is kind of how I would see multiple watchlists / lists working [23:03:37] addshore: right. i think the one place where that doesn't seem to cover things right now is the extended attributes. dbrant noted "21:08:13 Marybelle: this is a sort of generalization of watchlists, where the user can have multiple lists, each with its own attributes (name, description, whether it's saved for offline reading, etc)" - those extended [23:03:37] attributes on a list item would need to be encoded somewhere, probably a table of fk-to-attribute mapping or something like that. [23:04:11] dbrant noted there that a list can have attributes. but as i understand, that possibly also extends into specific items within a list [23:04:18] I'm pretty sure that has vaugly been discussed for watchlists somewhere too ;) gimmie 2 secs [23:04:21] (imagine if an item in a list is sync'd offline) [23:05:37] dr0ptp4kt: see https://phabricator.wikimedia.org/T124752#2235247 for a generic list / watchlist props table [23:06:26] It's discussed there in terms of using it for tags [23:06:51] but that could potentially be a bad idea due to db indexes etc... [23:07:34] Covering everything above, there would be 1) a list table 2) a list item table 3) a list item property table 4) a list item tag table? xD [23:08:13] *sigh* [23:08:15] so man different people want so many different things for watchlists the direction is really very unclear [23:09:02] * addshore hands DanielK_WMDE a coffee, although given the time you may not want to drink that... [23:09:48] i just might, there's a party i'm supposed to go to in a bit :D [23:10:04] lol. can they store shasum's of diffs, too? ;) [23:11:04] ok...i'm gonna head home...to be continued, perhaps in a meeting. perhaps simpler is a purpose built k-v :) [23:11:12] dr0ptp4kt: I dont see why not, I mean, the property table covers that nice and generically, given you dont want to query by the shasum (so long as this is a shasum for an item and not a list) ;) [23:11:36] dr0ptp4kt: have a good day / night! :) [23:11:48] addshore: DanielK_WMDE 'night guys