[08:10:39] godog regarding https://phabricator.wikimedia.org/T161012 I'm still really getting turned around by how all the file backend stuff is working, How much do you know about the mediawiki side of it all? [08:15:07] addshore: heh, not a whole lot besides how the swift file backend ties into the more general file backend [08:15:50] addshore: though for local testing swift has a mode "all in one", did you come across it already? [08:16:19] basically this https://github.com/swiftstack/vagrant-swift-all-in-one [09:06:19] godog: I did have a go using the swift all in one stuff through docker, and as far as I could tell swift was all setup just fine, but I couldnt get the mediawiki interaction working [09:06:25] that was quite some time ago though [09:07:02] What I kind of need is my only mini beta cluster running the same config as the actual beta cluster, but only have enwiki and commons for example :/ [09:08:06] It's all driving me mad :D [09:08:39] hehehe easy to believe, mediawiki-vagrant would be the closest I can think of [09:09:10] I can't remember though if swift runs on mediawiki-vagrant, maybe nowadays it does since gilles worked on thumbor and swift and all that [09:11:44] I might have to try and go down that path today then on labs [14:59:11] RainbowSprinkles: I have patches for 23 extensions to chmod -x some files (P5913), inspired by legoktm doing it for two extensions. Good candidate for pushing with +2? [15:02:16] * anomie considers picking on DanielK_WMDE by asking if he's going to make subtasks for changing each line of each file for MCR ;) [15:06:51] addshore: mw-vagrant does have a role::swift. Gilles used mw-vagrant for all the thumbor dev work so I would imagine it works. [15:41:33] anomie: I'd agree that it's a good candidate for that sort of thing [15:44:30] Reedy: Would the syntax to do that be something like `git push origin HEAD:refs/for/master/chmod%l=Code-Review+2,m=+2_approved_by_Reedy`? [15:48:04] hahah [15:48:09] I dunno if the syntax is right [15:48:13] But feel free to approve per me [16:00:52] Reedy: Yeah, that syntax seems to have worked. [16:01:00] e.g. https://gerrit.wikimedia.org/r/#/c/373590/ [16:05:55] anomie: i have worked in teams where the desired ticket granularity was "something that can be finished by one person in one day". [16:06:06] anomie: right now, I'm more on the level of weeks :) [16:06:31] DanielK_WMDE: (: [16:07:13] i'm actually ok with the one-day-approach if it's useful for the team - i.e. there is very low latency, and very close collaboration [16:08:32] that level of task decomposition takes a lot of effort so its really only worthwhile IMO when working on things that literally anyone on the team can do that are also highly independent. [16:08:55] I've worked on such teams too, but never enjoyed the grooming work [16:10:46] yes, it'S a matter of balance, and teh balance highly depends on the environment and soclial as well as technical factors [16:11:16] i granularity I chose for the mcr tickets is essentially the same as in the RDF document for MCR [16:12:24] I tend to go to the opposite extreme: one task for a project that might take a year, if I'm going to be doing the whole project. [16:14:35] that would drive me nuts, i need to be able to tick stuff off a list. [16:14:45] and that's all tickets are to me. things to tick off a list [16:15:25] I usually have a TODO.txt for that. Or put it in the commit message while the patch is WIP. [16:16:20] (this is where you're suppose to pick on me about doing a year's worth of work in one giant patch) ;) [16:20:30] but then you end up with huge patches that need forever to review. I suppose we'll have to find a way to meet in the middle [16:20:49] So, the two tickets I plan to tackle of the next couple of weeks are: [16:20:52] https://phabricator.wikimedia.org/T174025 [16:20:57] https://phabricator.wikimedia.org/T174039 [16:24:40] I do split up patches in many cases. It's just that if I'm making a change that needs 10 new classes, I prefer to just do it as one patch rather than 10 patches each adding one class. [16:26:21] depends... [16:26:48] higher granularity of patches makes it easier to see WHAT, but harder to see WHY. [16:27:17] Hmm, Phab doesn't seem to want to draw me a nice graph of all the new tasks like it does elsewhere. [16:27:21] Kind of the opposite of the size of functions/classes. Smaller functions make it easier to read intent, but harder to see what'S really happening. [16:27:46] yes, i was also wondering when phab does an graph, and when it doesn't. seems kind of random?... [16:33:28] anomie: i think we should have a weekly check-in for mcr work, together with cindy and maybe amanda. tim would be good, but time zones make that tricky... [16:33:49] anomie: i'm pretty flexible, what would be a good time for you? i'd go for 30 minutes for now. [16:36:06] hm... i think thursday would be a good day... [16:39:32] Ok, I just sent you an invite [16:42:34] DanielK_WMDE: Exactly, time zones make any meeting with everyone on this team difficult. At this time of year, it's either just before 2100 UTC if Tim gets up early or sometime in 0100-0300 UTC if I give up part of my evening. After US DST ends and Australia DST starts all those times shift an hour later, and for Tim the "get up early" becomes "before 9am" instead of "before 7am". [16:43:49] DanielK_WMDE: The meeting you scheduled is at 3:30am for Tim, I believe... [16:44:23] Yes, I know. I don't expect him to attend. He told me that that would be ok. [16:44:41] i invited him as optional anyway, simply so he sees the meeting in his calendar [16:44:43] Well, as long as you don't expect him to show up for it, then it works for me. [16:45:17] yea... we have had the techcom meeting at 10pm my time for years now, to make it somewhat sane for tim. [16:45:29] works for me, but i don't want to give up more evenings, really. [17:29:01] DanielK_WMDE: re: ticking things off a list, did you know you can make todo lists with [] in phab? [17:29:21] e.g. https://phabricator.wikimedia.org/T117661 [17:29:44] often a lot easier to manage than subtasks IMO [17:29:50] tgr: yes. but not very nicely. and sometimes, two states aren't quite enough [17:30:15] yea... sometimes. [17:31:35] anomie: woohoo, thanks :) I find them whenever I'm working on the Debian stuff and lintian complains about files that are executable and shouldn't be though we should probably have some kind of CI check for it [17:32:26] phab graph has a size limit, IIRC it tries to fetch all ancestors and descendants within some range and show a full graph, and if that ends up larger than a few dozen tasks then it just shows immediate parents and children in a flat interface, with search buttons [17:34:12] legoktm: find . \( -name .git -o -name node_modules -o -name vendor \) -prune -o -type f -perm /ugo+x -exec sh -c 'for f do head -c5 "$f" | grep -q "^#!" || echo "$f"; done' sh {} + [17:34:38] Then ignore the few binaries, like the lua binaries in Scribunto for LuaStandalone [17:44:39] thanks, I added that to the ticket [17:56:51] * subbu wonders what -prune does on find ... going to hit the man page [17:58:47] subbu: it drops those branches from the graph traversal. find is a depth first traversal and a prune lops of a branch [17:58:55] subbu: If the match is a directory, it doesn't descend into the directory. [17:58:57] *off [17:59:27] yup, saw that. :) [17:59:50] hmmm... maybe its an in-order traversal instead of depth first... [18:01:41] bd808: It's a pre-order depth-first traversal. The -depth option makes it a post-order traversal. [18:01:58] s/post-order/post-order depth-first/ to be clearer [18:03:02] I don't know how much sense in-order would make on a non-binary tree... [18:23:42] bd808: can I do multidirectional setups with swift in vagrant? Ie, make a commons and a Wikipedia? [18:31:13] addshore: I'm not sure what those words mean. :) mw-vagrant does easily support setting up wiki farms, but I'm not familiar with how the swift role changes config [22:35:58] Krinkle, no ideas about https://phabricator.wikimedia.org/T173646 ?