LGTM3.
-mike
On Wed, Jul 27, 2022 at 6:23 PM Mike Taylor wrote:
> LGTM2
>
> On 7/27/22 8:08 AM, Daniel Bratell wrote:
>
> LGTM1
>
> /Daniel
> On 2022-07-23 02:41, Frank Tang wrote:
>
> It was flip to stage on m105 and try to flip to ship for m106
> R2T for m105 could be found on 1Q2FHx9hBAAJ
>
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
On Thu, Jul 28, 2022 at 6:07 AM Kentaro Hara 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 owne
On Thu, Jul 28, 2022 at 10:29 AM Ali Juma wrote:
>
>
> On Thu, Jul 28, 2022 at 6:07 AM Kentaro Hara 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
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
HI all,
coming back to this thread as discussed a while back.
Summary
‘SharedArrayBuffers’ (SABs) on desktop platforms are restricted to
cross-origin isolated environments, matching the behavior we've recently
shipped on Android and Firefox. We've performed that change in Chrome 92. A
reverse OT
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
LGTM1
--
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/chro
Hey folks,
I'm fine with the OT extension based on the rationale and limits others
have set in this thread, but would like to understand why we aren't
shipping an MVP today and running the rest of these enhancements as
separate OTs/launches to fill in gaps as they stabilise. WebGPU is already
+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 /
c
Not to speak for Corentin, but this last OT extension is needed to get to
that MVP. The API and shading language have required final polishing - in
some ways incompatibly - to create that core around which future
enhancements can be made in a feature-detectable fashion. It's not a fair
characteriza
+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 inactiv
On 28/07/2022 16:33, 'Matt Menke' via Chromium-dev wrote:
> 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 -
13 matches
Mail list logo
