[11:40:31] [Log] Exception in load-callback in module mobile.editor.ve: (load.php, line 177) [11:40:53] Unknown dependency: ext.cite.style [11:41:14] on stable. [12:24:59] thedj, ugh, in production too [12:29:55] module missing mobile target ? [13:17:06] morning from mexico [15:48:02] hey joakino [15:48:30] hi kaity :D [15:48:34] do you need me at the prio meeting? [15:51:14] kaity: I don't think so, i figure it's just going to be me and kristenlans talking about how we're going to organize with sam gone [15:51:29] kaity: are you in mexico? [15:51:42] joakino: no but i leave today! [15:51:55] let me know if you need anything [15:52:10] ok awesome, see you tomorrow around here kaity [16:05:49] bearND: hey! i've been kind of thinking about your submodules mail. i don't have a great solution. i think are concerns are: 1) maintain library as a library, preferably in its own repo. 2) develop in one project. 3) publish library artifacts. for #2, i think gradlizing the library would help a lot [16:07:16] bearND: i've been trying to brainstorm. what if we have a compileDev dependency of a java-mwapi *subproject* and compileAlpha, compielBeta, ..., dependency of a java-mwapi jar / jcenter / maven artifact? [16:08:29] bearND: i'm not sure it's a great idea or not. devs still have to know to pull master for the submodule project and still have to bump the library version number when they want to see their changes in alpha [16:08:42] bearND: it would be possible to have a working dev build and a broken alpha build, for example [16:09:16] bearND: i believe ios use a submodule-like concept? cocoapods? i haven't played with them too much [16:11:12] bearND: i think submodules would discourage app development but encourage lib development in the sense that they allow us to maintain a separate library repo with its own artifacts [16:11:43] niedzielski: Yes, I agree with your last stament [16:12:35] niedzielski: If given the choice then I'd prefer more volunteer development on the app [16:14:04] bearND: i respectfully would prefer more development on app components (libs), because i think it's more realistic for third parties to want to contribute to code they can use, but i think both are very important [16:17:05] bearND: anyway, my feeling is that if we can somehow make the library a gradle project, it would be easy for folks who want to develop in one large project to do so, even if they had to manually modify gradle files. if we're in agreement on this, then i think the only change would be figuring out how to publish a gradle artifact like you mentioned in your mail (and this could be a multi step process) [16:18:03] bearND: so i think my proposal would be, gradlize the library (already done) and figure out how to publish an artifact. the only immediate changes to app would be bumping the version number like we do today [16:22:19] niedzielski: I'm ok with the library in Gradle if we have demonstrated we can publish those artifacts to the Central repo from Gradle. I think this shoulnd't be a big hurdle, since I've already found some documentation http://central.sonatype.org/pages/gradle.html [16:23:15] niedzielski: it would be good to have that in a separate Gradle file [16:26:14] bearND: ok, that sounds good to me! i think we have a plan! :) [16:26:41] niedzielski: what are the changes you refer to with "the only immediate changes to app would be bumping the version number like we do today"? [16:28:00] bearND: i would only propose simple gradle modules dependencies initially (like in master today). in the long term, i would personally investigate how to automatically specify a gradle project dependency if it exists. i think / hope this wouldn't be terribly hard [16:29:31] this means that developers who know they're working on both the lib and the app would want (but not need) to know to clone the library repo into the app repo [16:30:26] bearND: it'd be like git submodules with fallback gradle module dependencies [16:31:51] bearND: anyway, that would be my long term hope. the short term i would just keep two projects like everyone else [16:32:40] niedzielski: Well, right now we're in a similar situation. If you want to work on both you can clone both repos. [16:33:32] bearND: right, but you have to manually modify the gradle build files to use local changes seamlessly. in the long term, i hope to make that automatic [16:36:17] niedzielski: yes, that's correct. You'd have to update the version numbers to x.x.x-SNAPSHOT in both repos, then build the lib, then the app. [17:02:41] kaldari joakino [17:02:49] Will you stadn with us!? [17:02:59] going [17:03:52] kaldari dont ditch us on your last standup! [17:03:55] I'm in the hangout, but no one else is :( [17:04:08] try this kaldari https://plus.google.com/hangouts/_/calendar/d2lraW1lZGlhLm9yZ19yMWNvaHVib3JmYjlqcWMydHA0bmwxcXMxZ0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t.abvfhue9msa07tgt4d9v4s0u1g?authuser=0 [17:10:28] kaldari's last standup? *shocked* :o [17:25:18] mdholloway: did you say this was blocked on design? https://phabricator.wikimedia.org/T73136 [17:31:08] bmansurov: you renamed on github? :p [17:31:15] joakino: yes [17:31:27] in search of the perfect username [17:32:38] haha [17:45:22] dbrant|brb: sorry, phone [17:45:35] dbrant|brb: yes, i think vibha said friday she had comments [17:45:44] dbrant|brb: on the new work [17:46:58] vibha, if you're out there, comment away! [17:49:41] hey FlorianSW [17:49:54] kaldari is now on community tech :( [17:49:58] but also :) [17:50:22] hey joakino :) Oh :( Ok, but that's better as the scenario i thought first :D [17:50:45] a great benefit for community tech! [17:50:53] indeed [17:51:55] thx for the answer :) [18:19:54] FlorianSW: I'm sure kaldari will keep pointing out missing documentation in our patches ;)) [18:21:01] bmansurov: I hope :D [18:21:32] Don't forget the comments! ;) [18:27:56] here you go ^ lol [18:31:11] gonna head out and do some mexican things [18:31:22] been up since 5am... [18:31:37] joakino: enjoy ;) [18:32:24] thx bb rmoen! [18:32:28] & all [18:37:17] bearND: i just finished up my patch feedback. mind if i start looking into implementing the OSSRH uploads (as part of T105235)? /cc dbrant mdholloway [18:39:08] niedzielski: not at all. I think that would be great. I would pull this in as T103051 [18:39:37] bearND: oops, sounds good. thanks! [18:53:33] dbrant: any objection to my pulling https://phabricator.wikimedia.org/T105726 into this sprint, or to my proposed solution? i think it'll be a quick fix. [18:55:26] mdholloway: how about a minuscule hangout? [18:55:33] dbrant: sure, omw [19:05:32] mdholloway dbrant bearND: would it be possible for you devs to create a sonatype jira account and share your usernames with me? i'm about to file a new project hosting ticket and would like you guys to have rights. https://issues.sonatype.org/secure/Signup!default.jspa [19:06:14] niedzielski: ok, looking into that right now [19:06:22] bearND: thanks! [19:11:04] bearND: is it correct that we want to keep the "org.mediawiki.api" group id? [19:15:00] niedzielski: good question. I think org.mediawiki might be more appropriate. I've seen that one used for an older version of the library but don't know why yuvipanda changed that later. See the old version at http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.mediawiki%22 [19:15:27] niedzielski: that was used by the old PhoneGap app, i think [19:15:59] bearND: so the artifact id is currently "json" which maybe was already taken since it was common? [19:17:23] niedzielski: common? [19:17:45] bearND: i just mean that "json" isn't a very unique name [19:17:51] oh [19:18:00] bearND: maybe in your link, it was a monolithic artifact. like a fat jar? [19:18:35] bearND: if i'm reading this right, the old artifact id was "api" not "json"? [19:20:02] niedzielski: that's correct [19:22:32] bearND: so do you think it's safe to drop the group id down to org.mediawiki? i didn't know if there was another json artifact somewhere [19:22:45] niedzielski: old: https://github.com/wikimedia/java-mwapi [19:22:49] niedzielski: new: https://github.com/wikimedia/apps-android-java-mwapi [19:23:32] niedzielski: those two libraries are quite different [19:23:52] similar goals but for different platforms [19:24:58] bearND: so org.mediawiki is good then? [19:25:26] niedzielski: i think so, but we need to make sure the artifact ID is unique [19:25:51] =distinctive from the old type of library, which we don't support anymore [19:25:55] bearND: the form also asks for the project page. i think the readme would be as close a thing as we have: https://git.wikimedia.org/blob/apps%2Fandroid%2Fjava-mwapi.git/master/README.md [19:26:37] bearND: ok, i think the artifact id can be changed with just a pom adjustment but the group id can't (at least not easily) [19:27:54] niedzielski: yes, I think the README and the pom.xml of equivalent Gradle file need to be updated. You can look at the old library (https://github.com/wikimedia/java-mwapi/blob/master/pom.xml) for inspiration [19:41:32] niedzielski: created my account, username mholloway [19:42:55] mdholloway dbrant: nice! i have yours and bernd's. dmitry, would you mind getting an account here and sending me your handle? https://issues.sonatype.org/secure/Signup!default.jspa [19:43:15] niedzielski: standby... [19:43:21] dbrant: thanks! [19:44:23] niedzielski: "dmitrybrant" [19:44:35] dbrant: gr8, thanks! [20:14:51] dbrant: one issue with the language selection button -- if it's small enough to have roughly equal margins on the top, bottom, and left, it's going to be quite small (in appearance, if not actual clickable area), meaning that we're going to have to do special cases of the kind we were avoiding last week in order to cut down chinese language codes to [20:14:51] something meaningful that fits in the available space. [20:18:07] dbrant: top, bottom, and right, i mean. [20:22:48] mdholloway: right, i see... how about take the font size down by 2sp (from 10 and 12, go to 8 and 10), and then make the button size the minimum possible size that accommodates "zh-hans" [20:23:13] dbrant: ok! [20:26:59] HaeB: hangout will be okay. i'm now on a wifi connection. ok to do that instead of the phone?