Jump to content

Architecture meetings/RFC review 2014-04-09

From mediawiki.org

22:00 UTC, April 9th, at #wikimedia-office connect. This 50-minute meeting covered brief "what's the next step?" updates regarding several RfCs.

Requests for Comment to review

[edit]
  1. Requests for comment/UserMailer refactor
  2. Requests for comment/Nonlinear versioning
  3. Requests for comment/AuthStack
  4. Requests for comment/Abstract table definitions
  5. Requests for comment/Support for user-specific page lists in core

Summary and logs

[edit]

Meeting summary

[edit]
  • LINK: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-09 (sumanah, 22:00:38)
  • Today is a 40-minute meeting (sumanah, 22:00:43)
  • we're asking "is this still valid? what are next steps?" on UserMailer refactor, Nonlinear versioning, Authstack, Abstract table definitions, & support for user-specific page lists in core (sumanah, 22:00:43)
  • UserMailer refactor (sumanah, 22:01:20)
    • LINK: https://www.mediawiki.org/wiki/Requests_for_comment/UserMailer_refactor by Owen Davis (sumanah, 22:01:25)
    • Owen Davis last updated this in late 2013 and hasn't gotten any feedback. (sumanah, 22:01:35)
    • Any objection to moving forward? (sumanah, 22:01:35)
    • <brion> my main question about the usermailer refactor is whether the echo stuff duplicates/changes the email landscape (sumanah, 22:02:01)
    • <awight> I think it's a bad idea to pass the desired mailer class via the send() method. (sumanah, 22:02:20)
    • seems to be some agreement that using SwiftMailer as backend would resolve this better (brion, 22:06:32)
    • ACTION: brion to summarise this discussion on RfC talk page (re user mailer) (sumanah, 22:07:29)
  • Authstack (sumanah, 22:07:45)
    • LINK: https://www.mediawiki.org/wiki/Requests_for_comment/AuthStack (sumanah, 22:07:49)
    • Tyler updated this earlier this year. He responded to a request and "reduced the scope of the RFC by removing the Permissions infrastructure and the ClientSession class." So we could use a fresh opinion. (sumanah, 22:07:55)
    • some agreement to changing ExternalUser to ExternalAuthUser for clarity and to avoid potential conflict (brion, 22:14:53)
    • a few people like the idea in general (sumanah, 22:16:50)
    • people seem to like the general idea — likely to proceed? (brion, 22:16:52)
    • Everyone believes it's generally a good idea (MaxSem, 22:16:54)
    • <parent5446> Once I finish up the Password patch I'll start working on AuthStack code (sumanah, 22:17:06)
  • support for user-specific page lists in core (sumanah, 22:25:21)
    • LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Support_for_user-specific_page_lists_in_core (sumanah, 22:25:34)
    • Ori and Steven last updated this in September 2013. When we discussed it then, we agreed "to expand this RFC somewhat" and that "no one dislikes the basic idea, but ... it's large enough that it's hard to sign off on it completely without further work" (sumanah, 22:25:42)
    • TimStarling said "I will add some comments about the potential need to abstract the backend" (sumanah, 22:26:20)
    • Adam Wight relates: "this work is probably getting rolled into an EducationProgram rewrite" (sumanah, 22:26:30)
    • ACTION: TimStarling it would be nice if you could add a note to the user specific page lists in core RfC talkpage about abstracting the backend (sumanah, 22:32:40)
    • ACTION: someone should consult AaronSchulz and anomie re how to fix the externallinks issue (sumanah, 22:33:52)
  • Nonlinear versioning (sumanah, 22:36:51)
    • LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Nonlinear_versioning (sumanah, 22:36:56)
    • Adam Wight last updated this in August 2013. This feels super experimental so I don't know whether any next actions are necessary; should we encourage Adam to prototype this? (sumanah, 22:37:01)
    • LINK: https://meta.wikimedia.org/wiki/Grants:IdeaLab/Edit_your_replica human-language RfC (sumanah, 22:37:29)
    • ACTION: awight http://opensourcebridge.org/blog/2014/03/submit-your-2014-proposals-today/ ;-) (I bet people would come to your talk) (sumanah, 22:42:27)
    • <TimStarling> you know that we are considering redesigning the revision system along SOA lines (sumanah, 22:44:42)
    • this might be better for non-Wikimedia wikis, or for use by massively multiplayer editing on fast-breaking news topics (sumanah, 22:45:14)
    • Tim's questions: 1) do we want it? 2) how much hardware are we willing to buy to get it? 3) how do you make efficient use of that extra hardware? what schema, what server, etc.? (sumanah, 22:45:37)
    • performance, how to alter the DB schema, what does the current schema support (sumanah, 22:46:29)
    • ACTION: awight to keep investigating this, move motivations from Idealab page onto RfC, compare his idea to to other ways of implementing a draft feature, try to answer Tim's questions 2 & 3, and look for potential users (maybe 3rd party wikis) (sumanah, 22:56:35)


