| 03:32 | <MikeSmith> | about the GlobalSign cert screwup, does anybody have any idea what GlobalSign means by saying that “some browsers incorrectly inferred that the cross-signed root had revoked intermediates”? |
| 03:32 | <MikeSmith> | https://www.globalsign.com/en/customer-revocation-error/ |
| 03:33 | <MikeSmith> | basically they seem to be blaming their problem on browsers not conforming to OCSP or CRL requirements |
| 03:34 | <MikeSmith> | but don’t browsers just rely on system CRL libraries to get revocation info? |
| 04:10 | <MikeSmith> | caitp: https://chromium.googlesource.com/v8/v8.git/+/canary/ChangeLog seems less useful than it could be |
| 04:12 | <caitp> | yeah, no disagreements here |
| 07:42 | <annevk> | Does anyone know if you can setup a Gmail filter for X-Autoreply? |
| 07:43 | <annevk> | Deleting out-of-office reminders automatically would be great |
| 07:43 | <annevk> | Also, I hope they never bring those to instant messaging |
| 08:10 | <Ms2ger> | annevk, I'm sorry, I can't reply to your message right now, try again later |
| 08:14 | <annevk> | Ms2ger: haha, badly configured out-of-office reminders on IRC would be the worst |
| 08:14 | <annevk> | Although, I guess, that's what happens on mailing lists too sometimes |
| 08:47 | <Ms2ger> | annevk, hey, I seem to be overlooking where a Response's type is supposed to be set |
| 08:48 | <Ms2ger> | Oh, main fetch 13.2? |
| 08:48 | <annevk> | Ms2ger: it's basically a result of filtering that it appears different to the outside world |
| 08:49 | <annevk> | Ms2ger: yeah, as a result of that step it changes |
| 08:49 | <Ms2ger> | Mhmm |
| 08:50 | <annevk> | Ms2ger: unless you poke at the internal response, but then all bets are off |
| 08:50 | <Ms2ger> | Going to stick my nose in some more code, thanks |
| 08:51 | <annevk> | (security bets, not defined bets) |
| 08:57 | Ms2ger | goes for the easy solution... File a bug, move on |
| 09:13 | <MikeSmith> | I asked about this over on w3c #testing but maybe others here might be able to enlighten me |
| 09:13 | <MikeSmith> | question: how can it be that the commits on a particular branch can be squashed and merged but not rebased and merged? |
| 09:13 | <MikeSmith> | and how from the command line in git do you squash without rebasing? |
| 09:13 | <MikeSmith> | the context is https://github.com/w3c/web-platform-tests/pull/3328 which (before it was closed) was showing green for “Squash and merge” but if I change the button thingey to be “Rebase and merge” it was telling me, “This branch cannot be rebased due to conflicts” |
| 09:39 | <hsivonen> | annevk: FWIW, it also seems that what the Encoding Standard outputs as EUC-KR is valid EUC-KR but not valid windows-949 according to glibc. |
| 09:39 | <hsivonen> | not that we care, but weird |
| 09:41 | <Ms2ger> | Speaking of encodings, apparently playstation memory card titles are (can be?) stored in some kind of shift-jis |
| 09:41 | <foolip> | annevk: here I am |
| 09:41 | <annevk> | 🎉 |
| 09:44 | <hsivonen> | maybe, just in case, I should take a look at what byte sequence exacly it is that glibc doesn't like |
| 09:50 | <hsivonen> | ah. glibc doesn't know the label windows-949 |
| 09:50 | <hsivonen> | it knows cp949 |
| 13:46 | <Domenic> | MikeSmith: I think that could occur if commit A changes things in a way that causes conflicts, and commit B removes the conflict |
| 13:47 | <Domenic> | MikeSmith: thus the squashed A+B has no conflicts, but applying A and B individually will cause conflicts when it tries to apply A |
| 13:47 | <Domenic> | an easy example is: A modifies something that has since changed in master, and B is a revert of A, so that the squased A+B is a no-op. |
| 13:49 | <MikeSmith> | ah |
| 13:50 | <MikeSmith> | yeah that sounds like it might have been the state of things with that particular PR |
| 13:51 | <MikeSmith> | one of the commits was a bokred branch merge with some massive number of commits |
| 13:52 | <MikeSmith> | I guess the right way to deal with that kind of situation is just to abandon the PR branch and start over |
| 13:52 | <MikeSmith> | which is what Brian Birtles ended up doing to un-bork it I think |
| 13:53 | <annevk> | MikeSmith: you could just fix the branch and force push... |
| 13:53 | <annevk> | "just" |
| 13:53 | <annevk> | (but it's doable) |
| 13:54 | <MikeSmith> | yeah Brian says he tried that |
| 13:54 | <MikeSmith> | multiple ways, but none of them worked |
| 13:54 | <MikeSmith> | tried locally |
| 13:56 | <MikeSmith> | anyway this is also why I am not super enthusiastic about granting push-to-master perms for wpt for more people |
| 13:56 | <MikeSmith> | I mean given the craxy stuff I see getting pushed to some PR branches |
| 14:00 | <annevk> | MikeSmith: fair |
| 14:00 | <annevk> | MikeSmith: maybe if enough people had write access some kind of labeling could be done |
| 14:01 | <annevk> | MikeSmith: and then those that do have master access just look for the "alldone" label and land that stuff |
| 14:01 | <MikeSmith> | yeah that is good approach |
| 14:01 | <annevk> | MikeSmith: or some kind of protocol that makes it clear something is ready to land per reviewer but cannot land due to lack of wide access |
| 14:02 | <MikeSmith> | yeah we need to do something a bit more systematic and consistent for wpt |
| 14:02 | <MikeSmith> | because right now some people get frustrated waiting |
| 14:03 | <MikeSmith> | both waiting for review (which sometimes for some specs they are likely to be waiting forever for unless they provide a reviewer themselves) and then also waiting for stuff to be merged |
| 14:57 | <annevk> | Domenic: patching all event callsites is super boring, I might have to spread this out a bit and hope I don't get bitten by merge conflicts |
| 15:03 | <Domenic> | annevk: works for me |
| 15:15 | <tobie> | MikeSmith: have you given the new GH review a look? https://help.github.com/articles/about-pull-request-reviews/#required-reviews |
| 15:15 | <tobie> | MikeSmith: "When required reviews are enabled, anyone with access to the repository can approve changes in a pull request. However, to merge your pull request you need someone who has write or admin permissions in the repository to approve your pull request's changes in their review." |
| 15:16 | <jgraham> | I don't think that really helps unless they also provide a dahsboard showing what's waiting on merge |
| 15:16 | <jgraham> | also the review tools are "not great" |
| 15:26 | <tobie> | jgraham: yeah, I'm puzzled by a bunch of things with them at present. |
| 16:04 | <tobie> | jyasskin: I don't know what went wrong with https://github.com/heycam/webidl/pull/180, but it's super hard to figure out what got handled and what didn't. (Trying to recap what's left to do here so we can land this.) |
| 16:07 | <jyasskin> | tobie: Threading only works when you comment on a particular line, but bz never did that. |
| 16:10 | <tobie> | jyasskin: yeah, but that doesn't seem to be the only issue. Usually comments are hidden when they're addressed by a commit. Doesn't seem the case here. |
| 16:11 | <jyasskin> | They seem not to be hidden even when they were addressed. |
| 16:11 | <jyasskin> | tobie: Look for "reviewed" comments. |
| 16:14 | <jyasskin> | In the past, the thing that hid comments was when the line they were on changed. Now, it looks like "reviews" never hide. Which helps smaug's complaints but broke your workflow. |
| 16:15 | <jyasskin> | tobie: Also note that https://github.com/heycam/webidl/pull/183 will make #180 simpler. |
| 16:22 | <tobie> | jyasskin: yup. |
| 16:23 | <tobie> | jyasskin: have you addressed all of the points in: https://github.com/heycam/webidl/pull/180#issuecomment-250836913 ? |
| 16:24 | <tobie> | jyasskin: what about https://github.com/heycam/webidl/pull/180#discussion_r81793858 and https://github.com/heycam/webidl/pull/180#discussion_r81966920 (I think yes) |
| 16:29 | <tobie> | jyasskin: trying to recap thing s here: https://github.com/heycam/webidl/pull/180#issuecomment-253851644 |
| 16:46 | <jyasskin> | tobie: I omitted the HasOwnProperty() check like bz suggested. |
| 16:48 | <jyasskin> | tobie: Your recap looks good. I pretty strongly prefer handling half-open dictionaries in a separate PR. |
| 16:49 | <jyasskin> | Especially since I'm going to vanish for parental leave soon, so I won't be able to respond to reviews. |
| 16:57 | <tobie> | jyasskin: oh, wow, congrats! |
| 16:57 | <jyasskin> | tobie: Thanks. :) |
| 16:58 | <tobie> | jyasskin: can you give me access to push to you branch if you disappear overnight? |
| 16:58 | <jyasskin> | tobie: "Allow edits from maintainers." is checked, so you should have that access. |
| 16:58 | <tobie> | jyasskin: right, I thought you had done that but was unsure how to verify it. |
| 16:58 | <jyasskin> | I don't know either. :) |
| 16:59 | <tobie> | This GH thing needs some UX love |
| 16:59 | <tobie> | When are you leaving? |
| 17:00 | <tobie> | Or is this pending actual childbirth? |
| 17:18 | <Domenic> | annevk: do you have some easy method for pushing to other people's remotes? Or do you just do the git remote add ... |
| 17:19 | <KiChjang> | Domenic, git push local:remote seems to be the only way |
| 17:19 | <annevk> | Domenic: yeah, I clone |
| 17:20 | <annevk> | Domenic: I wish they had automated that some more or made it a magic branch or some such |
| 17:20 | <Domenic> | yeah magic branches would be nice |
| 17:20 | <KiChjang> | i mean git push remote local_branch:remote_branch |
| 17:20 | <KiChjang> | hub may have some magic stuff |
| 17:21 | <Domenic> | Oh interesting you just put the remote URL in directly KiChjang? |
| 17:21 | <Domenic> | I am thinking a small wrapper shell function that lets me put their GH username instead of their full remote URL would be nice |
| 17:21 | <KiChjang> | Domenic, no, i think you still need to add it as a remote? |
| 17:21 | <KiChjang> | i haven't tried that before |
| 17:23 | <Domenic> | Ah OK |
| 17:35 | <tobie> | Domenic: I end up adding folks as remote. |
| 17:35 | <smaug> | annevk: sorry, I'm a bit behind some spec-issue needinfos |
| 17:35 | <annevk> | smaug: I figured you were busy |
| 17:36 | <smaug> | I'll try to get to those early next week at latest |
| 17:47 | <annevk> | Domenic: so one worry I have with this "minor/major" cleanup is that I'm now on the hook for cleaning up 150 "fire a simple event" callsites too |
| 17:47 | <annevk> | Domenic: I guess I'll clean up stuff that does bubble/cancelable wrong |
| 17:48 | <Domenic> | annevk: yeah my main concern was cleaning up bubbles/cancelable/trusted all at once. But as I said it's fine to split it up and just leave the cleanup open. |
| 17:48 | <Domenic> | The normative changes are definitely more important. |
| 17:48 | <Domenic> | I am hoping that Ctrl+Fing for "does not bubble" and "is not cancelable" returns 0 results basically. |
| 18:24 | <Domenic> | Oh I see you're killing "fire a simple event" in favor of just defaulting in "fire an event" |
| 18:25 | <Domenic> | That is a nice cleanup and also a lot of work ^_^ |
| 18:27 | <KiChjang> | oh wow, time to make lots of updates |
| 18:27 | <KiChjang> | i kinda liked the simple event because it doesn't require that many parameters |
| 18:27 | <KiChjang> | i guess we can still keep it as an internal optimization in the browser, it just doesn't need to be in the spec |
| 18:29 | <smaug> | foolip: do you have telemetry data about window.open(, 'noopener') ? |
| 18:34 | <jyasskin> | tobie: Pending actual childbirth, so no idea. Probably within 2 weeks. |
| 18:35 | <Domenic> | KiChjang: yeah the difference is now "fire an event" also requires only one parameter |
| 18:35 | <KiChjang> | Domenic, huh? so there's no option of selecting whether an event bubbles or cancelable? |
| 18:36 | <Domenic> | KiChjang: there's an option, but it's not required. |
| 18:37 | <KiChjang> | hmm... would like to see how the text reads |
| 18:38 | <Domenic> | annevk: looks like master of DOM is not being pushed to dom.spec.whatwg.org?? |
| 18:39 | <Domenic> | anyway KiChjang see the examples at the bottom of https://rawgit.com/whatwg/dom/master/dom.html#firing-events |
| 18:39 | <Domenic> | I guess it omits the simplest possible example which is "fire an event named `change` at _target_" |
| 18:40 | <annevk> | Domenic: fixed manually |
| 18:41 | <foolip> | smaug: had a look, can't find anything, just for window.open() itself and when the third argument is non-empty: |
| 18:41 | <foolip> | https://www.chromestatus.com/metrics/feature/timeline/popularity/475 |
| 18:42 | <foolip> | https://www.chromestatus.com/metrics/feature/timeline/popularity/476 |
| 18:43 | <smaug> | foolip: it is just that noopener seems to be rather odd feature, since it forces window to be opened in a new window. (bz noticed) |
| 18:43 | <Domenic> | Yeah he just filed the issue |
| 18:44 | <Domenic> | (Although when you put it that way... window.open() forces a new window to open!?! NO WAI) |
| 18:44 | <smaug> | heh |
| 18:44 | <smaug> | well, normally it opens a new tab |
| 18:46 | <KiChjang> | Domenic, does the eventConstructor contain fields that tell the algorithm to set the event's bubbling or cancelable attributes to true? |
| 18:46 | <KiChjang> | the text right now (especially step 4) is pretty vague |
| 19:10 | <Domenic> | KiChjang: see the examples. That's "a description of how IDL attributes are to be initialized" |
| 19:45 | <jyasskin> | Domenic: For the gesture/promise integration, I think I have time to add a metric for how many times we merge two gestures. Would that help you? |
| 19:45 | <jyasskin> | (https://docs.google.com/document/d/1csmMqHr60zded2tdjczr6HrL18iOPR1PlnM2FqCDLOQ/edit?usp=sharing) |
| 19:56 | <Domenic> | jyasskin: that does sound helpful, yeah! |
| 19:56 | <jyasskin> | Domenic: 'k, I'll cc you. |
| 20:43 | <jyasskin> | I wish ES used something other than a quotation mark to represent Lists. Unicode has plenty of brackets they could have chosen from. |
| 20:55 | <Domenic> | I mean these aren't necessarily ES lists |
| 20:55 | <Domenic> | We could use anything else |
| 20:59 | <jyasskin> | Domenic: I think I value consistent notation with ES over getting the right Unicode characters. Unless there a reason these *shouldn't* be Lists? |
| 20:59 | <Domenic> | I mean, it's not formally defined to be one, but I do think there might be value over time in consolidating Web IDL's types into ES's List and Record types |
| 21:00 | <jyasskin> | +1 |
| 21:02 | <Domenic> | It is kind of interesting how both ES and Web IDL end up converging on a value space that is "ES types plus something for abstract vectors and something for abstract maps" |
| 21:08 | <jyasskin> | Lists and maps are the fundamental building blocks of programming. Look at Lisp. |
| 21:10 | <jyasskin> | WebIDL doesn't even really have the maps, since we have to operate on ES stuff that's fundamentally ordered so often. |
| 21:32 | <botie> | rniwa, at 2016-10-13 13:33 UTC, Domenic said: did you see my response to https://github.com/w3c/DOM-Parsing/issues/22 ? I'm not sure I got it right and would love your thoughts. |