HomePhabricator

ArchCom RFC Meeting W34: T69223: Schema change for page content language (2016-08-24, #wikimedia-office)
ActivePublic

Hosted by daniel on Aug 24 2016, 9:00 PM - 10:00 PM.

Description

Agenda

  • Location: #wikimedia-office IRC channel
  • Meeting type: Consensus
  • Time: Weekly, Wednesday 21:00 UTC (2pm PDT, 23:00 CEST)
  • Topic:
    • T69223: Schema change for page content language

Meeting summary

  • topic discussed: do we believe the page_lang field is needed on all wikis? (robla, 21:08:25)
  • jynus:Â [schema changes on Wikimedia's production cluster are tricky] so I want the maximum amount of agreement possible (robla, 21:13:37)
  • <James_F> we might in future have parallel slots with different languages. <brion> it feels like [the language] belongs with the content and we're already planning to change that with the content direction (DanielK_WMDE_, 21:15:05)
  • legoktm: [no actual urgency, but T69223] is a bug request from 2007 that a volunteer fixed 2 years ago and was released as part of 1.24 and in active use by other non-Wikimedia wikis. (robla, 21:15:48)
  • 14:16:08Â <legoktm>Â robla: the actual 2007 bug is https://phabricator.wikimedia.org/T11360 (robla, 21:16:31)
  • 14:20:16Â <TimStarling>Â there are two open questions: what to do about the rest of the schema changes, and policy going forwards (robla, 21:20:37)
  • applying changes to page table probably not super slow (should be onlineable) and a bunch of other changes are queued up for next master switch (brion, 21:23:07)
  • <jynus> it is actually "super slow", just that for most of the time it can live at the same time than regular writes (brion, 21:24:16)
  • we may wish to promulgate an RfC that just says "thou shalt not have optional schema updates" (brion, 21:31:14)
  • : legoktm add "If a table is deployed to multiple wikis/databases, any schema changes must be applied to all wikis where that table is present for consistency." to [[wikitech:Schema_changes]] (robla, 21:34:05)
  • LINK: https://www.mediawiki.org/w/index.php?title=Development_policy&type=revision&diff=2223295&oldid=2142163 (legoktm, 21:40:26)
  • jynus: a) I apply this change to all wikis, b) I apply this change to a subset of wikis, as requests (which I do object highly), c) I do not apply this change (robla, 21:44:30)

Meeting ended at 22:01:31 UTC.