Meeting ended at 22:56:54 UTC.


Action items

[edit]
  • brion to summarise this discussion on RfC talk page (re user mailer)
  • sumanah to point Daniel Friesen to log
  • TimStarling it would be nice if you could add a note to the user specific page lists in core RfC talkpage about abstracting the backend
  • someone should consult AaronSchulz and anomie re how to fix the externallinks issue
  • awight http://opensourcebridge.org/blog/2014/03/submit-your-2014-proposals-today/ ;-) (I bet people would come to your talk)
  • awight to keep investigating this, move motivations from Idealab page onto RfC, compare his idea to to other ways of implementing a draft feature, try to answer Tim's questions 2 & 3, and look for potential users (maybe 3rd party wikis)


Action items, by person

[edit]
  • awight
  • brion
    • brion to summarise this discussion on RfC talk page (re user mailer)
  • sumanah
    • sumanah to point Daniel Friesen to log
  • TimStarling
    • TimStarling it would be nice if you could add a note to the user specific page lists in core RfC talkpage about abstracting the backend


Full log

[edit]

See in HTML or see below.

Meeting logs


22:00:21 <sumanah> #startmeeting RfC review ("what next?") | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours
22:00:21 <wm-labs-meetbot> Meeting started Wed Apr  9 22:00:21 2014 UTC and is due to finish in 60 minutes.  The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:21 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:21 <wm-labs-meetbot> The meeting name has been set to 'rfc_review___what_next______channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours'
22:00:28 <sumanah> #chair sumanah brion TimStarling
22:00:28 <wm-labs-meetbot> Current chairs: TimStarling brion sumanah
22:00:38 <sumanah> #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-09
22:00:41 <brion> \o/
22:00:43 <sumanah> #info Today is a 40-minute meeting
22:00:43 <sumanah> #info we're asking "is this still valid? what are next steps?" on UserMailer refactor, Nonlinear versioning, Authstack, Abstract table definitions, & support for user-specific page lists in core
22:01:12 <sumanah> #chair sumanah brion TimStarling mark
22:01:12 <wm-labs-meetbot> Current chairs: TimStarling brion mark sumanah
22:01:20 <sumanah> #topic UserMailer refactor
22:01:25 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/UserMailer_refactor by Owen Davis
22:01:35 <sumanah> #info Owen Davis last updated this in late 2013 and hasn't gotten any feedback.
22:01:35 <sumanah> #info Any objection to moving forward?
22:01:51 <brion> my main question about the usermailer refactor is whether the echo stuff duplicates/changes the email landscape
22:01:57 <sumanah> (it's such a short RfC, either it's simple or the RfC is too short)
22:02:01 <sumanah> #info <brion> my main question about the usermailer refactor is whether the echo stuff duplicates/changes the email landscape
22:02:12 <awight> I think it's a bad idea to pass the desired mailer class via the send() method.
22:02:20 <sumanah> #info <awight> I think it's a bad idea to pass the desired mailer class via the send() method.
22:02:28 <awight> abstracting the mailer is a great idea, however.
22:02:41 <MaxSem> I don't like the growing number of parameters to the static function, it's scary enough already
22:02:44 * awight reads http://wiki.debian.org/MeetBot.
22:02:46 <MaxSem> use OOP?
22:03:11 <sumanah> (these seem like things we ought to mention to Owen on the talkpage; I encourage anyone talking now to expand on their thoughts at https://www.mediawiki.org/wiki/Talk:Requests_for_comment/UserMailer_refactor )
22:03:30 <awight> agreed
22:03:31 <sumanah> (if they have any expansion on their thoughts)
22:03:36 <ebernhardson> personally, i find it really odd to even consider a mailer refactor before looking at the underlying mail system (such as Swift_Mailer mentioned in see also)
22:03:41 <MaxSem> and where's their code?
22:04:05 <sumanah> good question
22:04:05 <brion> yeah, it’s a bit light
22:04:36 <sumanah> parent5446: the end of http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140409.txt for the chat till now :)
22:04:36 <brion> now it seems the point of the rfc is ‘make it easier to merge the wikia changes’
22:04:45 <parent5446> sumanah: thanks
22:04:51 <brion> if that’s mostly ‘we have an extra class and adding these params makes it trivial to plug in’ then that’s probably spiffy
22:04:59 <MaxSem> I think this RFC should be declined
22:05:05 <ebernhardson> i agree
22:05:24 <brion> needs moar code
22:05:34 <MaxSem> a solution would be a class with eg function addAttachment(), not a huge parameter list
22:05:48 <ebernhardson> and those solutions already exist, we should just be chosing one
22:06:00 <parent5446> Keep in mind we have a GSoC project working on using SwiftMailer in core
22:06:13 <parent5446> That would fulfill most of the goals of this RFC
22:06:32 <brion> #info seems to be some agreement that using SwiftMailer as backend would resolve this better
22:06:39 <sumanah> so it sounds like someone should summarise this for the RfC talk page, or possibly we should just decline this
22:07:15 <brion> i’ll add a quick note
22:07:29 <sumanah> #action brion to summarise this discussion on RfC talk page (re user mailer)
22:07:39 <sumanah> OK, let's move on to AuthStack
22:07:45 <sumanah> #topic Authstack
22:07:49 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/AuthStack
22:07:55 <sumanah> #info Tyler updated this earlier this year. He responded to a request and "reduced the scope of the RFC by removing the Permissions infrastructure and the ClientSession class." So we could use a fresh opinion.
22:08:00 <sumanah> (parent5446 that is)
22:08:50 <brion> oh authn/z…. what a fun world :D
22:09:09 <sumanah> csteipp: you probably have opinions ^
22:09:17 <parent5446> Yeah, so the goal of this is to get rid of the ChainedAuth hook in LdapAuthentication
22:09:29 <parent5446> B/c it's basically a hack to allow more than one authnz method
22:09:55 <sumanah> (while I wait for other people to respond: I am writing to you from a hallway at PyCon, the Python convention. It is in Montreal, so I have unearthed the French I learned 15 years ago. Je voudrais acheter un bilet!)
22:10:06 <csteipp> I really do like the concept in general. The ldap especially makes a compelling use case.
22:10:30 <parent5446> It also tries to adopt the whole service-oriented architecture theme we have going
22:11:26 <brion> i’ll defer to those who have been poking at auth code more recently on this one, but it sounds good in theory
22:11:40 <brion> old AuthPlugin was a bit hacky and was done without benefit of experience in using said plugins  :D
22:12:07 <brion> any implications for LDAP, CentralAuth, etc?
22:12:10 <parent5446> I do need feedback on one thing. Is it OK to use ExternalUser as a class name? Because it is the same class name as the recently removed ExternalUser experiment.
22:12:25 * brion whispers “namespaces!”
22:12:47 <parent5446> Lol, I can put this stuff in a namespace if we support putting core classes in namespaces
22:13:34 <brion> parent5446: worst case we can change the class name i guess :)
22:13:35 <csteipp> Was there an "ExternalUser experiment"? I missed that. The name sounds ok to me, but "ExternalAuthUser" would be fine too
22:13:49 <brion> actually i’d kinda prefer ExternalAuthUser, that’s more descriptive
22:13:55 <parent5446> Yeah, I think it was removed in a previous version. I don't think anybody ever used it
22:14:13 <sumanah> peut-etre Tim pense un quelque chose ici <----- (terrible high school French for "maybe TimStarling thinks something here")
22:14:22 <parent5446> I'd support ExternalAuthUser as well.
22:14:44 <sumanah> (since he was the one to comment in July)
22:14:51 <csteipp> Definitely look into the bug that we have open about initializing users using session setup... just to avoid the situation we're currently in
22:14:53 <brion> #info some agreement to changing ExternalUser to ExternalAuthUser for clarity and to avoid potential conflict
22:15:46 * sumanah waits another minute for Tim to speak up before we move on to Abstract table definitions (which should be quick)
22:16:03 <brion> :)
22:16:16 <sumanah> hmm, anything else to #info here?
22:16:50 <sumanah> #info a few people like the idea in general
22:16:51 <parent5446> Once I finish up the Password patch I'll start working on AuthStack code
22:16:52 <brion> #info people seem to like the general idea — likely to proceed?
22:16:54 <MaxSem> #info Everyone believes it's generally a good idea
22:16:58 <brion> :D
22:17:06 <sumanah> #info <parent5446> Once I finish up the Password patch I'll start working on AuthStack code
22:17:16 <sumanah> All right
22:17:17 <sumanah> #topic Abstract table definitions
22:17:20 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Abstract_table_definitions
22:17:24 <sumanah> #info This should be quick. I'm assuming the comment from Tim, "Seek comment on DSL details." from late July 2013, still holds. I don't think this one needs any discussion, I just wanted to give people a heads-up that it exists, in case anyone wants to collaborate with Daniel Friesen on it.
22:17:40 <MaxSem> okay, my opinion about it was requested and I'm sceptic
22:17:55 <sumanah> "... this is a proposal for an abstract language for defining tables, indexes, alters, etc... that; Can be sanely written and read. Is not raw sql (we'll probably PEG parse it) and can be used to build the database for any database engine we support. And can be used by extensions too to define their database pieces abstractly so the extension will work in other databases."
22:18:14 <csteipp> parent5446: bug 41201
22:18:25 <MaxSem> what's abstract in proposed "table hitcounter {
22:18:25 <MaxSem> @ENGINE(HEAP)
22:18:25 <MaxSem> @MAX_ROWS(25000)
22:18:25 <MaxSem> hc_id uint
22:18:25 <MaxSem> }" ?
22:18:37 <awight> I think it's much cleaner to use a basic SQL syntax and transform that to make use of extensions when possible.  But parsing is a pain.
22:18:42 <MaxSem> it's just MySQL-specific DDL in a different wrap
22:18:51 <parent5446> csteipp: Thanks. That's for the the ClientSession part
22:19:14 <brion> so the last time i tried something like this was for StatusNet
22:19:23 <brion> using structured arrays rather than a DSL so no parsing ;)
22:19:35 <awight> Yeah, Drupal uses that approach.  It's pretty heinous...
22:19:37 <brion> but i also tried to be clever about auto-applying schema updates, and that was hell
22:19:48 <MaxSem> I guess StatusNet didn't need to support holy Oracle?
22:19:50 <brion> explicit updates are probably better
22:19:53 <saper> we are close to getting structural arrays in DatabaseUpdaters
22:20:03 <brion> no, oracle could take a flying &$^# for all we cared ;)
22:20:11 <MaxSem> ...together with SQL server and a bunch of FLOSS DBs
22:20:13 <sumanah> ok, so I was wrong and this does inspire discussion :-)
22:20:21 <parent5446> Has anybody looked at Doctrine DBAL's schema generator?
22:20:41 <sumanah> #info skepticism.
22:20:41 <MaxSem> NO FRAMEWORKS IN CORE!!1 :P
22:20:45 <brion> nope, got a link handy?
22:20:49 <parent5446> It's not the same as this RFC, but provides some of the same deliverables
22:20:52 <parent5446> http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/schema-representation.html
22:21:07 <awight> Hehe.  we'll probably need a code generation step in core anyway
22:21:21 * brion kind of hews to the idea that mysql *is* a database abstraction layer…. from SQL to myisam/innodb/etc ;)
22:21:44 <sumanah> Since Daniel isn't here, I feel like I should just point him to this log and ask whether he has any responses
22:21:52 <MaxSem> can we just ditch myisam support?
22:22:14 <brion> people keep wanting postgres and sometimes oracle and mssql, so it seems like there’d be interest in having consistent support, but without the abstraction nobody maintains them
22:22:14 <sumanah> #action sumanah to point Daniel Friesen to log
22:22:39 <saper> MaxSem: do we support myisam at all?
22:22:50 <MaxSem> last time i checked
22:23:04 <brion> parent5446: looks mostly code-based, gets pretty verbose?
22:23:06 <sumanah> anyone in the WMF SF office? can you see whether Steven Walling &/or Ori Livneh are around? because we're about to move on to their RfC
22:23:25 <awight> swalling isn't here
22:24:06 <parent5446> Yeah it's mostly code-based
22:24:27 <parent5446> But it's a lot easier to integrate than inventing our own SQL replacement
22:24:33 <brion> my main worry there is verbosity kills maintenance
22:24:37 <brion> true :D
22:24:42 <awight> re: doctrine, isn't there a pure YAML schema syntax?
22:24:44 <sumanah> I'm about to change topic - if people wanna keep talking about the wonderful world of SQL, ORMs, etc., take it to #wikimedia-dev ? :)
22:24:45 <brion> scary DSLs also kill maintenance ;)
22:24:52 <brion> ok i’m done :)
22:25:06 <parent5446> http://doctrine-orm.readthedocs.org/en/latest/reference/yaml-mapping.html
22:25:12 <saper> I'd love we had record locking under control instead... every second SELECT has now FOR UPDATE or so :(
22:25:21 <sumanah> #topic support for user-specific page lists in core
22:25:33 <sumanah> This is Ori & Steven's RfC.
22:25:34 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Support_for_user-specific_page_lists_in_core
22:25:42 <sumanah> #info Ori and Steven last updated this in September 2013. When we discussed it then, we agreed "to expand this RFC somewhat" and that "no one dislikes the basic idea, but ... it's large enough that it's hard to sign off on it completely without further work"
22:26:18 <awight> fwiw, this work is probably getting rolled into an EducationProgram rewrite
22:26:20 <sumanah> #info TimStarling said "I will add some comments about the potential need to abstract the backend"
22:26:30 <sumanah> #info Adam Wight relates: "this work is probably getting rolled into an EducationProgram rewrite"
22:26:36 <sumanah> awight: around whennish?
22:27:06 <awight> sumanah: I don't know if that's on the roadmap yet, currently the work is focused on generalizing Campaigns
22:27:24 <sumanah> AaronSchulz: perhaps you can speak on behalf of your performancey colleague ;-)
22:27:29 <awight> But the big picture is that StevenW wants to add functionality like the user page lists as components.
22:28:37 <brion> i like the basic idea; there’s some open question about how tags would be managed though
22:29:07 <sumanah> looks like we won't have ori or StevenW in this chat today. That's ok
22:29:08 <brion> …and someone might have to take a flamethrower to some existing watchlist code to clean it up
22:31:22 <sumanah> awight: do you need Tim to follow up on making comments re abstracting the backend?
22:31:41 <AaronSchulz> brion: it could work, though it inherits all the sorting problems watchlists have now
22:31:48 <AaronSchulz> though brad already mentioned that it seems
22:31:51 <brion> *nod*
22:31:57 <awight> sumanah: I'm pretty far from that work, but mentioning the complications would be a good idea.
22:32:13 <AaronSchulz> reminds, we figured out a fix for the externallinks thing he mentioned...someone should do that :)
22:32:40 <sumanah> #action TimStarling it would be nice if you could add a note to the user specific page lists in core RfC talkpage about abstracting the backend
22:32:56 * sumanah hopes AaronSchulz or someone else will phrase the externallinks fix thing as an #info
22:33:26 <sumanah> (sounds like we can move on pretty soon to Nonlinear versioning which will be candy to some folks)
22:33:52 <sumanah> #action someone should consult AaronSchulz and anomie re how to fix the externallinks issue
22:34:02 <AaronSchulz> well that's not actually related, it just reminded me
22:34:34 <sumanah> oh here
22:34:37 <ori> hello
22:34:50 <sumanah> ori: the end of http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140409.txt for the chat till now :)
22:35:30 <sumanah> (in a minute we'll be talking about brainbreaking branching wiki repo stuff)
22:35:55 <ori> thanks
22:36:44 <sumanah> I will not be a draconian jerk if you want to follow up a little during the next topic :-)
22:36:51 <sumanah> #topic Nonlinear versioning
22:36:56 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Nonlinear_versioning
22:37:01 <sumanah> #info Adam Wight last updated this in August 2013.  This feels super experimental so I don't know whether any next actions are necessary; should we encourage Adam to prototype this?
22:37:15 <awight> There's also a human-language RFC at https://meta.wikimedia.org/wiki/Grants:IdeaLab/Edit_your_replica
22:37:16 <sumanah> awight: ^ :) I could be wrong!
22:37:29 <sumanah> #link https://meta.wikimedia.org/wiki/Grants:IdeaLab/Edit_your_replica human-language RfC
22:37:30 <awight> sumanah: no, you nailed it.  I need to know if anyone out there cares.
22:37:44 <awight> Technically, it's almost straightforward.
22:37:53 * sumanah imagines awight singing his plaintive lament on a stage. "does anyone caaaaaare"
22:37:56 <TimStarling> "It has been pointed out that the current "revision" table already supports arbitrary directed graphs"
22:38:00 <TimStarling> no it doesn't
22:38:18 <awight> revision.parent can point to anything...
22:38:27 <brion> yeah but not much uses rev_parent
22:38:33 <awight> oic!
22:38:35 <brion> most stuff assumes order
22:38:42 <brion> by timestamp and/or id
22:38:45 <TimStarling> if you actually used that for branches, you wouldn't be able to display a single branch efficiently
22:38:58 <TimStarling> you would have to actually traverse the rev_parent linked list, which would take forever
22:39:21 <awight> I think I had a shortcut for that... yeah, a link table which marks each revision with a branch name.
22:39:27 * brion hrms
22:39:36 <awight> so, along a given branch, the history would look linear.
22:40:04 <TimStarling> a link table which would pretty much replace the revision table for paging purposes?
22:40:18 <TimStarling> hundreds of GB of extra indexes etc.?
22:40:25 <awight> probably, but the history pager would... be a totally different animal.
22:40:35 <sumanah> awight: I know there are people out there - not so much in the active wikitech-l community, but out there - who care about this sort of thing. David Gerard is one
22:40:37 <sumanah> I think
22:41:11 <awight> Possibly, a compelling use case is: "Handle massive editing demand for breaking news articles"
22:41:17 <sumanah> I feel like I keep hearing people at conferences who want to expound on this sort of idea after a beer or two
22:41:24 <awight> lol i bet
22:41:34 <TimStarling> the questions I have about this are:
22:41:38 <TimStarling> 1) do we want it?
22:41:47 <TimStarling> 2) how much hardware are we willing to buy to get it?
22:42:11 <MaxSem> 1) I think it's going to be helluva confusing for most users
22:42:14 <TimStarling> 3) how do you make efficient use of that extra hardware? what schema, what server, etc.?
22:42:27 <sumanah> #action awight http://opensourcebridge.org/blog/2014/03/submit-your-2014-proposals-today/ ;-) (I bet people would come to your talk)
22:42:28 <awight> MaxSem: agreed, the complexity should be hidden most of the time.
22:42:50 <sumanah> is this maybe less for Wikimedia wikis and more for other wikis that people run for other purposes?
22:43:01 <brion> branching in svn and git is hard enough for devs who work with it every day. a good UX for a branching mechanism is HARD
22:43:09 <awight> Yes absolutely.
22:43:11 <sumanah> digital humanities stuff, SMW installs, art projects?
22:43:24 <TimStarling> you know that we are considering redesigning the revision system along SOA lines
22:43:31 <awight> The first phase would probably not be long-running branches.  It would be conflict resolution.
22:43:34 <sumanah> awight: have you already looked at SparkleShare/Glitter Gallery which attempts to make git usable by designers?
22:43:59 <awight> sumanah: thx, I'll check it out
22:44:21 <awight> TimStarling: no, pls send a link if you have it
22:44:23 * sumanah slightly ignores 40-minute meeting limit but doesn't want to go much above 45 or 50
22:44:38 <TimStarling> there's no link afaik
22:44:42 <sumanah> #info <TimStarling> you know that we are considering redesigning the revision system along SOA lines
22:44:53 <awight> My personal next step is to collect edit conflict statistics, so we know if the massive demand to edit current news is a valid use case.
22:44:54 <TimStarling> gwicke has been plugging the idea
22:45:14 <sumanah> #info this might be better for non-Wikimedia wikis, or for use by massively multiplayer editing on fast-breaking news topics
22:45:31 <TimStarling> you can reduce edit conflict rates without branching
22:45:37 <sumanah> #info Tim's questions: 1) do we want it? 2) how much hardware are we willing to buy to get it?  3) how do you make efficient use of that extra hardware? what schema, what server, etc.?
22:45:41 <awight> hehe by fixing oldid for example ;)
22:46:17 <TimStarling> you know we still just use diff3 for edit conflict merging
22:46:29 <sumanah> #info performance, how to alter the DB schema, what does the current schema support
22:46:33 <TimStarling> a system which must have taken less than an hour to implement
22:46:59 <awight> TimStarling: yes, but word-based conflict resolution is currently unsolved AFAIK
22:47:08 <awight> I think it's gonna remain a human task
22:47:56 <TimStarling> unsolved? you're saying someone has tried to solve it?
22:48:38 <awight> The second use case that I think is relevant to WMF is to improve article protection, to make articles editable by anyone, all the time, but to shift the work from spam patrolling on suspicious edits to having a merge-resolution work queue.
22:48:40 <TimStarling> but what proportion of edit conflicts result from intraline editing? in my experience, it is mostly adding new lines to the ends of lists
22:48:57 <awight> TimStarling: that's the thing... we don't have any statistics on edit conflicts.  They are not logged.
22:49:30 <sumanah> they aren't? I did not know that
22:49:48 <awight> Argh, I had a patch for that and... cannot find it.
22:49:48 <TimStarling> well, we can already make articles editable by anyone, all the time
22:50:15 <sumanah> We're now 10 min over
22:50:25 <sumanah> next steps for awight?
22:50:25 <TimStarling> it's called pending changes
22:50:48 <awight> TimStarling: it's linear however, so vandalism still affects future editing, right?
22:51:09 <TimStarling> yes, but that's not why it's underused, is it?
22:51:36 <awight> no, it'
22:51:49 <awight> it's probably because it creates a huge workload that nobody is ever going to do ;)
22:52:25 <awight> also, perhaps cos FlaggedRevs is overdue for a rewrite.
22:53:50 <sumanah> so: my opinion is that I want Adam to keep investigating this but it would need more thinking before getting to something where we want to prototype it, and he should have more detailed answers to Tim's 3 questions
22:54:28 <awight> Sure, but fwiw I cannot answer (1) myself
22:54:37 <sumanah> and Adam ought to reach outside the wikitech-l community to find potential users
22:54:39 <TimStarling> I would like to see some more rationale on the RFC
22:54:54 <awight> TimStarling: did you look at the IdeaLab page?  I put the motivations there...
22:54:55 <TimStarling> comparing it to other ways of implementing a draft feature
22:55:09 <TimStarling> not yet, no
22:55:31 <sumanah> awight: maybe you should just transclude that stuff onto the RfC - the RfC will basically be the canonical document for motivation & implementation/architecture
22:55:38 <sumanah> (or just copy-n-paste)
22:55:47 <awight> makes sense, thanks
22:55:49 <sumanah> ok, I'm declaring some next actions :)
22:56:35 <sumanah> #action awight to keep investigating this, move motivations from Idealab page onto RfC, compare his idea to to other ways of implementing a draft feature, try to answer Tim's questions 2 & 3, and look for potential users (maybe 3rd party wikis)
22:56:54 <sumanah> #endmeeting
Retrieved from "https://www.mediawiki.org/w/index.php?title=Architecture_meetings/RFC_review_2014-04-09&oldid=955059"