[00:37:20] TimStarling: anomie: https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/541130/ [00:39:07] looks straightforward, Krinkle [00:39:58] you miss an 'a' in the commit message, though [00:40:09] er.. MaxSem [00:41:00] the! :} [00:51:59] MaxSem: there should also be an 'a' in the word signature. [00:52:09] I suspect that's the one Platonides meant :) [00:52:56] Platonides: thanks, yeah, I know the change is harmless on its own but as a general principle, I assume code was written for a reason, and without that reason, removal is something I generally recommend against until that understanding is available especially if it's relatively new code. [01:17:44] The reason is usually "it seemed like a good idea at the time" :P [17:25:40] kostajh: thank for merging! is that going to be deployed automatically? when will it be live? [17:25:59] duesen: no, new docker images need to be built :\ [17:26:10] I'll ping Antoine [17:26:39] thanks! [17:38:09] duesen: Oh, my eyes. [17:45:38] James_F: I *knew* that you'd say that :P [17:46:20] * James_F grins. [17:51:57] duesen, arlo has a WIP here https://gerrit.wikimedia.org/r/c/mediawiki/core/+/540970 .. and expects to have it done wed or so .. giving you an early heads up so you can review it .. we need it for parsoid/php API completeness .. once that patch is done, an early review would be greatly appreciated since we are on a tight timeline to get parsoid/php on the cluster. [17:52:25] or anyone else on the cpt really .. but i pinged you since you seemed to have written that code originally. [17:52:32] accept header parsing. [17:54:30] duesen: oh dear, let me fix that rebase [17:58:39] subbu: this has good test coverage, so I don't really need to understand the code, right? ;) [17:59:41] does it originally have good test coverage? or does it need new tests for original functionality? [18:01:23] arlo discovered thse gaps because parsoid has mocha api tests to test all these .. so, presumably he can add any additional tests to that core accept header parsing code. [18:06:07] subbu: original test coverage seems decent. the new implementation is stricter, but that makes sense. [18:06:13] i see no tests for new functionality [18:06:25] in fact, it's unclear to me what the new functionality actually is. [18:07:03] it is still in wip .. it is not complete. but, it is needed for implement parsoid's content negotiation (version downgrade) functionality. [18:07:05] oh wait, the new method is public. needs tests, then. will comment [18:07:42] duesen: btw, did you see my earlier ping regarding PHP support draft? [18:07:42] i was only giving you a heads up so you are available for review once it is done. :) [18:09:38] Krinkle: I did, but I only got back from visiting family a few hours ago. The draft looks good to me, but I don't feel qualified to judge the actual requirements. What would I be verifying? That it matches the RFC? [18:10:04] kostajh: what rebase? [18:11:16] duesen: Yes. I made some common sense assumptions but had to write it mostly from scratch to be about what to require instead of what not to require. Given we never really described "everything else" inverting it was non-trivial. [18:12:29] Krinkle: i don't do much juggling of versions and releases. I'll check to see whetehr it matches [18:13:30] Krinkle: can we trade favors, and you have a look at tags I proposed in https://www.mediawiki.org/wiki/Stable_Interface_Policy ? [18:13:41] sure [18:13:58] thanks! [18:16:12] Krinkle: what does "at the time the Linux release cycle starts" mean? [18:16:39] duesen: date of .0 stable release? [18:16:51] when it becomes LTS [18:17:38] Krinkle: 1.35.0 is nominally due in May 2020. [18:17:41] "t the time the Linux distribution's LTS period starts" [18:17:45] duesen: would that be better^ ? [18:17:54] Krinkle: the distribution, I suppose? Maybe I'm pedantic, but to me, Linux is the kernes ;) [18:18:02] yes [18:18:10] not the internal development cycle [18:18:11] good point [18:18:22] Would it be correct to say "at the time the distribution's release cycle starts"? [18:19:08] duesen: yeah, I've gone further and mentioned LTS explicitly because some releases I think they are not LTS from day one (unlike for MW). E.g. they are first stable than than .4 becomes the LTS. Less ambiguity. [18:19:28] James_F: OK. - why are you mentioning that? :-) [18:20:44] Krinkle: maybe "at the time of the first release of the distribution's major version" or "the .0 release" would be even clearer. Or link "release cycles" to something that explains the scheme. [18:21:24] Krinkle: 1.35.0 is the next LTS for us. [18:22:08] James_F: I understand, but I'm missing some context. should this be corrected or added somewhere? [18:22:40] No, I was trying to give more context. Never mind. [18:22:58] The policy doesn't mention our LTS releases. I suppose it doesn't have to, the policy just has different implications for LTS releases than for "normal" releases. [18:23:03] duesen: Yeah, I don't want to get too detailed on describing the upstream process. From memory, while we start LTS at stable/.0, Canonical does not always do that. So start of LTS period seems more accurate whilet being less precise. [18:23:29] Yeah for us the support policy doesn't vary for stable vs LTS, it's only for our link to Linux that LTS matters. [18:23:35] But it would be helpful to mention or reference a page that provides information on how long we normally support a stable release, vs an LTS release. [18:34:36] Krinkle: I'm having trouble understanding the last point. Let me try and rephrase: "At any given point in time, there must be at least one combination of Debian Linux LTS and MediaWiki that continues to be supported by both parties for a period of at least two years into the future" [18:34:39] IS that correct? [18:35:18] If it is, the second sentence isn't needed, I think. [18:36:37] duesen: There doesnt' have to be a combination that you can start on today that will receive 2 more years of support. [18:36:43] small semantic difference [18:37:49] https://www.mediawiki.org/w/index.php?title=Support_policy_for_PHP&type=revision&diff=3449441&oldid=3449416&diffmode=source [18:37:55] added the simpler start from your version though [18:37:59] Krinkle: that's exactly the point i was having trouble with. and whether it is implied or not depends on the overlap provided by the relevant project's LTS policies. [18:38:28] which sentence could be removed you mean? [18:38:35] We only give one year of overlap, so the new lts may not yet exist, but the old one will run out in less than two years... that'S the point, right? [18:39:15] This should perhaps be removed: "Thus allowing a site operator to remain on a given combination for 2 years (with support), before upgrading to the next supported combination. " [18:39:17] That would not be allowed under this policy [18:39:20] It'S not really true either [18:39:29] it only works if you upgrade soon enough [18:39:30] It is, should be. that part is explicitly in the RFC. [18:39:42] Yes, that's fine. We can demand on when the upgrade starts. [18:39:42] now I'm more confused :) [18:39:48] But there has to be 2 years of overlap [18:40:06] where if you plan it right, you won't have to do a major upgrade of either LInux or MW for 2 years [18:40:09] "A long term support release (LTS) will be made every two years. There will be a one-year overlap in LTS support. " [18:40:10] https://www.mediawiki.org/wiki/Version_lifecycle#Release_policy [18:40:26] So that would have to change as well? [18:40:27] MW LTS have 3 years of support [18:40:50] Yes. Not sufficient for a 2 year windo into the future. that would require 4 years [18:40:59] I don't follow [18:41:13] It doesn't say you have to use the latest [18:41:41] Anywhere during that first year, you get onto the MW LTS and whatever Linux it is compatible with that has 2 years or more left, and you're good to go. [18:41:48] What would I install, if I installed right now, that would allow me to not update for two years? [18:43:02] You join the MW 1.31 cycle which will have less than 2 years left because you're joining the party late, but the next one will have 2+ years again. [18:43:19] It will have 2 years of overlap with the LInux LTS you use. [18:43:27] which started in the past [18:43:34] This is intentional. [18:44:19] So,the two years are guaranteed for the start points of our own releases. not from any given time. right? [18:44:25] Exactly [18:44:31] then the first sentence is confusing. at least for me. [18:44:38] let me try again. [18:45:16] Im open to better wording, but the way I see it, my wording currently captures this in some way, whereas your earlier suggestion would be a different requirement (continuing 2 more years, which is not what we approved). [18:46:12] The second sentence is indeed redundant. I added it to capture the spirit of the rule, in case of ambiguity or confusion. [18:46:39] It's just an example, it doesn't add or change the rule [18:46:53] Yes, I thought that was the intended meaning. I now see that it is not. I'm having trouble finding a good wording that captures this. [18:49:40] Krinkle: what's the EOL policy for regular releases? I don't see it made explicite anywhere [18:50:02] I'm trying to decide whether regular releases are at all relevant for the 2-year-window requirement [18:51:06] duesen: For the Linux thing regular releases with 1 year support indeed don't qualify. It's imho out of scope though. It's stating what must be possible, and releases and support etc needs to fit that, not the other way around. [18:51:21] stable release and LTSes can change, but it must continue to fit. [18:51:37] The stable releases still play into the other requrements though, e.g. we dropped PHP 7.1 support in a non-LTS release. [18:52:06] We can mention it, but I think I avoided it out of fear of more confusion of what is nominal and what is explanatory. [18:54:03] Yea, ok. I'm lokking for a phrasing that starts with "when specifying supported php versions for a release...". Can we simplify to a slightly stronger rule? That would be that any new release has to support a PHP version that will continue to be supported by a Debian|Ubuntu LTS for at least two years after the MW release is masde. [18:54:46] That would make things a lot more clear in my mind, and would effectively result in the same thing. Or did I get that wrong? [18:57:59] duesen: That's not incompatible with the intended rule, but it does not wholly cover it. [18:58:11] I think.. [18:58:20] There must not be gaps [18:58:30] between one stretch of 2 years and the next [18:59:18] Krinkle: but that can only be ensured by our release cycle. not by the policy on php support. [19:00:17] if we have a release cycle that doesn't have gaps, it amounts to the same. [19:00:21] I'm short on time. I want to focus first on not having changed, added, or removed parts of rules that weren't approved by the RFC. Communicating it well and minimally we can iterate on later. I've made notes of this and will think about that part more. [19:00:35] ok, cool [19:00:56] i did not spot any difference in substance [19:33:08] subbu: not super urgent, but a quick check on https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/540701 would be appreciated when you have a moment [19:33:45] (presumably only affects pipeline jobs, but trying to check with folks when dropping directories into the root of projects)