+1 to needing better tools for handling OOO, and big +1 to using gwsq when there are many reviewers to balance.
Given that long leave is potentially 6 months, but unlikely to be 12 months (citation needed), how about changing the criteria to 12 months? Then it sort of covers both "long-tme inactive" and "non-OOO". Regardless, until we have better tooling for OOO, I think it's reasonable to remove people who are currently inactive and they can be re-added later. On Fri, 29 Jul 2022 at 11:47, Kentaro Hara <[email protected]> wrote: > +1 to improving the tool to handle OOO owners. > > Let's step back. The problem I'm solving now is: currently OWNERS files > contain many long-time inactive, non-OOO owners. The goal is to remove > them. Do you agree with the goal? > > The "long-time inactive" part is covered by looking into their review / > commit activities in the past 6 months. > > The "non-OOO" part is tricky because currently there is no way to get the > information from the tool. I'm not sure if giving an option to manually > flip the decision is a great solution because if they are long-time OOO, > they are not likely to be looking at this email and get removed anyway. > Then I thought that it's more reasonable to execute the clean-up process > unconditionally while explicitly saying that they can explain the situation > and re-add themselves when they are back (where they can refer to this > email thread). > > What do you think? > > > > On Fri, Jul 29, 2022 at 1:41 AM K. Moon <[email protected]> wrote: > >> On a related topic, one challenge that I have with OOO status is that >> it's hard to update all the places where you might want to note that (each >> Gerrit repository, Slack, external Gmail, internal Gmail, Calendar, ...). >> For Googlers, I have decent tooling for checking whether they're OOO, in my >> time zone, or whatever (although better integration would save me time), >> but if I wasn't a Googler (and didn't have access to those tools), or I >> want to check the status of a non-Googler, it's often not as easy, or >> impossible. >> >> It'd be great if there were One Tool that (opt-in) tracked OOO status in >> a centralized directory, and worked whether or not you had a Google or >> Chromium account. >> >> For parts of the tree that need to balance between a large number of >> reviewers, something like gwsq probably would be a decent solution. >> (//ipc/SECURITY_OWNERS is using this now; I think trees like //content >> would benefit as well.) >> >> On Thu, Jul 28, 2022 at 8:56 AM Peter Boström <[email protected]> wrote: >> >>> I agree with the policy to not remove owners because they are on leave. >>> Owners plus OOO status should inform owner selection and we still need that >>> because we shouldn't remove owners while they are out for a week but they >>> sure shouldn't be used during that week. >>> >>> If OOO is an efficient signal this should be sufficient without force >>> removing folks on leave. If OOO isn't a sufficient signal and introduces >>> review latency we should look at why that is instead and fix our tooling. >>> >>> If I may spitball another reason for latency we should maybe also >>> surface how long folks review queues are and perhaps use that to help guide >>> owners selection. >>> >>> Also because I'm already up on my soapbox, if you're fast and not >>> overloaded and want to help with the review load, please put something like >>> "fast" or "more reviews plz" in your Gerrit status to encourage more >>> reviews your way (me inspired by ellyjones@ here). Encourage others to >>> do the same and reward this as a community contribution. >>> >>> On Thu, Jul 28, 2022 at 8:15 AM K. Moon <[email protected]> wrote: >>> >>>> I think our owner-suggesting tooling really needs to be better about >>>> deprioritizing owners who are on leave (as well as better load balancing). >>>> I'm not sure periodically removing and re-adding owners is the right >>>> long-term fix, but it could be acceptable if we're working on better >>>> infrastructure in the meanwhile. >>>> >>>> I think another good, oft-discussed improvement would be to separate >>>> Review+1 from Owners+1. This would make the review load for owners more >>>> manageable, as they can just say that they approve of the overall change, >>>> without also marking every file they own as reviewed (and all that >>>> implies). >>>> >>>> On Thu, Jul 28, 2022 at 7:34 AM 'Matt Menke' via blink-dev < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Jul 28, 2022 at 10:29 AM Ali Juma <[email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 28, 2022 at 6:07 AM Kentaro Hara <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Thanks all for the input! >>>>>>> >>>>>>> Dana: >>>>>>> >>>>>>>> This list includes per-file owners, did the script look for 100 CLs >>>>>>>> in those files named by the rule when deciding to remove the person? >>>>>>> >>>>>>> >>>>>>> Thanks for pointing this out! I'll exclude per-file owners from the >>>>>>> list for now. >>>>>>> >>>>>>> Peter: >>>>>>> >>>>>>>> I'm worried that this process excludes/penalizes folks who may be >>>>>>>> OOO for extended leave (incl long stretches of parental leave, >>>>>>>> bereavement) >>>>>>>> and have that in their Gerrit status. This should not be a source of >>>>>>>> review >>>>>>>> latency, if it is Gerrit should better surface that they are OOO. >>>>>>>> Are any of the inactive owners, who did opt out last time, a source >>>>>>>> of review latency? I.e. are reviews assigned to them but they don't >>>>>>>> review >>>>>>>> them within some SLO window? Otherwise I strongly suggest we let folks >>>>>>>> decline the OWNERS removal (at other OWNERS' discretion who should >>>>>>>> probably >>>>>>>> review removal CLs). >>>>>>> >>>>>>> >>>>>>> I think Glen covered this topic very well. As written in this >>>>>>> guideline >>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#expectations-of-owners>, >>>>>>> owners are expected to be an active contributor to the directory ("Have >>>>>>> the >>>>>>> bandwidth to contribute to reviews in a timely manner. ... Don't try to >>>>>>> discourage people from sending reviews, including writing “slow” or >>>>>>> “emeritus” after your name."). If you are on an extended leave and >>>>>>> removed >>>>>>> by this process, you can explain it and re-add yourself through the >>>>>>> owner >>>>>>> nomination process. Will it work? >>>>>>> >>>>>> >>>>>> The next guideline >>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#removal-of-owners> >>>>>> (on >>>>>> removal of owners) explicitly excludes owners who are on leave. I don't >>>>>> think we should be adding additional friction for folks who go on leave; >>>>>> the default assumption should be that when they return, they are just as >>>>>> capable of being a good owner as when they left, without them having to >>>>>> re-nominate themselves. >>>>>> >>>>> >>>>> The assumption is not that they're no longer good owners, but that >>>>> people shouldn't have to spend a week waiting on them to reply to a review >>>>> before giving up and trying someone else. Note that owners do not need to >>>>> be nominated - no one is losing their committer status. >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Matt: >>>>>>> >>>>>>>> Maybe it would make more sense to identify OWNERS who are not >>>>>>>> active globally in chrome/, instead of owners not active in a >>>>>>>> particular >>>>>>>> directory? How common are OWNERS active in Chrome, but high latency >>>>>>>> only >>>>>>>> for specific directories? >>>>>>> >>>>>>> >>>>>>> My personal opinion is that owners who made no contributions >>>>>>> globally in the past 6 months *or* owners who made no contribution to >>>>>>> the >>>>>>> directory they own while there were 100+ commits in the past 6 months >>>>>>> can >>>>>>> be identified as inactive owners. >>>>>>> >>>>>>> Note that this is not an irreversible process. When you have a >>>>>>> reason, you can explain it and re-add yourself through the owner >>>>>>> nomination >>>>>>> process. >>>>>>> >>>>>> >>>>> I'm not concerned about the fact that it's not reversible, but wasting >>>>> time. I received ~10 emails from the last mass owners purge, and Not >>>>> LGTMing a bunch of CLs created by a tool following completely opaque rules >>>>> seemed not a productive use of time. >>>>> >>>>> >>>>>> >>>>>>> I'm asking as someone who was recently inundated by auto-generated >>>>>>>> removal CLs, the majority of which did not make sense (admittedly, I >>>>>>>> believe it wasn't based on activity). The tool even seemed to want to >>>>>>>> remove all owners from some directories. >>>>>>> >>>>>>> >>>>>>> Right, the removal tool is not looking at activities, and this >>>>>>> proposed process is different from it. FWIW when I removed ~500 inactive >>>>>>> owners last year, it ended up removing (only) ~10 OWNERS files. So >>>>>>> removing >>>>>>> all owners from some directories will be rare. >>>>>>> >>>>>>> Pavel: >>>>>>> >>>>>>>> The data in the table seems off, what is considered a "review": is >>>>>>>> that a "Code Review +1" or is that any review comment? >>>>>>> >>>>>>> >>>>>>> "Code Review +1" in the git commit log is considered as "review". >>>>>>> >>>>>>> >>>>>>>> I also have an edge case where I'm mostly interested in several >>>>>>>> files in a folder where other files are being changed more frequently, >>>>>>>> should I be optimizing OWNERS to list myself as per-file? >>>>>>> >>>>>>> >>>>>>> This sounds reasonable to me :) >>>>>>> >>>>>>> Glen: >>>>>>> >>>>>>>> I recently tried a similar automated audit of inactive owners - I >>>>>>>> looked for anyone who hadn't reviewed or authored a CL in 12 months >>>>>>>> anywhere, regardless of activity in the directory and found (as list, >>>>>>>> Google internal only) many accounts that no longer exist (or perhaps >>>>>>>> never >>>>>>>> did) in OWNERS. It probably has different false positives than the >>>>>>>> proposed >>>>>>>> set above. Maybe the intersection of the two sets would be sensible? >>>>>>> >>>>>>> >>>>>>> I'm happy to tweak the criteria depending on the conclusion of this >>>>>>> email thread :) >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 28, 2022 at 3:32 PM Glen Robertson <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> > Having your name on OWNERS is an award for your previous amazing >>>>>>>> contributions >>>>>>>> I'm concerned that being in OWNERS is regarded as a reward, and >>>>>>>> being removed as a penalty -- it is part of the problem with cleaning >>>>>>>> up >>>>>>>> inactive OWNERS. I'd much prefer to have a separate "amazing >>>>>>>> contributors" >>>>>>>> file to list people who have made amazing contributions, without this >>>>>>>> affecting the code review process. >>>>>>>> >>>>>>>> Owners are supposed to be >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#expectations-of-owners> >>>>>>>> active reviewers for a directory. I'd even expect us to remove people >>>>>>>> who >>>>>>>> go on long leave, unless Gerrit can understand that status and avoid >>>>>>>> suggesting them for reviews (currently it does not do that well). >>>>>>>> Re-adding >>>>>>>> an owner is not an arduous process, but adding days to a code review >>>>>>>> is a >>>>>>>> significant cost. >>>>>>>> >>>>>>>> I recently tried a similar automated audit of inactive owners - I >>>>>>>> looked for anyone who hadn't reviewed or authored a CL in 12 months >>>>>>>> anywhere, regardless of activity in the directory and found >>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3750667> >>>>>>>> (as list, Google internal only >>>>>>>> <https://docs.google.com/spreadsheets/d/1BWvj44vJUjSXUHI85fJwX8AgIoYR5SkAm378pp80ljw/edit?resourcekey=0-7pInBE4h65x3c5t6Af1hbA#gid=0>) >>>>>>>> many accounts that no longer exist (or perhaps never did) in OWNERS. It >>>>>>>> probably has different false positives than the proposed set above. >>>>>>>> Maybe >>>>>>>> the intersection of the two sets would be sensible? >>>>>>>> >>>>>>>> On Thu, 28 Jul 2022 at 07:45, Pavel Feldman <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> The data in the table seems off, what is considered a "review": is >>>>>>>>> that a "Code Review +1" or is that any review comment? >>>>>>>>> I also have an edge case where I'm mostly interested in several >>>>>>>>> files in a folder where other files are being changed more frequently, >>>>>>>>> should I be optimizing OWNERS to list myself as per-file? >>>>>>>>> >>>>>>>>> On Wednesday, July 27, 2022 at 2:16:47 PM UTC-7 Matt Menke wrote: >>>>>>>>> >>>>>>>>>> Maybe it would make more sense to identify OWNERS who are not >>>>>>>>>> active globally in chrome/, instead of owners not active in a >>>>>>>>>> particular >>>>>>>>>> directory? How common are OWNERS active in Chrome, but high latency >>>>>>>>>> only >>>>>>>>>> for specific directories? I'm asking as someone who was recently >>>>>>>>>> inundated >>>>>>>>>> by auto-generated removal CLs, the majority of which did not make >>>>>>>>>> sense >>>>>>>>>> (admittedly, I believe it wasn't based on activity). The tool even >>>>>>>>>> seemed >>>>>>>>>> to want to remove all owners from some directories. >>>>>>>>>> >>>>>>>>>> On Wednesday, July 27, 2022 at 5:03:05 PM UTC-4 [email protected] >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I echo Dana's concern about removing per-file owners and would >>>>>>>>>>> like to see that policy rethought. Agree with Peter's observations >>>>>>>>>>> as well. >>>>>>>>>>> >>>>>>>>>>> -Ken >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Jul 27, 2022 at 9:12 AM Peter Boström < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> I'm worried that this process excludes/penalizes folks who may >>>>>>>>>>>> be OOO for extended leave (incl long stretches of parental leave, >>>>>>>>>>>> bereavement) and have that in their Gerrit status. This should not >>>>>>>>>>>> be a >>>>>>>>>>>> source of review latency, if it is Gerrit should better surface >>>>>>>>>>>> that they >>>>>>>>>>>> are OOO. >>>>>>>>>>>> >>>>>>>>>>>> Are any of the inactive owners, who did opt out last time, a >>>>>>>>>>>> source of review latency? I.e. are reviews assigned to them but >>>>>>>>>>>> they don't >>>>>>>>>>>> review them within some SLO window? Otherwise I strongly suggest >>>>>>>>>>>> we let >>>>>>>>>>>> folks decline the OWNERS removal (at other OWNERS' discretion who >>>>>>>>>>>> should >>>>>>>>>>>> probably review removal CLs). >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Jul 27, 2022 at 8:08 AM <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>> This list includes per-file owners, did the script look for 100 >>>>>>>>>>>>> CLs in *those files* named by the rule when deciding to >>>>>>>>>>>>> remove the person? >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Jul 26, 2022 at 9:16 PM Kentaro Hara < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>> Hi >>>>>>>>>>>>>> >>>>>>>>>>>>>> As of 2022 July, Chromium has 4531 OWNERS files containing >>>>>>>>>>>>>> 6850 names. These include inactive owners, which are one of the >>>>>>>>>>>>>> sources of >>>>>>>>>>>>>> slow code review latency. One year ago, we cleaned up >>>>>>>>>>>>>> inactive owners >>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/g/chromium-dev/c/MpOgk56qKS0/m/HHy7G19oAwAJ> >>>>>>>>>>>>>> and removed ~500 inactive owners. I propose running the clean-up >>>>>>>>>>>>>> process >>>>>>>>>>>>>> again to keep the OWNERS files updated. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Specifically, a person is identified as an "inactive" owner >>>>>>>>>>>>>> iff: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - >>>>>>>>>>>>>> >>>>>>>>>>>>>> The person didn't commit or review any CLs in the >>>>>>>>>>>>>> directory they own while there were 100+ CLs that touched the >>>>>>>>>>>>>> directory in >>>>>>>>>>>>>> the past 6 months (as of July 6, 2022). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Last year, I gave the inactive owners an option to flip the >>>>>>>>>>>>>> decision manually to stay as an owner, but for this cycle, I'm >>>>>>>>>>>>>> planning to >>>>>>>>>>>>>> remove the inactive owners unconditionally. The rationale is 1) >>>>>>>>>>>>>> if the >>>>>>>>>>>>>> person made no contribution on a very active directory for 6 >>>>>>>>>>>>>> months, it >>>>>>>>>>>>>> will be reasonable to say that the person is inactive, and 2) if >>>>>>>>>>>>>> there is >>>>>>>>>>>>>> any special reason for it and the person needs to stay as an >>>>>>>>>>>>>> owner, the >>>>>>>>>>>>>> person can show evidence that they are meeting the owners >>>>>>>>>>>>>> expectations >>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#expectations-of-owners> >>>>>>>>>>>>>> and be readded through the standard OWNERS nomination process. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Specifically, people listed in this spreadsheet >>>>>>>>>>>>>> <https://docs.google.com/spreadsheets/d/1gJbXzTaoITvCDmQaqMmGCvfOngrcFtMPmMsGhHgEV_4/edit#gid=0> >>>>>>>>>>>>>> are identified as inactive owners and will be removed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I understand this is a tricky proposal. Having your name on >>>>>>>>>>>>>> OWNERS is an award for your previous amazing contributions, and I >>>>>>>>>>>>>> understand your feeling about your name being removed. However, >>>>>>>>>>>>>> I think >>>>>>>>>>>>>> it's important to keep the OWNERS files updated so that Chromium >>>>>>>>>>>>>> developers >>>>>>>>>>>>>> can find active owners and improve the code review latency. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you have any questions / concerns, please let me know. >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Kentaro Hara, Tokyo >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>>>> >>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyArLjDp0ixPu%2BCSZ9NVrn0M1GwNFiJqiPGRE1f0mrbfQ%40mail.gmail.com >>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyArLjDp0ixPu%2BCSZ9NVrn0M1GwNFiJqiPGRE1f0mrbfQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>> . >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> -- >>>>>>>>>>>>> Chromium Developers mailing list: [email protected] >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> View archives, change email options, or unsubscribe: >>>>>>>>>>>>> http://groups.google.com/a/chromium.org/group/chromium-dev >>>>>>>>>>>>> --- >>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>> Google Groups "Chromium-dev" group. >>>>>>>>>>>>> >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHtyhaTNC4tgQbqbUq%2BQdFfcORr3aFobjgbeE%2BTaVf7eDgU2Bg%40mail.gmail.com >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHtyhaTNC4tgQbqbUq%2BQdFfcORr3aFobjgbeE%2BTaVf7eDgU2Bg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> -- >>>>>>>>>>>> Chromium Developers mailing list: [email protected] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> View archives, change email options, or unsubscribe: >>>>>>>>>>>> http://groups.google.com/a/chromium.org/group/chromium-dev >>>>>>>>>>>> --- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "Chromium-dev" group. >>>>>>>>>>>> >>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAGFX3sFB9G8R2MyHT6rjVtEFRAKMeyCTH6Yu0DYqUOfLPCxCBw%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAGFX3sFB9G8R2MyHT6rjVtEFRAKMeyCTH6Yu0DYqUOfLPCxCBw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "blink-dev" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0a2a01e2-652b-4e31-895c-f020e7b46358n%40chromium.org >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0a2a01e2-652b-4e31-895c-f020e7b46358n%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Kentaro Hara, Tokyo >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "blink-dev" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyCNN1%3DpfT%3DCWPmc4%2Bi9PmGs-%3DbX9e2mUi2bHthF%2B0w-w%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyCNN1%3DpfT%3DCWPmc4%2Bi9PmGs-%3DbX9e2mUi2bHthF%2B0w-w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvr5vjo0FdbYepkOLBDGJN7KLivmauf4G-HQ1rf67f7pSQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvr5vjo0FdbYepkOLBDGJN7KLivmauf4G-HQ1rf67f7pSQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> > > -- > Kentaro Hara, Tokyo > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jwB528AFfwArSHLKoHWeWt-JOvCS0dnFJNaDycKSc5GDw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jwB528AFfwArSHLKoHWeWt-JOvCS0dnFJNaDycKSc5GDw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg8WJ0PBAWhtRm0eyJhAw%2Bn28P%2B4GWgu2dMnpes9zPJchA%40mail.gmail.com.
