►
From YouTube: 2020-12-08 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
B
I
think
I'm
not
sure
josh
and
max
will
join
yeah.
Let's
wait
for
probably
two
more
minutes
and
then
I
think
my
lead
will
not
join
since
hey
he's
in
a
different
tango.
B
B
I
think
we
probably
can
start
yeah
today.
Hopefully,
since
today's
meeting
will
be
a
quick
one,
and
I
I
only
have
one
question,
but
my
question
is
mostly
for
josh
yeah,
as
he
did
some
work
on
spin,
lock,
some
tuning
and
after
his
change.
I
think
it
is
not
appropriate
to
be
named
as
spin
lock
anymore,
because
it
is
not
something
is
being
there,
but
as
josh
is
not
here,
I
think
I'll
follow
up.
B
And
the
front
from
the
logging
logging
sdk
site
all
the
aprs
under
review.
Now
I'm
wondering
mark
and
karin.
A
Yeah,
so
we
made
the
api
pr
on
friday
and
it
looks
like
you
and
a
couple.
Other
people
took
a
look
at
that
and
coming
up
so
tomorrow
we're
going
to
file
an
ostream
pr
and
in
it
we're
thinking
of
including
a
shared
pointer
change.
So
the
processor,
instead
of
it
using
a
unique
pointer,
it'll,
use
a
shared
pointer
and
then
following
that,
we're
going
to
add
an
injection
pr
to
the
sdk.
A
C
I
the
question
on
mark's
statement,
so
the
question
I
had
there
is:
is
it
okay
to
actually
file
a
shared
pointer
change
and
the
stream
exporter?
C
You
know
pr
in
in
baked
into
one
or
should
they
be
two
different
prs?
I
mean
there
is
a
dependency
on
the
shared
pointer
code
to
be
merged
for
the
old
stream
pr,
but
is
it
I
mean,
should
we
split
it
up
or
do
one.
B
I
think
we're
putting
the
shirt
in
pointer
guitar
into
one
pair
is
fine.
I
think
that
that's
not
a
big
change
right.
Yeah,
no
need
for
separate
clear
on
this
one.
Okay,.
B
Okay
and
therefore
for
the
login
for
the
log
api,
you
just
update
it.
I
thought
you
added
many
utility
functions
like
debug
on
infor
or
warning
functions
there
or
that's
a
new
new
addition
right,
yeah.
A
B
B
D
Yeah,
so
the
o
stream
exporter,
pr
is
the
one
that's
going
to
be
coming
next,
the
simple
processor
has
been
merged
and
the
issues
have
been
flagged
as
like
issues.
In
the,
as
I
mean,
the
to-do's
have
been
flagged
as
issues
for
that.
B
B
C
C
Yeah,
I
think
I
think
tom
in
our,
in
my
conversation
with
riley
and
and
you
I
think,
last
time
we
discussed
right
that
we'd
have
a
triad
session,
so
we
could
just
go.
I
I
mean
I
have
triage
rights
now,
so
I
can
at
least
go
through
the
list,
and
you
know
we
can.
We
can
shortly
again
there's
time-bound,
just
automatic
closing
of
vrs
that
we
can
instrument,
but
there's
also
that
you
know
they're
there
we
could
ping
and
close
so
yeah.
D
C
Maybe
if
we
can
do
a
regular,
like
you
know,
every
second
week
of
the
month,
we
can
review
that
or,
however
you'd
like
to
see
that
we
can
do
that
like
I
can
give
an
update.
D
B
C
Mean
maybe
we
can
just
do
it?
You
know
for
the
end
of
the
year
we
have
in
current
slate,
you
know
and
and
get
everything
up
to
up
to
updated
up
to
date,
and
then
you
know
go
from
there.
B
B
B
C
A
Sure
cool,
oh
yeah,
so
on
the
login
library,
api
update,
so
we're
changing
the
key
value
iterables
for
attributes
and
resources,
and
so
I
changed
it
to
a
shared
pointer,
but
there's
some
talk
on
actually
having
the
log
record
own
the
resource,
whereas
the
shared
pointer
it
doesn't
actually
own
it.
It
just
like
points
to
the
correct
location,
and
so
josh
says
the
log
record
should
actually
own
the
attributes,
since
it's
what's
going
to
be
passed
to
the
processor
and
exporter.
A
A
G
Attribute
types
exposed
on
api,
like
string
you,
for
example,
pdi
save.
G
So
there
shouldn't
be
an
issue
as
long
as
the
original
collection
uses
api,
safe
types
from
the
set
of
things
we
have
in
the
nowhere
std
namespace.
B
I
think
josh,
as
I
mentioned,
we
let
let
the
sdk
on
the
memory
right,
which
means
sdk,
I
pre-allocate
a
number
of
records
and
then
so
in
the
api
side,
we
don't
need
to
worry
about
the
owner
of
the
pointer
yeah.
That's
very
close
to
to
the
idea.
I
I
think
I
I
talked
about
before
like
provides
a
poor
in
sdk,
so
sdk
owns
that
the
memory
and
unfreeze
the
memory
so
there's
no
usual
api
compatibility.
B
Yeah,
I
think
yeah.
That's
one
way
to
do
this.
Yeah
another
way
is
ask
sdk
to
allocate
a
log
record
with
in
the
first
place
right,
so
no
need
to
new
or
provide
a
memory
allocation
allocator
for
sdk
had
a
new
api
to
do
that,
and
the
sdk
can
can
make
a
pool
of
the
network
records
so
no
need
to
actually
intermix
with
the
api
and
hey
for
api,
which
may
cause
fragmentation
on
the
hip.
B
Right
yeah,
I
think
that
there's
a
comment
on
that.
I
think
it
still
hasn't
been
addressed
right
from
george.
That's
a
comment.
I
think
we
can
follow
up
in
that
thread
and
see
which
direction
we'll
go.
B
C
Know
you
can
see
it
now,
okay,
okay,
so
should
we
look
at
pull
requests
first
and
then
issues
or.
C
Okay,
because
our
full
request
list
is
shorter,
so
we
can
at
least
target
that
and
we
have
14
prs
open
right
now.
So
let's
go
through
it
april.
16Th
support
async
networking.
G
Much
has
some
history:
it's
a
non-trivial
change.
Okay,
I
think
I
think
we
all
kind
of
agree
that
it's
a
good
change
to
have.
G
G
I
think
right
now
we
handle
it
in
in
an
interesting
way
like
technically.
We
do
not
have
dependency
on
the
spr
right
now,
for
example,
for
http
based
exporters,
lalit
has
submitted
the
http
client
for
etw.
We
don't
need
async
networking,
I'm
just
trying
to
understand
like,
even
though
it's
a
good
change
to
have.
What
are
the
other
items
that
are
blocked
on
this?
I
don't
think
we
have
any.
G
I'd
personally
focus
on
http
client.
First
frankly,
for
many
scenarios
it
seems
like
there
would
be
other
higher
priority
issues:
yeah
yeah.
C
So
I
guess
the
maintainers
need
to
figure
out.
You
know
what.
G
Yes,
so
it's
more
like,
I
think,
for
a
local
listeners
such
as
fluent
beat
fluent
d
udp
listener.
In
those
scenarios
we
may
need
this
stuff,
but
for
remote
pushing
to
a
remote
cloud
server.
G
We
don't
need
this
per
se
right
now,
because
we
go
with
the
other
http
client
based
approach
right
now,
so
I
guess
maybe,
depending
on
the
need
when
somebody
says
hey,
we
have
that
scenario
where
we
have
agent
listening
and
then
it
accepts
tcp
or
udp
events,
then
this
is
the
pr
that
we
need
to
refer.
C
G
Based
on
my
understanding,
or
at
least
based
on
our
company's
understanding
like
for
microsoft,
I
do
not
think
that
this
is
a
blocker.
C
Yeah,
so
that
that's
that's
fair.
G
Actually
riley
approved
that's
right,
sir.
C
Failing
okay,
then
he
said
he
was
looking
into
it.
Ci
fails
on
this
specific
files,
yeah.
G
G
Rebased,
okay,.
B
G
About
this,
I
I
assume
that
the
person
was
an
intern
and
there
are
no
active
contributions
coming
in
how
about
I
take
the
ownership
of
it.
G
C
And
let
us
know
max
again
mark
or
karen
can
even
take
a
look.
If,
if
you
don't
have
bandwidth
sure.
G
C
G
Discussed
this
one
before
from
what
I
remember,
there
was
an
attempt
to
add
fork
something
in
code,
but
forking
is
a
unix
only
concept.
So
my
proposal
was
to
abstract
it
away
in
a
nicer
way.
But,
for
example
like.
C
G
C
I
should
just
have
another
window
open
here:
okay,
adding
z
pages.
These
seem
like
again
all
pr's
from
the
summer.
G
Let's
try
to
update
it
again,
I
feel
like
I
should
follow
up
on
this
one
as
well,
because
I
was
helping
the
uv
guys
to
to
work
on
this
z
pages
in
general.
G
Yeah,
it's
lower
priority.
It's
an
additional
test
for
a
facility
that
we
have
functioning
yeah.
So
there
will
be
some
merge
issue.
I
know
that
circuit
tools
have
been
refreshed
with
some
fixes
yeah.
So
it's
a
lower
priority.
It's
not
adding
much
functionality,
it's
more
like
verifying
the
feature
that
we
already
have
function.
C
C
G
But
we
should
still
update
and
make
sure
that
the
formatting
that's
declared
right.
F
C
G
One
is
just
one
skip
it
for
now.
I
was
sharing
thoughts
with
the
guys
when
we
worked
on
loading
api,
how
to
flatten
and
flatten
how
to
represent
objects
in
a
flat
lease
and
then
remap
it
back
into
like
deep
nested
structure.
Okay,
good.
C
C
B
G
By
the
way
about
this
formatting
issue
with
zero,
six
13,
in
fact,
we
are
right
now
on
zero.
Six.
Thirteen,
as
I
mentioned
the
tooling,
which
updates
the
most
recent
version
of
c
mac
format.
G
G
So
if
we
are
changing
protobufcy
make,
I
think
it'd
be
best
to
actually
send
in
a
pr
to
open
telemetry
proto.
You
see
what
I'm
saying
it's
like:
it's
gonna
be
in
there
merged
and
once
it's
in
the
air
ripple,
we
update
our
commit
id
to
refer
to
latest
open
telemetry
protocol.
G
G
So
it
it
will,
I
will
take
a
look,
but
it
will
actually
require
the
person
sending
in
the
pr
to
commit
the
protobuf
she
made
to
the
main
line
upon
the
elementary
property.
G
So
it's
like,
otherwise
it's
not
good
anyways,
because
when
we
clone
some
code
from
another
place
and
we
modify
it
locally,
that's
not
the
right
way
to
do
it.
Yep
whenever
we
it,
it
it'd,
be
best
to
actually
submit
the
cmx
script
to
the
main
line
yeah,
and
then
we
keep
tracking
it
in
there
in
the
original
source
of
it.
G
Proto
right,
yes,
so
it's
open,
telemetry,
open,
telemetry,
yeah
I'll
I'll,
send
the
link.
I
can
comment
on
that
pr,
maybe
so
this
next,
you
can
add
you.
G
B
I
think
that
that
ripple
is
language
independent,
so
maybe
probably
we
should
let
some
ads
they
make
to
to
that
ripple.
G
I
see
that
we
already
have
in
that
repo
just
a
moment.
Let
me
confirm
with
you.
G
I
thought
that
there's
something
language
specific
in
it
already
in
english.
That's
why
I
was
thinking
okay,
so
there's
that
make
file
in
there,
which
means
that
there
are
some
make
file
infrastructure
like
for
go,
for
example,
in
there
and
cmake
is
yet
another
build
system,
and
I
think
it'd
be
best
to
integrate.
The
change
in
the
main
line
opens
in
elementary
dash
rotor.
G
C
I
see
okay,
okay
cool,
so
let's
wait
also
for
the
original.
Hopefully,
the
original
creator
can
respond.
Yeah.
G
B
G
Okay,
so
this
one
I'll
update
you
guys
later
today,
I
was
thinking,
I'm
gonna
be
done
with
it.
I
haven't
finished
it.
G
G
G
C
G
Yes,
preferably
from
a
different
company,
so
in
short,
what.
G
In
short,
this
is
a
mechanism
to
send
the
data
using
event
racing
for
windows,
2
and
out
of
proc
agent,
and
we
will
also
follow
up
with
an
example
how
to
implement
that
agent
or
how
to
implement
a
module
for
any
other
agent.
That
would
listen
to
that
etw
flow,
okay,
cool
and
just
as
of
now,
we
are
trying
to
make
it
genetic.
So,
for
example,
if
in
microsoft
scenarios
in
azure,
we
have
some
implementation
of
the
agent
which
will
listen
to
that,
we
do
want
to
democratize
this.
G
B
B
B
G
Yes,
at
least
two
and
preferably
well,
I
guess,
as
a
requirement
strong
require
a
rather
strong
requirement
for
them
to
be
from
different
companies.
D
C
B
Yeah,
this
is
a
simple
way.
I
think
we
can
ignore.
Just
my
update
to
the
document
yeah
it
changes.
Is
there.
C
B
C
C
A
I
haven't
addressed
and
yeah
so
in
the
next
couple
of
days,
I'm
going
to
address
all
of
those,
so
hopefully
it
can
be
merged.
After
that.
C
B
B
C
C
C
Yeah,
because
what
I'd
like
to
do,
there
is
again,
perhaps
we
can
decide
this
time?
What
kind
of
labels
do
you
guys
use
again?
We
have
24
labels.
Are
these
adequate?
We
have
the
standard
ones
across
the
project.
B
C
I
can
go
through
them
and
just
label
them
based
on
and
then
we
can
prioritize
them.
Perhaps
in
the
next.
G
Maybe
we
should
also
have
some
sort
of
stale
stale
board
yeah
yeah
because
well
for
prs.
It's
usually
like
people
are
actually
wanting
to
do
something
for
the
issues.
It's
it's
the
opposite.
It's
like,
yes,
there's
an
issue.
Somebody
is
unhappy,
but
maybe
they
don't
care
in
a
year
and
we
cannot
afford
fixing
it
yeah.
So
we
need
some
sort
of
a
bot.
G
There
are
a
few
which
we
can
review
like
existing
bots,
which
we
can
set
it
up,
which
may
just
say
this
issue
is
still
and
once
no
action
we
just
close
or
if
we
want
to
keep
it
on.
We
comment
on
it
like
no
still,
let's
keep
it
in
our
backward.
Something
like
this.
C
Yes
sounds
good,
that's
a
good
good
session
max.
What's
the
timeline
within
which
a
stale
issue
is
closed
on
the
project
I
mean
it
depends
on
the
project.
B
B
C
C
C
E
Take
a
I'll
take
a
pass
through
them.
I
think
we're
missing
also
a
like
a
tag
that
says
needed
for
ga
to
get
help
us
prioritize
like
work
that
we
think
is
really
important
for
an.
E
C
Absolutely
okay,
I
think
again,
you
know.
D
C
Think
we
have
one
you
do
indeed,
I
think
you
know
right
now,
based
on
the
discussions
that
are
ongoing
for
versioning
and
tagging.
These
labels
might
change
in
the
next
week.
So
again,
I
think
it
might
be
required
for
stable.
You
know
metrics
stable
traces,
stable
logs,
but
I
think
in
in
general.
My
understanding
is
that
the
they're
trying
to
wean
off
the
ga
idea.
E
Fair
enough,
some
some
way
of
indicating
like
these
things,
are
really
needed
to
comply
to
a
certain
level
of
whatever
the
spec.
D
E
And
so
that
give
give
like
new
users
a
a
really
easy
indicator.
As
to
you
know,
these
would
be
the
most
important
issues
to
pick
up.
First,
we
have
this
one
project
out
here:
traces,
api
and
sdk,
and
that
seems
to
have
some
gives
the
user
some
guidance,
but
not
not.
I
don't
think
that
anybody
is
keeping
this
up
to
date.
G
Once
I
think
couple
weeks
ago
about
milestones,
probably
we
need
to
get
that
conversation
going
like
what
the
milestones
are
and
then
we
can
also
assign
milestones
to
issues
then
pretty
much.
The
project
tab
is
going
to
be
functional,
showing
the
fall.
C
G
It
does
need
a
bit
of
follow-up
discussion
like
what
yeah.
C
I
think
I
think
max
what
we
can
do
is
once
we
triage
all
the
issues
and
have
you
know
a
more
well-maintained?
You
know
backlog
then,
and,
and
it's
all
tagged
then
we
can.
I
think
that
will
give
us
the
data
for
building
out
the
milestones
sounds.
G
C
E
G
I
I
can
probably
go
like
over
mine
and
assigned
tags.
What
I
believe
is
right.
We
can
discuss
next
week
because
for
some
of
these,
like,
I
think
these
are
purely
cosmetic
changes
which
are
non-critical
and
should
be
right
away,
tagged
as
low
priority,
and
I
can
follow
up
on
that
and
maybe
for
those
that
I
believe
we
need
to
do.
I
can
bring
it
up
for
next
week.
We
can
go
over.
C
Or
or
we
can,
you
know
kind
of
categorize
to
the
best
of
knowledge
and
then
re-evaluate
them
in
the
meeting
for
like
30
minutes
or
so.
B
C
Okay,
cool,
that's
all
I
I
think
we
covered
anything
else.
B
No,
no
more
from
my
side
any
questions
there.
Anyone
cool.