People present (lines said)

  • jynus (119)
  • brion (43)
  • robla (36)
  • DanielK_WMDE_ (35)
  • TimStarling (22)
  • legoktm (20)
  • Scott_WUaS (6)
  • Dereckson (5)
  • James_F (4)
  • domas (4)
  • SMalyshev (3)
  • stashbot (3)
  • wm-labs-meetbot` (3)
  • ebernhardson (2)
  • ori (1)

Full log

121:02:39 <robla> #startmeeting ArchCom: Schema change for page content language (T69223)
221:02:39 <wm-labs-meetbot`> Meeting started Wed Aug 24 21:02:39 2016 UTC and is due to finish in 60 minutes. The chair is robla. Information about MeetBot at http://wiki.debian.org/MeetBot.
321:02:39 <wm-labs-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
421:02:39 <wm-labs-meetbot`> The meeting name has been set to 'archcom__schema_change_for_page_content_language__t69223_'
521:02:39 <stashbot> T69223: Schema change for page content language - https://phabricator.wikimedia.org/T69223
621:02:54 <robla> #topic Wikimedia meeting channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/
721:03:08 <SMalyshev> hi
821:03:11 <robla> hi everyone!
921:04:17 <robla> jynus wanted to make sure we have developer consensus on T69223 . do we?
1021:04:17 <stashbot> T69223: Schema change for page content language - https://phabricator.wikimedia.org/T69223
1121:05:06 <jynus> the main issue seems to be with people thinking we could apply schema changes optionally
1221:05:22 <jynus> and that was everybody's mind when it was merged
1321:05:48 <legoktm> Would it be problematic to apply the schema change to all wikis?
1421:05:51 <DanielK_WMDE_> To me the question is whether it makes sense semantically. is the language really a property of the page? or is it rather a property of the content? can it change over time? cane (with Muti-Content-Revisions) have content in multiple languages on the same page?
1521:05:52 <jynus> then, 2 years later, people realize that we may not need that extra column on one of our largest core tables
1621:06:04 <jynus> ^legoktm
1721:06:48 <jynus> that is the point, people think we can do that, and even if we could technically do that, that would mean wmf forking mediawiki code and maintaining its own version
1821:07:17 <legoktm> er, I don't think we need to go down that rabbit hole...
1921:07:18 <TimStarling> legoktm: on the ticket jynus seems to be pushing back on that pretty strongly
2021:07:20 <Scott_WUaS> Heya! :)
2121:07:23 <James_F> DanielK_WMDE_: Yes. Very much so.
2221:07:25 <jynus> no
2321:07:29 <jynus> I do not want that
2421:07:41 <brion> so i'm a little vague on the scope here. are we talking about applying a schema change to enable an existing feature, or talking about how best to do that kind of feature?
2521:07:49 <DanielK_WMDE_> James_F: yes what? it's a property of the content, not the page?
2621:07:54 <legoktm> brion: the former AIUI
2721:08:12 <jynus> I want people merging changes to have into account how practical that is
2821:08:16 <legoktm> TimStarling: from what I read, it seemed to me that he was only objecting to the plan of not applying it to all wikis.
2921:08:20 <DanielK_WMDE_> if that is the case, it should go into the new content table we discussed last week, not into the page table
3021:08:25 <robla> #info topic discussed: do we believe the page_lang field is needed on all wikis?
3121:08:34 <legoktm> DanielK_WMDE_: well, this feature has been in core since 1.24
3221:08:36 <James_F> DanielK_WMDE_: Yes, sorry. And also yes, we might in future have parallel slots with different languages.
3321:08:39 <legoktm> it just hasn't been deployed yet
3421:08:46 <jynus> most of the people that agreed that change: aaron, nemo, etc.
3521:08:58 <jynus> thought we were going to apply it only to a few tables
3621:09:16 <jynus> if we are not going to have that, do we still want it (that way)
3721:09:44 <DanielK_WMDE_> James_F: if that is the case, i vote for adding this to the content table, and not deploy it to the page table on more wikis. we'd just have to remove it again in the future.
3821:09:58 <jynus> some people mentioned that maybe the slot thingie we discused last week could be an alternative
3921:10:05 <jynus> I do not know, what I want
4021:10:12 <jynus> is people agreeing
4121:10:18 <DanielK_WMDE_> that would also be an opportunity to apply the same optimization we want to apply for storing content model & friends. use int ids to represent the language in large tables
4221:10:24 <jynus> and not asking for the reverse change in a few weeks
4321:10:26 <brion> my inclination is to agree with DanielK_WMDE_; it feels like it belongs with the content and we're already planning to change that with the content direction
4421:10:55 <jynus> let me give my personal take a bit offtopic
4521:10:55 <brion> so if there's not a pressing need to enable this with the existing page_lang schema tweak, we save ourselves some trouble by making only one change later
4621:11:04 <brion> :)
4721:11:10 <jynus> merging code is "easy"
4821:11:18 <jynus> it is not, but physically easy
4921:11:23 <SMalyshev> I wonder how it would work with indexing - different languages require different analyzers, etc. but right now all pages of the wiki are in the same index...
5021:11:43 <jynus> aplying schema changes in a runing system is not that easy, and technically cannot be reverted
5121:11:56 <jynus> so I want the maximum amount of agreement possible
5221:12:02 <brion> *nod*
5321:12:04 <jynus> not to the point of blocking things
5421:12:07 <legoktm> to avoid this from happening in the future, I think <https://wikitech.wikimedia.org/wiki/Schema_changes> needs to explicitly state that if a schema change is proposed for a table, it must be applied to all wikis that have that table.
5521:12:11 <jynus> it is ok to make mistakes
5621:12:24 <jynus> but making sure that here and now we all agree
5721:12:34 <jynus> that is my only requuest to all of you
5821:12:36 <jynus> :-)
5921:12:40 <DanielK_WMDE_> SMalyshev: the content handler could declare a different index depending on the content language... but it would have to declare an index of all the languages we plan to support, right? would that be an issue?
6021:13:05 <brion> hooking up the search index to multiple languages is a question for later, but a good one :)
6121:13:10 <brion> jynus: ++
6221:13:13 <jynus> is Nemo around?
6321:13:20 <Scott_WUaS> (In - https://www.mediawiki.org/wiki/Extension:Translate/Usability_improvements_2014#Tentative_timeline - what does "University starts-Work hours shifted to evening and night" refer to please? As some of you know, CC MIT OCW-centric in 7 languages and Yale OYC-centric CC was donated to Wikidata last autumn 2015 by WUaS ... and per Lydia:) too)
6421:13:21 <SMalyshev> DanielK_WMDE_: I don't know... it probably needs to be discussed with ebernhardson and dcausse
6521:13:23 <DanielK_WMDE_> jynus: i agree - not all changes are easy to undo. anything that creates artifacts (data) needs extra thought.
6621:13:34 <jynus> the other thing
6721:13:37 <robla> #info jynus: [schema changes on Wikimedia's production cluster are tricky] so I want the maximum amount of agreement possible
6821:13:44 <jynus> is that that was merged a long time ago
6921:13:51 <jynus> I wasn't part of the wmf
7021:14:00 <jynus> so maybe needs shifted, etc.
7121:14:13 <legoktm> brion: like everything, there's no actual urgency, but this is a bug request from 2007 that a volunteer fixed 2 years ago and was released as part of 1.24 and in active use by other non-Wikimedia wikis.
7221:14:40 <jynus> that is another issue
7321:14:47 <brion> legoktm: right, so any future replacement would need to properly migrate from both states
7421:14:53 <jynus> I think more important than the particular thing
7521:15:02 <ebernhardson> DanielK_WMDE_: letting the content handler choose the index doesn't sound too great, more likely search would have to key off the language it reports at and decide what needs to happen
7621:15:04 <jynus> there is a disconnection between mediawiki and wmf
7721:15:05 <DanielK_WMDE_> #info <James_F> we might in future have parallel slots with different languages. <brion> it feels like [the language] belongs with the content and we're already planning to change that with the content direction
7821:15:05 <legoktm> so to block code written 2 years ago on the basis that it will conflict with code that doesn't exist yet seems pretty silly? poor to me.
7921:15:11 <jynus> which is not bad by itself
8021:15:25 <jynus> but I would like the coordination to be smoother
8121:15:48 <robla> #info legoktm: [no actual urgency, but T69223] is a bug request from 2007 that a volunteer fixed 2 years ago and was released as part of 1.24 and in active use by other non-Wikimedia wikis.
8221:15:48 <stashbot> T69223: Schema change for page content language - https://phabricator.wikimedia.org/T69223
8321:15:52 <jynus> for this I only have requests, not real solutions
8421:15:56 <brion> it's the deployment that's hard part :)
8521:16:08 <legoktm> robla: the actual 2007 bug is https://phabricator.wikimedia.org/T11360
8621:16:10 <James_F> legoktm: I agree that the code should not have been merged without a plan to deploy it. But possibly you're not saying that?
8721:16:22 <jynus> is there something we can do to make that gap smaller?
8821:16:31 <robla> #info 14:16:08 <legoktm> robla: the actual 2007 bug is https://phabricator.wikimedia.org/T11360
8921:16:44 <jynus> but lets focus on this bug first
9021:16:59 <brion> jynus: we could have a MediaWiki core maintenance team that coordinates with ops/db .... but that's another question for another time
9121:17:04 <jynus> ha ha
9221:17:08 <jynus> fair enough
9321:17:22 <DanielK_WMDE_> jynus: mediawiki governance currently lies with the wmf... people are discussing an independant mediawiki org of sorts. do you think that would make things better, or worse?
9421:17:40 <ori> both
9521:17:47 <robla> lol
9621:17:48 <James_F> brion: Except at the time of 1.24 we /had/ such a team…
9721:17:51 <Dereckson> To have a multilingual page doesn't especially conflict with the possibility to assign one language to a page. Different extensions/needs could receive different solutions. So there is no obvious conflict between content language and page language.
9821:17:55 <jynus> if I am being a bit selfish, (please undertand what I mean)
9921:17:55 <DanielK_WMDE_> ori: hehe...
10021:18:11 <legoktm> DanielK_WMDE_: if you're trolling, please do it elsewhere. come on.
10121:18:15 <jynus> I do not care about mediawiki, I care about users using mediawiki to serve wikis :-)
10221:18:52 <legoktm> James_F: There was always a plan to deploy it, it's just that that plan was slightly flawed in the case where they weren't planning to deploy to all dbs. But now that it has been identified, we can fix it by deploying the schema change to all wikis
10321:18:55 <jynus> anyway, this is easy to go offtopic
10421:19:09 <Dereckson> For example, the page language could be set at null for a monolingual wiki or a wiki with pages with multicontent language-specific (or a mul code there).
10521:19:29 <jynus> I think we will not be able to take a decision about this in 20 minutes, but can someone think about it more deply, offline?
10621:19:51 <TimStarling> I don't think we need to discuss page_lang design, that was done 2 years ago
10721:19:56 <jynus> should we try to deploy this to a few wikis to sync with mediawiki
10821:19:58 <ebernhardson> James_F: at the time of 1.24 we didn't have a dba and were basically unwilling to change schemas of large tables in prod though :P
10921:19:59 <DanielK_WMDE_> legoktm: it was a genuine question. sometimes, formalizing relationships makes communication easier. but as robla said, it's a question for another time.
11021:20:04 <brion> jynus: as a practical matter, do we have an estimate on how long it would take to deploy page_lang column as written on enwiki page db?
11121:20:09 <brion> hours/days/months?
11221:20:15 <TimStarling> there are two open questions: what to do about the rest of the schema changes, and policy going forwards
11321:20:16 <legoktm> Aaron said it's 40MB to add the column to enwiki (https://phabricator.wikimedia.org/T69223#2285536), and AFAIS no one else has identified performance problems with the schema change.
11421:20:32 <jynus> brion, times does not matter much
11521:20:37 <robla> #info 14:20:16 <TimStarling> there are two open questions: what to do about the rest of the schema changes, and policy going forwards
11621:20:45 <legoktm> So I don't see any reason to further block this schema change
11721:20:47 <brion> cause if it's a quick change then our lives may be simplified by saying 'apply it' so we have a consistent set of dbs
11821:20:59 <jynus> as I think (cannot guarantee) that I can do it online as it has a PK
11921:21:00 <brion> then can concentrate on being saner in future :D
12021:21:19 <DanielK_WMDE_> my vote: don't deploy page_lang to more wikis, add cont_lang when we add the content table.
12121:21:22 <jynus> but I will require read only at the start and end of the application
12221:21:28 <jynus> maybe multiple times
12321:21:30 <TimStarling> yeah, I think I would like the schema change to be scheduled for the next maintenance batch
12421:21:37 <Dereckson> So if I've well understand the fear of jynus, it was: "is someone going to revert this page_lang field in the next weeks/months?". If so, jynus advices to defer the deployment, if we're sure this change is stable enough, jaime is okay to deploy it to all wikis at the next opportunity. I've well summarized your thoughts jynus ?
12521:22:04 <TimStarling> doing all the master switches is a lot of work, but each schema change applied during that maintenance period is not a lot of extra work
12621:22:30 <jynus> info: I have already a bunch of changes scheduled: watchlist, others
12721:22:41 <DanielK_WMDE_> oooh, watchlist...
12821:22:41 <jynus> and I asked for a week of maintenance
12921:22:42 <TimStarling> you need read-only time during the master switches, right?
13021:23:04 <jynus> yes, the idea is sync it with the dc failovers
13121:23:07 <brion> #info applying changes to page table probably not super slow (should be onlineable) and a bunch of other changes are queued up for next master switch
13221:23:10 <jynus> apply it to the passive dc
13321:23:39 <robla> jynus: is Dereckson's summary accurate?
13421:23:55 <jynus> brion, it is actually "super slow", just that for most of the time it can live at the same time than regular writes
13521:24:12 <jynus> and definitely exclusive from other alters on the same table or even server
13621:24:16 <brion> #info <jynus> it is actually "super slow", just that for most of the time it can live at the same time than regular writes
13721:24:39 <jynus> relatively serial due to the extra writes involved
13821:25:15 <jynus> I tend to apply schema changes serialy for extra safeness, not needed if a dc is passive, though
13921:25:50 <jynus> so tes, although with tables like page or revision, I would say "in the next year"
14021:25:56 <DanielK_WMDE_> jynus, TimStarling: if(!) we end up putting the language into the content table, and we deploy that change in half a year, page_lang would become redundant. if it was certain that we are going to do that, would you want to deploy page_lang now, for consistency?
14121:26:24 <TimStarling> DanielK_WMDE_: I'm pretty sure that we should deploy it now for consistency, yes
14221:26:33 <brion> possible cases: page_lang becomes a summary field, or gets removed
14321:26:48 <DanielK_WMDE_> TimStarling: mit take is yes if it's cheap, but not if it's painful...
14421:27:05 <TimStarling> if in 6 months or a year there's a patch to remove the field, it can be scheduled in the same way
14521:27:11 <jynus> how dependent core code is from that field, once the feature is enabled?
14621:27:13 <brion> so i feel like we're asking jynus if it'll be painful, and jynus is saying pain is ok if it's necessary :)
14721:27:25 <DanielK_WMDE_> hehe
14821:27:26 <TimStarling> jynus will be angry but we will promise to try to do better next time
14921:27:28 <brion> jynus: should be only a couple bits pulling from it
15021:27:35 <jynus> yes, I just want you to make that decision
15121:27:36 <DanielK_WMDE_> brion: yea, it's kind of circular :D
15221:27:39 <brion> and very easy to switch back off if needed
15321:27:48 <jynus> it felt that that was not a real decision before
15421:28:10 <jynus> "I know that undoing this will be painful and I will not complain if jaime delay it"
15521:28:10 <TimStarling> I don't really know if we will have cont_lang or whatever, that has not been the subject of an RFC meeting as far as I know
15621:28:22 <brion> so yeah i'm ok with saying 'deploy it, make sure everything's consistent' even if it ends up changing later
15721:28:42 <brion> i suspect we'll obsolete it but need to be more thoughtful about doing so
15821:29:06 <DanielK_WMDE_> TimStarling: well, the original concern was "let's not do it if we are going to undo it in a few months". it's a real possibility. it should be considered.
15921:29:11 <brion> it's also conceivable we'll store content language through different metadata
16021:29:17 <jynus> as I said, I am ok with someone looking at it in depth and sending a report for everybody to discuss offline
16121:29:23 <DanielK_WMDE_> i'm not opposed to deploying page_lang now. i'm trying to find out if it is "necessary"
16221:29:35 <jynus> I just want more eyes on it
16321:29:45 <DanielK_WMDE_> brion: can be a page_prop even
16421:29:46 <legoktm> [14:29:06] <DanielK_WMDE_> TimStarling: well, the original concern was "let's not do it if we are going to undo it in a few months". it's a real possibility. it should be considered. <-- that was not the original concern.
16521:30:44 <legoktm> DanielK_WMDE_: it can't be a page_prop, https://phabricator.wikimedia.org/T69223#2501293
16621:30:49 <brion> but yeah overall we need to not do stuff like this in future. ;) either deploy everywhere or nowhere, it gets confusing to have optional schema tweaks
16721:30:59 <jynus> ++++++++1000000
16821:31:14 <brion> #info we may wish to promulgate an RfC that just says "thou shalt not have optional schema updates"
16921:31:22 <jynus> in releng/ops we do not have support for such a schema
17021:31:23 <TimStarling> like legoktm said, that can be in the policy document on mw.org
17121:31:25 <robla> thanks brion :-)
17221:31:27 <DanielK_WMDE_> legoktm: then i must have misunderstood what jynus said.
17321:31:42 <jynus> in fact, I mention that every difference from mediawiki core is a bug
17421:31:56 <TimStarling> we don't need a separate RFC, that is a DBA decision and jynus is making it
17521:31:58 <jynus> and that has already caused issues
17621:32:31 <robla> TimStarling: I think it makes sense for it to have some sort of policy backing somewhere
17721:32:33 <DanielK_WMDE_> +1
17821:32:41 <legoktm> I was bold and did it: https://wikitech.wikimedia.org/w/index.php?title=Schema_changes&action=historysubmit&type=revision&diff=818276&oldid=542880
17921:32:42 <brion> well, it's a coding decision to make the update optional, then a dba decision to have deployed it or not
18021:32:53 <brion> legoktm: yay
18121:33:09 <robla> legoktm: thanks!
18221:33:26 <jynus> the question was, "people seemed to want this optional, that may have been an option some time ago (I do not know), it is not longer an option because it is causing multiple problems"
18321:33:31 <DanielK_WMDE_> brion: well, we tend to write code for optional schema changes since typically the code is deployed before the schema change, so it needs to be able to work without it.
18421:33:51 <TimStarling> we have in the past had optional schema updates for minor things like varchar widths
18521:33:56 <Dereckson> jynus: I'm not sure why people seemed to want this optional, perhaps it was only a suggestion to ease your dba life not to apply it where not needed
18621:33:56 <brion> DanielK_WMDE_: we may wish to do that the other way round :)
18721:34:05 <robla> #info: legoktm add "If a table is deployed to multiple wikis/databases, any schema changes must be applied to all wikis where that table is present for consistency." to [[wikitech:Schema_changes]]
18821:34:10 <Dereckson> there is no serious arguments against coherence
18921:34:23 <jynus> The person I have been discussing this more was pushing for optionally applying it
19021:34:33 <DanielK_WMDE_> brion: yeesss.... but then the code needs to be able to live with uninitialized fields....
19121:34:48 <TimStarling> but that was in a different environment, where schema updates were harder and inconsistency was less of a problem
19221:34:59 <robla> legoktm: we should update https://www.mediawiki.org/wiki/Development_policy#Database_patches too
19321:35:41 <jynus> in fact, those schema differences are #1 cause of slowing down schema changes
19421:35:45 <brion> heh "Make your schema change optional – All schema changes must go through a period of being optional. Some examples:"
19521:35:48 * brion headdesk
19621:35:59 <jynus> that is ok, in contecty
19721:36:04 <jynus> it means code optional
19821:36:11 <brion> those aren't quite wrong yeah :D
19921:36:13 <jynus> and it is still good advice
20021:36:30 <jynus> you cannot expect a schema change to be applied atomically
20121:36:34 <DanielK_WMDE_> yea, that's what i meant.
20221:36:39 <jynus> so code must be able to ignore it
20321:36:41 <jynus> that is ok
20421:36:56 <jynus> and a good policy, just needs to be clarified
20521:37:18 <jynus> "period =/= all the time"
20621:38:39 <robla> so, where are we with this particular change?
20721:38:42 <jynus> so, thing I would want from you, can someone compromise to give a look at the code and say "yes, consensus to apply to all wikis"
20821:39:23 <jynus> and then, compromise for involvement on deployment plans, with my help in future cases
20921:39:44 <jynus> if you need a new policy
21021:40:25 <jynus> it would be "schema change need to include a plan for deployment, or something"
21121:40:26 <legoktm> https://www.mediawiki.org/w/index.php?title=Development_policy&type=revision&diff=2223295&oldid=2142163
21221:40:33 <legoktm> robla: ^
21321:40:38 <robla> TimStarling: do you think that someone should step forward and do what jynus is asking for?
21421:41:28 <TimStarling> I'm not really clear on what jynus is asking for
21521:42:03 <jynus> there is 3 ways to go here:
21621:42:15 <jynus> I apply this change to all wikis
21721:42:26 <brion> i believe jynus needs go/no go for this schema change, but also for us to have a clearer policy in future on making sure schema changes are consistent and someone works with ops on future schema-changing merges
21821:42:34 <jynus> I apply this change to a subset of wikis, as requests (which I do object highly)
21921:42:40 <jynus> I do not apply this change
22021:43:05 <brion> what do we need to do to make such a policy real? enough to edit the pages or do we need to approve an RfC or organize ourselves with the other devs?
22121:43:08 <jynus> whatever it is, a reasonable set of reasons, not matter if finally it is not the most optimal decision
22221:43:23 <TimStarling> I've been pretty emphatic that I think the first should be done, apply to all wikis
22321:43:35 <brion> i'm ok with that
22421:43:43 <TimStarling> but without code review, there won't be consensus on whether page_lang is a good idea, from a blank slate design point of view
22521:43:55 <brion> good or not it's already there ;)
22621:44:28 <legoktm> so we're in agreement to deploy it to all wikis?
22721:44:30 <robla> #info jynus: a) I apply this change to all wikis, b) I apply this change to a subset of wikis, as requests (which I do object highly), c) I do not apply this change
22821:45:15 <brion> so as i understand tim says a), i'm leaning to a), DanielK_WMDE_ thought maybe c) ? is that current?
22921:45:35 <brion> or are we still fluid :)
23021:45:47 <Scott_WUaS> :)
23121:45:49 <brion> but nobody things b) is awesome
23221:45:52 <brion> *thinks
23321:46:12 <jynus> note that a decision now is not binding forever, I just want to unblock on this topic
23421:46:25 <DanielK_WMDE_> i'm good with a) if nobody complains if page_lang becomes redundant in half a year. i'm not certain that it will, but it might.
23521:46:53 <DanielK_WMDE_> option b) doesn't sound good, it doesn't solve any of the underlying propblems
23621:47:00 <brion> *nod*
23721:47:10 <jynus> the second question is, I suppose this was an undesired state (?), is there something I/we can do to avoid it in the future (short term actionables)?
23821:47:15 <Scott_WUaS> *nod* too
23921:47:16 <TimStarling> right, I'm saying a over c just as a judgement call, based on expected lead time before an alternative solution becomes available, cost in terms of DB space, cost in terms of schema change time
24021:47:56 <DanielK_WMDE_> i'll trust TimStarling that he's judging that right, then
24121:48:27 <brion> right :)
24221:48:31 <robla> should we put "a)" in last call?
24321:48:35 <DanielK_WMDE_> jynus: in terms of process? we should make sure we have a db/ops person at these RFC meetings, i think.
24421:48:39 <robla> er..."final comment"?
24521:48:51 <brion> jynus: I think correct, we don't want to be left in this state in future. not sure exactly solution but we agree on the problem statement there :D
24621:48:55 <robla> DanielK_WMDE_: I don't think we need to insist on that
24721:49:19 <robla> I think from a process perspective, we just need to make sure https://www.mediawiki.org/wiki/Development_policy is right
24821:49:34 <jynus> robla, that is outdated
24921:49:47 <jynus> I worked with developers for a better process
25021:50:01 <robla> jynus: it's a wiki; please edit (like legoktm just did)
25121:50:10 <jynus> I already did
25221:50:18 <DanielK_WMDE_> robla: not insist, of course. i think it would help. but it doesn't have to be the live meeting. comments on rfcs in pahb will also do. we should make sure to reach out to db/ops whenever an rfc entails a schema change or other ops issue
25321:50:20 <TimStarling> it would be cool if we had more than one DBA so that jynus didn't have to reliably be here at stupid o'clock
25421:50:21 <jynus> but as a non-"mediawikiean"
25521:50:25 <DanielK_WMDE_> i think we have become better at this already.
25621:50:30 <jynus> I edited wikitech
25721:50:32 <DanielK_WMDE_> do we need to do more in this regard?
25821:50:37 <jynus> let me share
25921:50:43 <DanielK_WMDE_> TimStarling: indeed
26021:50:52 <jynus> robla, https://wikitech.wikimedia.org/wiki/Schema_changes
26121:51:22 <jynus> that is my requested process to speed up schema change applications, work with me from earlier, use some tags when ready for deployment
26221:52:09 <jynus> also an explanation of why I am so slow applying schema changes
26321:52:14 <jynus> :-)
26421:52:23 <jynus> (spoiler: I am not)
26521:52:38 <robla> jynus: are you saying that anything we put on mediawiki.org with respect to database stuff is irrelevant?
26621:52:45 <jynus> no
26721:52:55 <jynus> but I have to for schema-changes
26821:53:00 <brion> ok i have to run, taking cat to vet for a checkup :) /meow
26921:53:00 <jynus> *had to fork
27021:53:17 <jynus> because it was full of discussions and abandoned proposals
27121:53:36 <jynus> and create blocked-on-schema-change for the deployment part
27221:53:47 <jynus> WMF servers != mediawiki process
27321:54:34 <jynus> you can do anything you want they way you want, but on deployment, I am the process quality filter, if you are ok with that
27421:54:42 <robla> we deploy MediaWiki code weekly, so WMF servers is nearly equal to mediawiki process
27521:55:13 <jynus> yes, but releng wants to know anything about deploying schema changes
27621:55:17 <jynus> *nothing
27721:55:27 <jynus> so I had to create a process myself
27821:55:54 <robla> could you link to your process from https://www.mediawiki.org/wiki/Development_policy ?
27921:56:01 <jynus> yes, I can add that
28021:56:11 <robla> thanks!
28121:56:20 <jynus> I just do not want to impose anything to developers
28221:56:32 <jynus> I worked on that in fact woth several developer to be more agile
28321:56:47 <jynus> and agreed to that when deploying schema changes
28421:57:29 <robla> cool, I think we're in a good place here now
28521:58:18 <Scott_WUaS> Great, all!
28621:58:22 <robla> so, outcome of today: 1. last call on option A) above and 2. clarifying policy
28721:58:27 <robla> sound about right?
28821:58:46 <robla> (er....*1. final comment on option A)
28921:59:17 <TimStarling> yes
29021:59:25 <Scott_WUaS> :)
29121:59:30 <jynus> so I will clarify the "optional part" add outdated tags and link to the policy
29222:00:01 <robla> wonderful, thanks jynus! will #endmeeting in 60 seconds
29322:00:03 <jynus> I will send a link to the changes to the ticket in case you think I've become too evil
29422:00:18 <DanielK_WMDE_> oh hey domas! you just missed a fun discussion about the deployment of schema changes ;)
29522:00:29 <domas> haha
29622:00:35 <domas> schema change? what is that?!
29722:00:43 <DanielK_WMDE_> *g*
29822:00:43 <jynus> that thing you have automatized
29922:00:52 <robla> jynus: I don't think any of us thinks you're evil :-)
30022:00:53 <TimStarling> ah domas
30122:00:59 <domas> hi Tim!
30222:01:10 <jynus> but people on the wiki cannot agree on :-)
30322:01:11 <TimStarling> we could have had a much more fun discussion if you showed up an hour ago :)
30422:01:24 <robla> alright, ending meeting.... we can have after meeting chat
30522:01:28 <domas> was busy not looking at my screen!
30622:01:31 <robla> #endmeeting

Other meetings

Architecture meetings
13:00 PT ArchCom Planning Meetingsupcomingall since 2016-03-30
14:00 PT ArchCom-RFC Meetingsupcomingall since 2015-09-09

Recurring Event

Event Series
This event is an instance of E66: ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office), and repeats every week.

Event Timeline

RobLa-WMF renamed this event from ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office) to ArchCom RFC Meeting W34: <topic TBD> (2016-08-24, #wikimedia-office).Aug 15 2016, 7:03 PM

Current leading candidate for our August 24 office hour is T69223: Schema change for page content language

RobLa-WMF updated the event description. (Show Details)Aug 24 2016, 7:31 PM
daniel renamed this event from ArchCom RFC Meeting W34: <topic TBD> (2016-08-24, #wikimedia-office) to ArchCom RFC Meeting W34: T69223: Schema change for page content language (2016-08-24, #wikimedia-office).Aug 24 2016, 7:40 PM
RobLa-WMF updated the event description. (Show Details)Aug 26 2016, 8:51 PM

I did more clarifications, as requested, about the deployment policy. The idea is that I can provide constructive feedback as soon as possible and that I need time to apply the changes (right now there are a lot of them enqueued and some may take multiple weeks to be applied, others, like the original task, may require read-only scheduled).

I also recently created the Blocked-on-schema-change project, which helps me organize myself (there are too many Schema-change tags that are abandoned or still in discussion).

Have a look at: https://www.mediawiki.org/w/index.php?title=Development_policy&type=revision&diff=2229089&oldid=2223295 and https://wikitech.wikimedia.org/wiki/Schema_changes

daniel renamed this event from ArchCom RFC Meeting W34: T69223: Schema change for page content language (2016-08-24, #wikimedia-office) to ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office).Nov 21 2016, 6:11 PM
daniel changed the host of this event from RobLa-WMF to daniel.
daniel invited: ; uninvited: .
daniel updated the event description. (Show Details)
daniel updated the event description. (Show Details)Dec 9 2016, 7:41 AM
daniel renamed this event from ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office) to ArchCom RFC Meeting W34: T69223: Schema change for page content language (2016-08-24, #wikimedia-office).