►
From YouTube: 2021-03-10 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).
A
B
Hey
yeah,
I
I
I
just
want
to
be
sure
that
everyone
joins
the
right
meeting.
B
Yeah,
I
I
I
always
afraid
of
the
the
change,
but
we
have
to
do
it.
You
know
the
unfortunate
thing
is
that
how
the
the
thing
works
is
that
they
have
a
a
limited
set
of
zoom
ideas
for
meetings,
and
I
had
to
change
that
because
there
was
another
team,
the
php
already
using
the
same
time.
You
know.
D
E
F
B
A
B
G
B
Okay,
so
yesterday
zach
and
I
took
time
to
kind
of
go
over
what
were
the
the
changes
in
open
telemetry
that
perhaps
data
dog
want
to
pull
and
then
later
we
we
have
some
follow-up
on
that.
So
those
should
keep
the
integrations
easy
and
it's
good
stuff.
In
general,
there
is
a
bunch
of
pr's,
but
I
think
everyone
is
reviewing.
E
It
might
be
good
for
a
quick
discussion
just
so
that
I'm
understanding
the
scope
of
it.
There's
the
adding
the
hotel
span
status
and
how
errors
are
handled
in
hotel
in
general,
and
so
I
just
want
to
see
if
I
have
the
same
understanding
as
everyone
else.
E
Okay,
so
in
in
that
pr,
so
I'm
noticing
that
we're
explicitly
setting
the
error
status
in
some
cases,
and
it
was
my
understanding
that
it's
up
to
the
the
user
to
determine
if
something
is
truly
an
error.
So
just
because
an
exception
was
caught.
That
doesn't
necessarily
mean
that
the
span
has
an
error,
and
so
that's
where
I'm
not
sure
where
we
stand
with
auto
instrumentation
setting
the
error
status.
G
The
approach
that
I've
been
using
for.
B
For
auto
instrumentation
in
this
case
is
kind
of
in
general.
I
I
start
with
its
error,
in
case
of
exception,
for
auto
instrumentation,
but
to
be
fair,
I
have
a
few
requests
also
to
make
that
an
option
of
the
tracer,
because
it's
the
usual
thing
you
know
for
some
people
want
to
see
the
300
400
as
errors.
Other
people,
don't
you
know
right
so
the
starting
point.
B
The
default
is
typically
to
really
have
setting
as
error,
but
yeah
in
the
end,
people
end
up
adding
our
options,
so
I
I
think
from
the
pr
perspective,
I
I'm
fine
with
setting
the
error
by
default,
because
it's
a
decision
by
the
auto
instrumentation,
but
I
think
some
moment
down
the
line
and
we
can
open
a
issue
a
red
to
track
that.
B
But
I
think
eventually
we
end
up
having
to
have
our
option
to
control
that
okay.
E
B
Yeah
yeah:
this
is
something
that
in
the
list
that
we
have
for
splunk
folks
to
do
it's
adding
the
capability
of
events
and
then,
on
top
of
that,
adding
the
capability
to
record
the
exception.
Following
the
semantics.
You
know
for
hotel,
you
know,
but
but
but
we
are
going
step
by
step.
So
now
is
just
the
status.
E
And
then
the
other
thing
that
I
saw
in
the
pr
was
that
we're
still
setting
some
additional
error
attributes
or
not
attributes
but
tags,
and
so
that's
where
I'm
wondering
if
this
is
another
place
where
we
need
to
introduce
that
intermediate
layer
where
we
have
the
the
differing
semantic
conventions,
because
I
don't
think
spans
have
error
message
tags
it
just
has
the
hotel
status
and
hotel
description
yeah.
I
think.
B
So
I
think
so
so
this
the
the
I,
I
think
the
pr
is
changing
that
for
the
exporters
right.
So
they
follow
the
convention
that
we
have
for
zipking
right
now,.
B
H
Just
one
thing
guys-
and
this
is
more
of
a
high
level
thing-
and
I
may
be
wrong
on
this
one-
it's
just
a
hunch,
so
please
feel
free
to
disagree.
It's
like
when
we
add
so
open.
H
Telemetry
has
a
bunch
of
recommendations
for
for
how
to
you
know
for
for
what
should
be
supported,
but
we
can
make
selective
choices
about
whether
we
use
all
of
these
features,
like
you
know
all
of
these
events
and
so
on,
for
example,
if
if
there
is
something
that
we
some
real
world
occurrence
that
we
really
feel
there
is,
this
is
by
far
the
best
way
to
record
that
way.
Then
sure
right.
H
The
thing
is
the
reason
why
we
might
so
so
because
open
telemetry
right,
so
we
we
want,
we
will
have
many
different
exporters,
but
in
terms
of
the
internal
like
tags
on
the
span,
we
already
have
true,
and
maybe
we
have
more
of
it
since
we
already
have
an
abstraction,
but
we
probably
want
to
have
fewer
of
those
than
exporters
because
it
becomes
too
complicated
and
whatnot.
H
So
not
all
exporters
might
support
all
features,
because
not
all
beckons
might
support
all
features
right.
You
know
some
some
guys
might
like
support
events.
I'm
not
it's
just
an
example
right,
so
I
would
be
selective.
Some
more
advanced,
open,
telemetry
features
around
spence,
especially
some
new
ones.
H
H
So
if,
if
we
are
forced
to
kind
of
come
up
with
a
new
special
magic
tag,
name
where
open
telemetry
already
has
a
concept
for
it,
then
of
course
we
should
be
using
the
open,
telemetry
concept,
but
in
cases
where
it's
not
the
case
where
we
just
like
use
events
for
the
sake
of
using
events
where
we
don't
need
you,
I
would
like
you
know,
think:
do
we
really
need
this.
E
Yeah,
so
one
of
the
things
that
I'm
nervous
about
is
so,
if
we're
adding
information
as
tags
to
spans
internally
and
then
we're
relying
on
each
exporter
to
be
able
to
filter
out
the
set
of
tags
that
it
cares
about,
it
seems
like
that
could
be
complicated
if
we
ever
start
supporting
custom
tags.
B
B
So
the
thing
that
I
was
mentioning
about,
for
instance,
we
carry
the
logical
status
as
open
telemetry,
but
the
zipping
exported
doesn't
have
a
way
to
express
that
so
open
telemetry
defines
in
the
specification
how
that
should
be
translated
by
zipking,
and
so
so.
Basically,
what
we,
I
think,
the
thing
we
we
should
focus
is
keeping
the
open
telemetry
span
abstraction
it
should
satisfy
the
specification
and
the
exporters
should
follow.
Also
the
transformation,
as
defined
in
the
specification.
B
You
know
so
the
logical
model
it's
there
and
it
should
align
even
when
we
eventually
get
to
activity
it's
gonna
align
because
of
that
and
the
exporters
follow
already
pre.
I
specified
the
way
to
make
the
translation.
H
I
think
you're
right
and
I
just
realized
yes
you're,
very
right,
and
it,
if
I
understand
you
correctly
and
please
correct
me
if
I'm
wrong,
this
set
setup,
sets
us
up
for
a
risk
mitigation
for
a
potential
future
possibility
that
using
activities
turns
out
to
be
not
acceptable
from
the
perspective
of
performance,
because,
if
in,
if
like,
if
we
like
you
know
right
now,
we
did
the
diagnostic
source
work
that
we
discussed
last
week,
but
we'll
put
it
into
the
product.
H
We
will
mature
it
and
then
at
some
point
we'll
be
ready
to
try
those
activities
and
then
we
will
prototype
it.
And
then
we
will
discover
either
in
terms
of
runtime
performance
it's
good
or
acceptable.
H
Then
we
just
switch
to
activities
and
we're
in
a
good
place
right
or
we
realized
that
the
like,
because
you
know
some
kind
of
runtime
performance
is
too
much
impact.
So
we
cannot
switch
to
activities
and
in
that
case,
what
do
we
do
because
we
want
to
be
like
open,
telemetry
conformant.
H
That
essentially
has
a
autel
conform
standard
layer
on
top
of
on
top
of
our
expanse
here,
and
I
I
prefer
this
not
to
happen,
I
prefer
us
to
actually
be
able
to
use
activities.
I
very
strongly
prefer
that,
but
it
could
be
a
potential
risk
mitigation.
B
Yes,
no,
I
I
I
agree
with
that,
because
the
way
for
us
to
to
start
to
migrate
is
really
to
observe
the
open,
telemetry
semantic
specification,
and
to
do
that,
we
need
to
perhaps
add
some
attributes
to
the
span
that
we
have
in
the
tracer,
but
it
should
be
logically
equivalent
to
activity.
You
know
we
should
be
able,
for
instance,
we
I'm
not
saying
to
do
this,
but
we
should
be
able,
in
theory,
to
write
the
following:
translate
from
the
expand
to
activity
and
then
pick
up
any
exporter
that
exists
for
the
dotnet
sdk.
B
B
You
know
if
somebody
wanna
write
that
converter
from
spencer
active
just
to
track.
I
I
I'll
be
pleased
to
have
like
not
shipping,
but
in
the
ripple.
H
I
agree
and
I
think
getting
there
may
not
be
a
prerequisite
for
release
because
we
may
not
need
all
of
it,
but
I
think
we
definitely
should
be
on
on
the
track
there
and
we
may
not
get
like
be
a
hundred
percent
there
at
some
point
where
we
decided
to
release,
but
as
a
as
a
approach
vector,
I
think,
agree
completely.
B
All
right,
so
I
I
actually.
This
came
from
a
question
from
chris
on
api
and-
and
I
didn't
look
at
the
details
of
that
pr
specifically,
but
it's
a
very
good
question
and
I
think
I
would
like
to
be
able
to
one
of
us
write
about
because
erasmus
pull
on
his
piacho
added
the
jaeger
he
based
it
on
the
hotel.net
sdk,
and
he
is
bringing
dependence
to
system
memory
and
system
buffers
and
I'm
very
worried
about
bringing
the
dependencies.
B
And
then
I
realized
that
we
don't
have
this
written
anywhere.
To
kind
of,
I
know
that
this
is
just
the
recommendation
and
kind
of
if
we
get
to
a
point
that
you
guys
upstream
decide.
Oh,
we
are
gonna
bring.
This
dependency
is,
is
up
to
you.
Guys
is
upstream.
There
is
no,
but
I
would
like
to
have
this
written
kind
of
in
a
way
that
people
should
be
aware
kind
of.
Oh,
this
is
okay.
This
needs
approved
from
the
sig.
B
You
know
to
happen,
you
know,
so
if
you
guys
need
to
prepare
something
to
discuss
that,
we
we
can
schedule
for
next
wednesday,
but
if
you
guys
could
prove
provide
overview
that
perhaps
serves
the
basis
for
one
of
us
to
write
and
put
in
the
repo
as
part
of
the
dev
documentation
kind
of
so.
H
B
Because
when
he
took
the
code
and
moved
to
the
span
instead
of
the
activity,
the
original
package
already
have
this
dependence
since
he's
new
to
the
project
he
he
he
brought
the
reference
to
the
new
the
to
the
new
get
packages
as
it
was
on
the
sdk
fork,
but
I
know
that
we
are
very
careful
about
bringing
the
dependencies.
So
that's
why
I'm
trying
to
establish
this
kind
of
apollo's
kind
of?
B
Oh,
perhaps
the
policy
is
no
dependency,
is
okay,
but
I
would
like
to
to
have
something
written
and
perhaps
kind
of
the
thing.
Oh,
if
you
are
going
to
bring
this
kind
of
dependence,
this
is
the
way
to
do
or
if
you
are
going
to
bring
this
kind
of
dependence,
you
need
to
talk
with
the
sig
before
even
consider
it.
You
know
kind
of.
H
Thank
you
for
bringing
this
up.
I
completely
agree
and
based
on
the
experience
that
we
went
through
in
in
focusing
on
the
availability
of
the
tracer
over
the
last
year,
I
would
say
the
same
thing,
but
even
much
stronger.
Basically,
of
course,
this
is
engineering.
At
the
end
of
the
day,
we
are
creating
solutions,
and
if
there
is
a
good
reason
to,
should
you
change
our
policy,
then,
of
course
we
should
change
policies
right,
but
generally,
I
would
say
no
dependency
is
okay.
H
We
have
like
we
the
the
work
for
diagnostic
stores.
Just
did
it
like
in
order
to
not
have
a
dependency
on
diagnostic
source,
which
is
a
very
common
library
right.
We
just
went
through
this
huge
exercise
of
stabbing
up
these
these
apis
and
if,
if
we
you.
H
Of
course
we
can
it's
just
that
like
right
now,
for
example,
with
datadog,
we
are
not
able
to
monitor
any
food.net
framework
application
diagnostic
sources,
because
we
have
not
yet
incorporated
this
new
technology
from
last
week
into
the
product.
Essentially,
no
dependency
is
possible
and
we
spend
a
lot
of
death
cycles.
H
If
you
follow
the
changes
over
the
last
year,
we
have
spent
a
lot
of
cycles
ripping
out
every
possible
dependency
that
that
existed
out
of
the
product,
because
for
every
single
one
of
them
there
is
one
or
more
actual
real
support
cases
where
there
was
a
crash
at
customer
side.
B
I
see
I
see
so
in
in
in
that
sense,
even
if,
for
things
like
system
memory
and
system
buffer,
that
typically
being
stuff,
that
performance
wise
is
helpful
or
the
trade-off
is
done
in
the
sense
kind
of
okay.
We
don't
have
that
feature
and
you
should
live
without
it.
H
Correct
so
there
is,
there
is
something
that
we
do
is.
Of
course
we
have
these
different
compilation
flavors.
So
when
we
compile
against,
I
think
the
newest
one
is
net
core
3.1.
If
I'm
not
remember
correctly
and
then
so.
Some
features
that
are
part
of
the
dot
net
core
31,
then
that
build
flavor
that
targets
it
can
use
those
features.
And
then,
if
we
like
every
time,
we
would
like
to
use
those
features.
H
We
kind
of
look
at
the
complexity
trade-off
and
if
we
think
that
this
is
really
worth
it,
then
we
use
those
features
in
the
target
like
we
use,
if
devs,
essentially
to
create
code.
That
makes
us
takes
advantage
of
those
features
for
net
core
3.1
and
uses
something
else
that
is
available
in
other
framework
versions
for
other
flavors
and
and
we
never
bring
in
a
nuget
into
an
older
version
to
use
an
api
that
wasn't
available
there.
Never
ever,
and
I
think
every
time
this
was
there
was
an
exception.
E
E
H
It's
it's
it's
it's
whether
you
we
prefer
grouping
the
source
code
if
it's
allowed
that
instead
of
io
repack,
because
I
think
it's
just
better
to
work
with
the
source
code
that
allows
us
to
make
a
choice
to
maybe
rip
out
some
of
it
and
modify
it.
It
depends
on
the
license
as
well,
but
I
don't
think
we
I
ever
eat
back
anything
right
now.
H
We
should
really
consider
the
maintenance
complexity,
though,
if
so,
if
somebody
wanted
to
to
a
vendor
in
memory
like
system
memory,
I
would
expect
a
a
set
of
performance
tests
that
show
that
this
is
a
clear
actual
advantage
rather
than
saying.
Oh,
this
is
good
for
performance.
Let's
do
it,
but
rendering
is
okay,
because
that
doesn't
create
this.
This
versioning,
as
long
as.
F
Like,
for
example,
message
pack
was
something
that's
how
we
send
information
to
our
our
agents
and
if
we
upgraded
past
a
certain
version,
it
started
to
assist
in
memory,
so
we
actually
had
to
hold
off
on
upgrading
for
a
bit
until
we
figured
out
how
to
work
around
that.
So
one
of
the
telltale
signs
is,
if
you
we,
we
have
different
build
tools
in
our
in
the
repo.
One
of
them
is
the
packaging
for
the
msi
and
so
on
on
disk
and
the
repo.
B
Flag
cool,
so
I
I
think
one
one
thing
you
should
avoid
bringing
independence
is
the
general
rule
of
thumb.
The
second
is:
if
you
want
to
bring
for
performance
reasons,
you
will
have
to
have
the
data
and
then
the
preferred
method
to
do
is
rendering,
and
I
think
we
should
stop
there
anything
else.
F
Yeah-
and
I
think
it's
also
worth
writing
down-
is
all
what
greg
said
about.
If
you
want
to
use
new
framework,
libraries
or
apis,
if
they're
built
in
then
we
can
basically
yeah
compile
them
for
that
framework
only
and
take
advantage
of
those
performance
ones
like
system
memory,
but
otherwise
yeah
the
rest
of
that
flow
sounds
sounds
right.
E
I
feel
like
we
might
start
running
into
more
and
more
problems,
especially
with
dot
net
five,
since
people
can
build
a
self-contained
app
and
a
basically
cut
out
pieces
of
the
framework,
and
so
I
suspect
some
of
these
headaches
will
likely
creep
up
again.
E
H
Yeah,
actually,
this
is
another
thing
that
yeah,
so
that
that
would
be
a
general
problem
for
tracers
right
and
I
think,
some
a
conversation
to
start
with
microsoft.
For
us
as
a
group
in
some
sort
of
foreseeable
future
is
how
do
we
avoid
this,
like
you
know,
because
microsoft
is
interested
in
in
apm
vendors
to
be
successful
right
because
they
want
dotnet
applications
to
be
monitored
in
a
good
way.
H
So
we
need
to
maybe
have
some
sort
of
good
conversation
with
their
design
team
about.
How
do
we
make
sure,
as
a
tracer
vendor,
to
solve
this
problem?
We
can't
bring
in
dependencies,
but
we
need
to
rely
on
some
dependencies
always
being
there.
How
do
we
make
sure
that.
F
If
I
recall
there
was
a
conversation,
I
think,
in
terms
of
a
issue
on
the
don
at
runtime
repo,
discussing
basically
a
base
set
of
apis,
that
the
the
il
trimming-
I'm
sorry,
the
linker,
forgetting
all
the
terms
would
not
trim
out
of
the
application
and
that's
probably
a
good
place
to
carry
this
conversation
on
and
yeah.
I
think
this
party,
the
sig
and
microsoft,
would
have
a
really
productive
conversation.
There.
B
Yeah,
I
think
I
think
we
dave
is
not
here
today,
but
and
I
I
think
that
actually
we
should
kind
of
prepare
the
questions.
You
know
in
a
more
targeted
way
and
perhaps
ask
for
his
help
on
that
regard.
H
Dave
also,
he
will
certainly
be
able
to
point
us
to
the
right
people,
but
he
is.
He
is
the
profiler
guy
right,
so
yeah
he's
not
the
framework
guy,
so
his
colleagues
from
esteem
are
probably
the
the
best
people
to
have
a
conversation
with,
because
he
is
probably
just
like,
coincidentally
aware
of
this,
rather
than
being.
H
H
Do
you
have
a
link
to
that
discussion?
Maybe
if
you
do.
B
So,
switching
gears
here
is
something
because
we
mentioned
diagnostics,
and
this
came
to
my
mind.
The
collector
keeps
implementing
the
the
feature
to
collect
metrics
via
event
pipe,
and
I
think
that
is
advancing
great
is
not
merged
yet,
but
I'm
gonna
see
if
I
get
the
author
to
do
a
demo
for
us
when
the
feature
is
merged
on
hotel
contrib.
You
know,
because
I
think
it's
for
the
net
ecosystem
is
something
very
nice
to
have
a
way
to
collect
all
these
metrics
from
any
kind
of
platform.
B
All
right,
so
the
next
thing
is,
I
think
that
robert
mentioned
about
the
increasing
the
size
of
the
git
repository.
B
I
think
it
is
very
interested
in
reducing
the
size
of
the
the
git
repository,
but
the
problem
is
that
we
also
have
to
purge
that
from
the
history
right,
so
there
are
ways
to
do
targeted,
but
I
think
this
this
needs
the
the
cooperation
between
data
dog
and
us
to
get
that
right.
I
think
I
I
don't
know
if
he
talked
to
tony
I
I
saw
a
long
thread
on
his
leg,
but
I
didn't
dive
in
the
tread.
B
Because
when
the
git
parser
tests
were
built,
they
increased
the
size
of
the
the
git
hippo
quite
a
lot,
because
it
it
brings
ripples
inside
the
ripple
of
binary
data.
B
So
the
idea
that
I
think
they
are
discussing
is
just
to
reduce
that,
so
they
keep
the
tests,
but
it's
something
that
doesn't
increase
the
size
of
the
the
git
by
so
much.
I
I
wish
robert
was
here
to
discuss
that,
but
that's
my
understanding
of
the
problem.
B
So
so
I
think
this
is
something
that,
as
I
said,
I
didn't
dive
into
the
thread,
but
I
I
just
quickly
answered
it
seems
that
they
are
agreeing
what
should
be
done,
and
I
think
it's
just
a
matter
of
coordinating
between,
I
hope
is
not
a
lot
of
work
for
the
guys,
but
I
think
we
also
need
to
coordinate,
because
we
want
to
then
fetch
and
immediately
get
the
the
smallest
git
because
of
the
history
and
these
things.
B
If
you
have
branches
that
may
complicate
things,
you
know
if
you
have
blanches
on
the
fly,
but
once
more,
I
didn't
dig
deep
in
the
thread.
Maybe
I'm
I'm
just
represented
at
high
level
what
they
talking
about.
F
Perhaps
one
thing-
and
I
am
wondering
what
the
the
community
roles
for
for
this
repo,
because
I
I
would
like
to
move
to
a
maintainer
status
and
basically
replace
lucas
as
a
maintainer
of
this
project.
And
what
are
the
steps
for
kind
of
proposing
that.
B
So
I
think
it's
contributions
and
you
are
doing
that
reviews
knowledge
of
the
project,
and
I
think
here
we
have
exception,
because
the
the
the
the
re
repository
out
of
us
see
that
about
six
months
ago.
The
work
is
picking
up
now,
so
I
think
we
have
exception
to
move
you
to
a
maintainer
and
I'm
I'm
support
of
that.
Were
you
one
of
the
representatives
from
datadog?
B
You
are
replacing
lucas
so
and
you
are
the
one
that
haven't
been
participate
so
for
me,
makes
total
sense
and
that
I
don't
think
anybody
will
be
opposing
to
that
yeah
all
right.
So
I
start
the
process
to
get
you
as
a
maintainer
may
take
a
week
or
so,
but
I
will
start
that
and
I'll
put
here.
Okay,
thank
you.
H
Eventually,
it's
actually
tricky
because
I,
when
I
first
played
around
with
this,
you
click
on
it
and
then
you
want
it
to
go
away.
So
you
click
on
it
more,
but
it
actually
makes
it
stay
longer.
No.
B
All
right,
then,
thank
you,
everyone.
I
think
it's
time
for
us
to
go.