[18:13:07] anomie: found it at https://github.com/wikimedia/generator-wikimedia-php-library#readme [18:14:01] thanks [18:50:55] bd808: I think you need to accept an invite before I can make you admin [18:51:08] or I am not finding the right place to do it [18:51:52] or should I just transfer ownership to you? [19:01:43] tgr: let me see if I can remember how to do it [19:08:36] tgr: I think something has changed in how permissions work on the github side. [19:09:23] It looks like there are 2 ways we can do it now. one would be to make you an admin of the wikimedia organization, the other would be for you to transfer to me and then I can transfer to wikimedia [19:09:55] the second one sounds more reasonable [19:10:00] It doesn't seem to be possible to create a co-admin anymore [19:10:36] Works for me. The only thing that might end up being weird is redirects from your original repo to the new one [19:10:46] probably I would have to make it an organization repo, not a personal repo? [19:11:17] I guess so. it used to be possible to do that with a personal repo but it seems to have changed [19:11:22] anyway if I made you co-admin you would still transfer it so there is not much difference in the end result right? [19:11:43] yeah its basically the same thing [19:15:47] "being transferred" [19:17:04] wow they make this annoying. no in site notification just an email with a sekret link to click [19:19:22] tgr: https://github.com/wikimedia/php-gpglib [19:19:38] I sent you an invite to join the org [19:22:42] tgr: and now on packagist too -- https://packagist.org/packages/wikimedia/gpglib [19:22:56] cool [19:23:50] \o/ [19:23:56] nice work [19:40:49] bd808: (I finally got around to looking at the link) Yet another WTF tool ("yo")? Ugh. [19:41:12] * bd808 shrugs [19:41:26] yeah, build systems all suck so everybody makes a new one [19:41:39] https://xkcd.com/927/ [19:43:05] And of course it wants "npm -g". Sorry, no. You're lucky I'm using you at all, "yo". [19:43:12] it's not really a build system, more of a scaffolding tool [19:43:53] AFAIK it was the first one aimed at web developers not heavily into programming [19:44:20] seemed nice, although I think I only used it once [19:44:59] I was actually thinking of creating a yeoman template for hosting a PHP tool on labs [19:45:24] so people can set up OAuth and autodiscovery easily [19:46:18] Hmm. Which license? [19:46:52] GPL maybe? [19:47:17] but you can set up dialogs through which people can pick one [19:47:25] * anomie goes with GPL, for the moment anyway [19:48:16] MIT for libriaries, GPL for applications IMO [19:50:16] opinions vary. Apache2 has some advantages for libraries. Assignment of contributions being the largest [19:51:01] GPL 3+ is my current favorite for apps [19:51:26] bd808, tgr: Any of MIT, Apache2, GPL-2.0+, I don't care. Just tell me what color to paint the bikeshed. And have someone make me a gerrit repo, please ;) [19:51:55] as in, contributions are being assigned to the Apache Foundation? [19:53:10] to the application without needing a separate contributors agreement [19:53:32] many OSI licenses don't explicitly include that clause [19:54:12] "5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions." [19:55:14] anomie: I made a wiki page just for you ;) -- https://www.mediawiki.org/wiki/Gerrit/New_repositories#Step_4:_Request_space_for_your_extension [19:55:25] that does sound useful [19:56:37] can't wait for differential and self-service repo creation [19:57:18] I know only vague things about licensing but that robla dude dropped some knowledge on me about a year ago when we were doing the librarization project [19:59:38] bd808, tgr: Another thing to paint, what should I name this? "mediawiki/php-session-serializer"? [20:00:07] * anomie was hoping someone would take him up on "And have someone make me a gerrit repo, please ;)" and have to decide on the name for him [20:00:33] the perfect name IMO [20:01:05] do we use mediawiki/ or wikimedia/ ? [20:01:38] we've just been putting new libs in the root "php-session-serializer" [20:01:57] but the packgist name would probably be wikimedia/php-session-serializer [20:02:06] it's not something mediawiki specific [20:03:16] right now that's the rule of thumb for package naming: mediawiki if its not really useful outside of MW; wikimedia if it is a general library [20:03:53] there is a task somewhere to rename mediawiki/assert [20:33:49] bd808: https://phabricator.wikimedia.org/T115388 [20:33:57] what do you think about the syntax? [20:34:40] where does all the non-hook description in that file go? [20:35:01] before the --- if I understand the spec correctly [20:35:39] well... that will kind of work [20:36:08] or it can just be commented out [20:36:21] that would make the file a yaml stream of 2 documents. the first being gibberish and the second being the hook info [20:37:00] I guess that comments or even a flowed text block wold work [20:37:31] In general that part specified there doesn't look bad [20:38:25] if all the keys in the yaml doc are hook names then it would be ok. Otherwise you probably want a "hooks" key or something that they all nest under [20:38:40] I tried to look for an example that has everything: longmultiline description, deprecated marker, reference arguments [20:39:16] as far as I can see there is no need for other keys [20:39:58] the arguments there would become an array of hashes ( [{"$editpage": "EditPage object"}, {...}] [20:40:38] yes, I think that's not terrible [20:40:40] If you are assuming processing with php the array level could be removed [20:40:55] but for non-php that wouldn't be right, so yeah [20:41:20] I looked at !!omap but that makes it less human-readable [20:41:37] and the output is not that much nicer [20:42:13] the one sucky thing is that references need escaping [20:42:42] that's an easy mistake when editing by hand [20:43:11] thins like !!omap and !seq are basically implementation details that should really only be used in serialization formats IMO [20:43:25] yeah & is a reserved character [20:43:57] maybe all arguments should be quoted so there is no ambiguity [20:44:02] quoting all variable names would probably be safest for copy-n-paste editing [20:44:16] I guess we agree :) [20:45:09] how could argument type be added to that format? [20:45:21] I think we have some docs that include a type [20:45:52] there are things like "$saveName: (string) destination file name" [20:46:11] the ones I have seen just add it to the text [20:46:18] *nod* [20:46:20] but you could do something like [20:46:37] why aren't we doing this as php docblocks or something similar? [20:46:40] - "$foo": set the foo [20:46:45] type: string [20:46:47] it would be easy in sphinx ;) [20:47:11] I was thinking of generating docblocks from this [20:48:33] not sure about doxygen but phpdocumentor has http://manual.phpdoc.org/HTMLSmartyConverter/PHP/phpDocumentor/tutorial_tags.method.pkg.html [20:49:28] so you can add __callStatic to Hooks as a sort-of alias to run and add @method documentation for the hooks [20:49:59] If doxygen has something similar it would be burried in http://www.stack.nl/~dimitri/doxygen/manual/commands.html I think [20:50:13] it doesn't work for extensions but it's a start [20:50:32] bd808: Don't forget to merge that thing. [20:50:50] I don't think there is a way to get autocompletion for extension hooks without getting into heavy IDE trickery [20:51:06] anomie: *nod* was waiting to see if the wmf.3 deploy actually happened but thanks for the poke [20:51:35] * bd808 doesn't care at all about ide autocomplete [20:53:17] so how does wmf.3 work as semver? [20:53:33] shouldn't that be 27.0.0-wmf.3 or something? [20:53:46] i hate that change [20:53:48] it makes no sense [20:53:53] it's confusing and terrible [20:54:29] maybe legoktm can explain how it parses [20:55:08] it should be parseable by human operators too [20:55:46] "A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version." [20:55:49] * legoktm reads up [20:56:28] so - means pre-release, "wmf" is random noise and ".3" is third iteration [20:57:00] which would make sense if the part before the - were semver-compatible [20:57:00] tgr: it follows the semver version formating, we just don't follow the increment major for breaking changes thing [20:57:17] lol [20:57:27] jut like semver except not at all :) [20:58:26] at least you kept the php- [20:59:17] in the first place, the branch is called wmf/..., doesn't that break semver? [20:59:27] or can composer map that somehow? [20:59:37] the branch name != version number [21:00:12] the branch name is just a number that increments periodically as code changes [21:00:17] nothing like a version number [21:00:33] well, composer doesn't like "-wmf.X" already [21:00:55] but it's valid semver [21:01:08] is composer more opinionated? [21:01:15] I thuoght the point was to make composer accept branch names as (pretend-)valid semver codes [21:01:39] otherwise why change the branch format at all? [21:01:57] woah, github's UI changed [21:01:59] someone should file a task about making the version format not suck [21:02:01] https://github.com/composer/semver/blob/master/src/VersionParser.php#L27 [21:02:12] bd808: ^ yes, it hardcodes "alpha/beta/rc/etc" [21:02:15] not me, because i'm snarky and mean [21:02:18] maybe tgr [21:02:20] :P [21:02:39] legoktm: I think I know a guy who works on that library ;) [21:03:04] so why didn't we switch to -alpha.1? [21:03:24] which is what .wmf1 really meant anyway [21:06:18] we discussed it at some point (semver.org allows arbitrary pre-release stuff) and the consensus at that time was that the library was firstly intended for composer, which has stricter requirements than semver.org [21:06:28] if we are serious about this, why not drop the 1. and actually follow the semver standard? [21:06:56] great PR move too [21:07:35] well what would we carp about then? [21:07:36] "their version number is thrice higher than Drupal so it must be three times better" [21:07:37] boring [21:07:48] if it worked for Firefox... [21:07:54] as for not using -alpha...it's not really a MediaWiki alpha with all the Wikimedia-specific extensions that are bundled in [21:08:35] well that gets into the whole question of why we do that in the mw/core.git repo too [21:09:05] * bd808 claims hysterical raisins [21:09:07] I was told ostriches has a plan for that :) [21:11:32] Version numbers are silly [21:11:35] ^ My thoughts [21:14:39] the branch name != version number