[00:00:58] I've consistently rejected them from PNG meta data, SVG/HTML file comments, and CSS/JS file comments. I don't see why PHP needs to be different. [00:01:42] They should be in JS and CSS [00:01:44] the license is applied to the repository or other distributed form as a unit. Manually taking a single line out of a random file, or taking one file or one directory without including the license, violates the license. [00:02:04] I agree with you to the extent that I'm not very keen on legoktm's idea of adding license headers to every class file [00:02:16] What use case in the license mandates a license header for the case of stealing a file that does not apply to stealing the last 5 lines of a single file? [00:03:03] the habit presumably comes from GPL's informational text "How to Apply These Terms to Your New Programs" [00:03:21] but it's not necessary to follow that section, it's not part of the license [00:03:27] As someone who has performed a licensing audit on all of MediaWiki core, I can tell that our not caring about them has made it really easy to introduce GPL violations in the past [00:03:38] Right, if you have a single-file program with no LICENSE file or readme accompanied, distributed as-is, that makes sense to me. [00:03:48] And the lack of them makes it really confusing when there is plenty of multi-licensed code in core [00:04:50] I don't see a difference between requiring file headers and requiring painters to include their creative commons license be mentioned in the center of their panting. [00:05:18] I do agree however, that we need to be clear about indicating the license of files. [00:05:35] GPL v2 section 1 does say that we must "keep intact all the notices that refer to this License" [00:05:48] so it may not be necessary to add them, but it's not allowed to remove them [00:06:57] but like I say, we are committing a wilful violation of the GPL every time we change a file, by not following section 2a [00:07:23] By not doing what? [00:07:46] "You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change." [00:09:10] But we're not creating a new Program are we? Its the same program [00:14:00] Like, I don't see FSF/GNU projects maintaining a changlog inside the file itself [00:14:15] But I can email the FSF for clarification [00:14:20] pretty sure there is no right to distribute a modified version of a source file other than the right granted in section 2 [00:15:00] section 2 says " You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program" [00:15:15] this is just a statement of copyright law, a modification of a work by another author is a derivative work [00:15:21] Whilst they're in the same repo they're all one "Program". [00:15:32] (Ish. Ignore libraries.) [00:15:45] it doesn't even mention repos [00:15:58] I don't know where you're getting this from [00:15:59] I don't think repos matter here [00:16:11] how can you tell if a modified work is still the same program? [00:16:21] Indeed, it's trying to be generic enough that non-repo-based distribution/curation is covered. [00:16:39] section 1 only allows "verbatim" copies, it doesn't allow you to modify the work and call it the same program [00:16:40] TimStarling: The honest answer? Lawyers, several million dollars, and a couple of years. [00:16:59] I generally take the Denning approach to these things. [00:17:37] you're proposing that forking of a software project is an act with some legal effect and definition? [00:18:48] what I think is that there is an implicit license given by our contributors to waive section 2a [00:18:50] No, I'm saying that it's complex and mostly untested in court, and satisfactory answers generally don't exist. Good lawyers in this area (like WMF's) advise caution. [00:19:31] evidently we don't follow 2a, nobody tries to enforce their rights under 2a, so an implicit license arises [00:20:05] a contract can be created informally in such a way [00:20:29] Yes, though note that AU/UK law is quite a bit different from US law on this. [00:21:43] I'll send an email to the FSF once I get home to see if we can get some clarification [00:22:21] All the projects I'm involved in put short-form licence mentions at the top of each PHP/JS/CSS/LESS file. Some files don't make it possible though – JSON, SVG, etc. [00:25:07] short as in one line, or do you mean the recommended GPL license header [00:25:49] One line. But then, I generally avoid GPL code as much as possible for this kind of reason. [00:27:01] The recommended one is poorly-considered for code that's broken up into one-short-file-per-class, which is especially true for JS code. [00:27:56] We could move all of MediaWiki to one file and then put a header at the top [00:28:01] Then we don't have to debate per-file stuff [00:28:44] Just run Tim's script in reverse :p [00:30:23] no_justification: I think we just had an RfC about not doing that. :-) [00:30:33] Also, can you imagine the rebase issues? [00:31:01] Can't be any worse than the rebase issues caused when we decided typing array() was too many keystrokes [00:31:22] just think of the glorious future no_justification [00:31:29] * James_F laughs. [00:31:49] Anyway, it's getting busy here, I'm going to step away. Have fun sorting out the logistics of the GPL. ;-) [00:33:09] TimStarling: I'm still trying to get through today though :P [00:35:42] according to that GPL informational section, the point of putting the long form at the top of each file is to "most effectively convey the exclusion of warranty" [00:35:52] Well crap. Locked myself out of the house. [00:36:14] is your house very secure? [00:36:46] Its an apartment building. My actual unit is currently unlocked since I just ran outside for a few moments. [00:36:58] Just need a neighbor to unlock the front door [00:38:28] (it's a small building, we all know one another) [00:45:11] Its a little chilly out though... [00:46:54] Yay upstairs neighbor got home [02:12:12] no_justification: if you have more tasks like https://phabricator.wikimedia.org/T181758 we can make them GCI ones [02:12:21] ("stop using deprecated stuff") [02:12:53] I was skimming logstash earlier [03:05:46] What's the process for creating releases for extensions we support? Can I just create one in GitHub and be done with it? [03:14:40] most extensions don't do releases, I don't know if there is a standard procedure [03:14:53] Depends what you mean by "creating releases" :) [03:15:09] You can create git tags in the gerrit repo, and they'll be propogated through to github [03:15:42] But as Tim said, most don't bother... [03:16:41] Reedy_: Someone asked for one for CodeMirror. They said that ExtensionDistributor gives them an old version and they want the newer one. [03:17:08] ExtensionDistributor just takes code from the REL1_xx branches [03:17:48] If you know a newer branch version should work, they should use that [03:18:02] But obviously goes against the core/branch making suggestions we make [03:18:08] Are they on an old mw? [03:18:24] "We use MW 1.27.4 and what I get through the ExtensionDistributer is CodeMirror 3.4.0, wheras the current version is 4.something." [03:18:51] So they can't get the newer version until they update MW? Or is there a workaround? [03:18:51] Answers are "tough" or "use newer at your own risk" probably :) [03:19:10] They can, we'd just generally consider it unsupported [03:19:18] Master of codemirror says "MediaWiki": ">= 1.23.0" [03:19:23] Which feels a little dubious [03:19:35] Yeah, I don't think it'd cause a problem with older MW. [03:19:40] It's just a bunch of JS. [03:20:26] MW shouldn't stop them [03:20:39] Do they need a feature from a newer version? [03:21:32] Reedy: Some bugs in older version that were fixed in the newer one. [03:22:00] They can select master in the ExtensionDistributor [03:22:08] It should work, but it's not guaranteed to work [03:22:20] That's what I was about to ask. Thanks! [03:22:21] And they shouldn't expect support if it doesn't (probably) [03:22:37] Got it. At their own risk. [03:23:14] heh, that 1.23 is definitely wrong [03:23:21] wfLoadExtension doesn't come in till MW 1.25 [03:23:23] * Reedy fixes [03:25:17] Reedy: You're fast! How did you submit two patches at the same time? [03:25:27] just stack them [03:25:36] make changes. git commit. make more changes. git commit. git review [03:25:49] you can do upto 10 in one go [03:26:10] Ah. Nice! [09:26:23] Niharika: see https://www.mediawiki.org/wiki/Compatibility#MediaWiki_extensions [09:27:15] using release branches, and getting rid of the extension's own versioning scheme is the best practice IMO [09:41:48] tgr: Thanks. Are the extension branches corresponding to MW releases automatically made or do I need to make one myself? [09:42:09] automatically, assuming nothing is broken [09:42:28] Got it. [09:42:54] there was a while around 1_26-ish when it was flaky, but I haven't heard any problems recently [17:17:42] https://github.com/composer/composer/pull/6696 [17:17:42] legoktm: IT GOT MERGED [17:17:48] * Reedy parties [17:28:13] It does amuse me when they bodge multiple releases in a row [17:28:13] https://github.com/composer/composer/releases [17:44:52] Reedy: woohoo [17:45:25] Reedy: once they make a release we can update the vendor documentation to specify that as the minimum version people should use [17:45:33] Yup, definitely [17:45:38] Might want to wait for a point release or 3 :P [18:23:59] legoktm: Filed another deprecated one that's a good GCI task: https://phabricator.wikimedia.org/T181828 [18:25:29] And https://phabricator.wikimedia.org/T181829 [18:25:32] Can't remove it from Translate though probably [18:25:38] I think those 3 are the easiest ones [18:26:14] $useOoui = method_exists( $editpage, 'isOouiEnabled' ) && $editpage->isOouiEnabled(); [18:26:15] lol [18:26:45] Probably needs a version check putting in [18:26:56] Of course, shouldn't have had wfDeprecated added while still in use in WMF extensions.. [18:27:27] Yep [18:28:02] There's already tasks filed for the AbuseFilter, Collection and Scribunto ones [18:28:12] So alllllll the deprecated log entries have tickets now [18:28:13] Yay [18:30:26] I guess it just wants a version check putting in [18:30:32] Reedy: That was because Translate is trying to maintain compatibility in master with MW1.27+. :-( [18:30:38] I know [18:30:52] But you've upset no_justification [18:31:02] We're not going to wait four years to refactor just because of an eccentric compatibility policy. [18:31:13] [18:30:26] I guess it just wants a version check putting in [18:31:20] Then gtfo of my logs. [18:31:59] Fair. Or fix Translate's compatibility policy. [18:32:12] That's not gonna change, I think [18:32:17] Sadly. [18:32:19] I dunno why they need the compat [18:32:26] Considering twn runs master mostly [18:32:36] I don't care about their compat policy. I care about spammy logs [18:32:40] We could un-deprecate the method :p [18:32:42] (for all I care) [18:33:17] lol [18:33:34] no_justification: Did T181758 actually exist back in April? Shouldn't we fix those ones and do a new task? [18:33:34] T181758: Stop using deprecated ApiBase::dieUsage() in Linter extension - https://phabricator.wikimedia.org/T181758 [18:34:08] Eh, we could just retitle the task and get a new table [18:34:27] Or… do a new task with a new table. [18:34:37] Eternal tasks considered harmful. :-) [18:34:38] Heh, just removed the datestamp from the task [18:34:43] Now don't need a new task ;-) [18:35:11] no_justification: Then it's not a task, it's a project. [18:35:18] $useOoui = version_compare( $wgVersion, '1.30c', '>=' ) [18:35:18] || method_exists( $editpage, 'isOouiEnabled' ) && $editpage->isOouiEnabled(); [18:35:22] no_justification: Tasks have an end point when they're complete. [18:35:25] That should work, and short circuit, right? [18:35:37] James_F: Well if the 6 subtasks are done, it's complete ;-) [18:36:01] no_justification: Except you just added another… [18:36:02] because version_compare is stupid [18:36:06] There's no rule that says tasks have to have an arbitrary number of subtasks. [18:36:22] over 9000 or gtfo [18:36:55] James_F: I mean if you want to be super pedantic about it and re-parent those tasks to a new tracking one, be my guest. I just did what made sense to me [18:37:00] Can anyone remember why people put the c in the version? [18:37:00] I don't care enough [18:39:06] https://gerrit.wikimedia.org/r/394626 [18:40:30] Ouch [18:40:33] There's a lot of warnings [18:41:20] A third are WikimediaEventsHooks::onChangesListSpecialPageFilters [18:41:33] Hang on [18:41:38] Is that description up to date? [18:41:55] I'm guessing not... [18:41:55] I was looking based on logstash [18:42:23] Hmmm, I have an idea for wfUseMW() [18:42:29] Add a second param that's a callback [18:42:40] So basically call wfUseMW( $version, function(){} ) [18:42:49] If the version is whatever, call the function. Otherwise, don't [18:43:01] (right now it just throws MWException) [18:43:06] no_justification, Reedy: I had planned to close the task from April and open a new one today. Timing. :-) [18:43:12] Lies! [18:43:14] :P [18:43:28] I'm pretty sure we fixed up most of the noise there [18:43:32] We did. [18:43:36] At least the really spammy ones [18:43:39] That table is the table from April. [18:43:46] Hence the need for a new one. [18:43:55] Heh, speaking of wfUseMW(), Collection extension being insane, etc.... [18:43:56] https://github.com/wikimedia/mediawiki-extensions-Collection/blob/HEAD/Collection.hooks.php#L24 [18:43:59] That made me chuckle ^ [18:44:09] wat [18:44:20] * no_justification removes [18:44:21] Wow. [18:44:23] We could almost always have a parent tracking one... And just create new ones at specific dates [18:45:58] https://gerrit.wikimedia.org/r/394628 [18:46:19] lol [18:47:44] https://phabricator.wikimedia.org/T181834 [18:48:42] no_justification, Reedy: Review on https://gerrit.wikimedia.org/r/#/c/381806/ would fix another Collection log error. [18:48:51] James_F: Should the still-open ones on the old task be migrated to the new one? [18:48:56] Since they're still spamming me? [18:49:09] probably [18:49:19] no_justification: Yeah, if they're still spamming we should double-parent them. If they're not, Decline. [18:49:53] 381806 would fix the spam issue, but there's still use of raw $_SESSION that all *should* be migrated to Session::get() and friends [18:50:03] Fun. [18:50:31] But that's a larger thing to fix. I just wasn't sure how nicely raw $_SESSION usage would play with SessionManager [18:50:43] Otherwise I would've written that same patch like 3 months ago :p [18:50:46] :-D [18:52:33] no_justification: Can you dump in a table from logstash into https://phabricator.wikimedia.org/T181834 so we can prioritise? [18:53:04] * no_justification just screenshots it to be annoying [18:53:07] I'm lazyyyyyy [18:53:55] Psh. [18:53:59] Heh, I love that export raw and export formatted both give you CSV :p [18:54:16] Export to CSV and I'll manually reformat if you really need it. :-) [18:55:51] So, given that $_SESSION works fine and acts as a standard interface. Why bother migrating it to the more complicated direction and not just standardise on $_SESSION instead? [18:57:58] James_F: Updated w/ table [18:58:26] Krinkle: That's fine too....I just wasn't sure how $_SESSION behaved w/ session mgr. If the answer is "just fine" then the patch James linked above can land and we can silence this finally [19:43:52] Scribunto is a bit out of date with SyntaxHighlight [19:46:40] Krinkle: Oh, re: dblists/ do you think I can just remove that test outright? [19:52:51] no_justification: maybe, looks like it. Maybe just ensure the dblist symlink exists [19:52:57] the directory [19:53:22] If I swap the all.dblist contains enwiki test to dblists/all.dblist, that covers it too [19:54:43] https://gerrit.wikimedia.org/r/#/c/394199/1..3/ [19:56:11] Actually, this might not still be right: highlight might need some fixin' [19:56:59] I should add the symlink first, get it all working, then drop the old ones [19:57:17] But first, time for walkies with the pupperz [20:08:55] So yeah, let's do the symlink first, then get highlight.php pointing to it, *then* I can drop the old symlinks [20:20:22] no_justification: You rock [20:20:45] ....for what? :) [20:26:14] Krinkle: $_SESSION works as long as you're dealing with the session specified by the global WebRequest. If something is working with FauxRequest or doing other weird things, I'm not sure I'd trust it. [20:27:52] #til [20:29:08] Reedy: Last I checked, the Scribunto/SyntaxHighlight situation was blocked on someone deciding on and implementing a new interface for SyntaxHighlight to let Scribunto get the necessary RL modules. [20:29:16] no_justification: For putting in the table on T181834; have culled the wmf.8 ones and added tasks for the ones that have them. [20:29:16] T181834: Fix MediaWiki deprecated calls in Wikimedia production, 2017-12-01 - https://phabricator.wikimedia.org/T181834 [20:29:27] heh [20:31:32] anomie: Yeah, but session_start/id is only called by Setup.php if the session already existed by that point. If started later, wfSetupSession does it. If we replace a call to wfSetupSession with just SMgr::persist(), then $_SESSION won't work properly, right? [20:31:41] we'd need the _id/_start call still as well, I'd expect. [20:34:28] Krinkle: Session->persist() calls SessionBackend->persist(), which calls SessionBackend->autosave(), which either calls SessionBackend->save() or will in the near future, which will call SessionBackend->checkPHPSession(), which will call session_id() and session_start() if the Session being saved is the same ID as SessionManager's "global" session. [20:34:41] Note that SecurePoll is also using wfSetupSession (twice). [20:35:38] anomie: Hm.. so does that mean those calls can be removed from wfSessionStart? [20:37:34] wfSetupSession() was also used to switch to a different session, probably to implement the aforementioned "other weird things". [20:38:40] k :) [20:46:21] no_justification: ah, yeah, highlight.php itself requires the file in question be a symlink as defense against mis-use just in ase. [20:46:22] case. [20:59:14] anomie: did you just put some text in the database directly to test the ar_text patch? [21:00:27] legoktm: More or less. On my localhost test wiki I ran `begin; update archive, text set ar_text=old_text, ar_flags=old_flags, ar_text_id = null where ar_text_id = old_id and ar_id < 20; delete from text where old_id not in (select rev_text_id from revision union select ar_text_id from archive where ar_text_id is not null); commit;` [21:24:41] Looks like our unit tests don't pass on PHP 7 .1. Getting "A non-numeric value encountered" from an objectcache test locally in PHP 7.1. [21:24:50] Due to $str . $num + num [21:25:02] Possibly broken already, or could be a breaking change we need to fix in non-test code. [21:25:09] (HashBagOStuffTest) [21:32:15] Looks like the behaviour didn't change in PHP 7.1, just the fact that it warns now, because it does indeed already not work as expected. https://3v4l.org/0JJrM