I specifically disagree with the "for this cycle, I'm planning to remove the inactive owners unconditionally" bit. If you suggest this removal but you defer to local OWNERS to make the call I think that's fine to send out removal CLs for. I would encourage you and/or the reviewers to look at the removed owner's calendar if they're internal and confirm that they've not been on long-term leave.
I don't think that 85/6850 OWNERS entries are a large enough problem to bypass local owner approval for this (i.e. land it unconditionally). If some of them are owners in very active folders and have had a lot of reviews assigned to them, sure. This is about 1% of ownership entries if I'm understanding this correctly. How badly are they contributing to review latency in order to override "and they are not on a leave during that time" as a policy? I like this policy, and it's supposed to still be the policy. If any of these OWNERS entries had a significant amount of reviews assigned to them during this period (i.e. sorta-evidence of latency), you could use that as additional justification in the CLs to get the OWNERS to approve the (possibly temporary) removal. For fixing review latency which is the real goal presumably, I think handling OOO and load balancing are both more important vectors here. We shouldn't need to get inactive owners down to 0 to solve review latency. On Thu, Jul 28, 2022 at 6:47 PM Kentaro Hara <hara...@chromium.org> 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 <km...@chromium.org> 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 <p...@chromium.org> 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 <km...@chromium.org> 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 < >>>> blink-dev@chromium.org> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Jul 28, 2022 at 10:29 AM Ali Juma <aj...@chromium.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 28, 2022 at 6:07 AM Kentaro Hara <hara...@chromium.org> >>>>>> 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 <glen...@chromium.org> >>>>>>> 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 <pfeld...@chromium.org> >>>>>>>> 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 k...@chromium.org >>>>>>>>>> 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 < >>>>>>>>>>> pb...@chromium.org> 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 <dan...@chromium.org> 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 < >>>>>>>>>>>>> har...@chromium.org> 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 blink-dev+...@chromium.org. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> 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: chromi...@chromium.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 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 chromium-dev...@chromium.org. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 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: chromi...@chromium.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 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 chromium-dev...@chromium.org. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 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 blink-dev+unsubscr...@chromium.org. >>>>>>>>> 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 blink-dev+unsubscr...@chromium.org. >>>>>>> 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 blink-dev+unsubscr...@chromium.org. >>>>> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGFX3sE_2jRGJsADV3UVBDe04-1Yc%3D5Tqy0wcTVu9WAEec7itg%40mail.gmail.com.
