►
From YouTube: 2021-02-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
C
So
yeah,
by
the
way,
if
you
guys
are
here,
do
you
think
I
mean?
Probably
not
if
you
ask
me,
but
do
you
think
we
should
wait
for
14
16
to
get
in
in
the
specs.
C
A
C
C
Essentially,
is
that
and
probably
nobody
commented,
but
probably
one
of
you
should
comment
to
me
that
we
have
not
defined
what
is
the
behavior
and
probably
the
behavior
could
be
drop
after
the
limit
or
or
use
a
first
in
first
out
approach,
but
I
think
that
should
be
kind
of
defined.
What
the
what
the
approach
is
or
just
say
that
the
behavior
is
implementation,
detail.
B
Yeah,
I
would
go
with
the
second
if
we're
just
trying
to
to
clarify
an
environment
variable
that
sets
the
limit.
I
think
that's
like
I
don't.
I
don't
think
anyone
there's
any
debate
about
that
right.
C
Yeah
but
yeah
so,
but
there
was
a
debate
that
people
were
complaining
that
there
is
not
clear
specification
for
how
these
variables
should
be
set
and
how
is
the
configuration
look
like
and
that's
what
we
added,
but
we
did
not
define
the
behavior
very
well
and
maybe
the
behavior
I
just
added
sentence
that
behavior
is
not
strictly
enforced
by
the
specification
and
we
can.
D
B
B
B
I
I
guess
I
don't
have
a
strong.
These
environment
variables
are
in
place
in
a
bunch
of
places
all.
C
No,
it's
not
the
change
that
the
1000
was
there.
Oh.
C
I
I
don't
know,
I'm
just
telling
you
that
yeah
sorry,
but
I
see
it
in
ruby,
these
guys
and
yeah.
There
is
a
config
thing,
a
trace,
config
thing
in
ruby,
which
we
had
in
java
as
well,
and
we
split
it
into
sampler
and
some
spam
limits
it's
in
python.
It's
in
typescript,
I
see
them.
I
see
them
in
ruby
again,
erlang
so
java.
I
see
them
in
a
bunch
of
places
that.
C
I
think
I
think
it's
fine
to
leave
that
behavior,
as
these
are
the
limits
we
have
not
specified
yet
how
these
and
based
on
anurag
or
your
comment,
I
don't
remember,
which
one
told
me
that
hey
it
is
fine,
because
telemetry
itself
or
the
emitted
telemetry
is
not
stable,
so
we
can
trick
a
bit.
The
behavior.
C
What
do
you
mean
is
new,
oh
attributes
in
the
events,
and,
yes,
that's
that's
kind
of
new
ish,
but
but
for
me
was
like
what
is
the
difference,
if
you,
if
I'm
adding
an
event
with
the
2000
attributes
versus
if
I'm
adding
2000
attributes.
B
Right
yeah,
I.
C
C
But
but
there
may
imply
one
thing
for
the
implementation:
a
bunch
of
implementation
were
inheriting
some
of
the
concepts,
this
concept
from
open
sensors,
which
we
called
trace,
config
an
entire
thing,
which
included
these
limits,
plus
the
sampler,
and
with
this
because
we
define
sampler
as
a
standalone
thing.
These
become
two
different
objects
and
some
of
the
languages
may
have
to
do
a
small
thing
here,
but
I
think
it's
very
minimal,
like
even
it's
just
like
a
an
immutable
object
to
split
it
into
two
objects.
So.
B
C
But
it
would
be
weird
for
some
implementation
to
call
something
trace,
config,
which
includes
only
the
sampler
and
the
limit
and
for
others
to
call
this
limits
and
sampler,
even
though
it
doesn't
matter
if
it's
an
eti
or
whatever,
which
is
called
set
config
because
config-
and
I
think
I
got
this
feedback
from
anurag
or
from
others
from
java.
I
think
ids
generator
is
also
a
config
or
spam.
Processor
is
also
a
config
of
the
the
thing.
So
why
why
these
are
conceived.
C
C
C
Anyway,
I
just
want
to
point
out
that,
because
of
the
previous
pr.
A
C
I
completed
this
what
other
things
on
run?
C
There
was
a
decision
for
the
trace
id
based
samplers
stuff,
because
there
was
a
to
do
there
that
most
likely.
I
added-
and
I
didn't
finish
it.
The
decision
was
that
we
declared
the
implementation
as
being
unstable
or
whatever
it's
not.
C
Users
should
not
rely
on
the
on
a
specific
implementation
should
just
rely
on
the
behavior
that
the
amount
of
percent
the
percentage
of
traces
will
be
sampled.
Not
how
and
we
want
to
clarify
that
we
want
to
to
do
a
better
algorithm
that
is
unified
across
languages
and
stuff,
but
this
comes
probably
gonna
come
next
week
or
something
in
the
next
release
of
specs.
So
so
far
we
don't
have
to
do
anything
on
the
java
side.
We
may
want
to
change
one
method
in
java
side,
but
that's
a
separate
topic
with.
C
C
One
we
can
survive
with
one
one
zero
without
them.
Oh
another
thing
that
we
decide
on
rug
is
we
have
every
first
week
of
the
month,
a
release
of
the
spec?
If,
if
there
were
changes
in
the
spec
every
first
week
of
the
month,
we'll
have
a
new
minor
release.
C
C
We
don't
I
mean,
I
don't
know
it
can
be
today
if
we
don't
want
this
to
happen.
If
we
want
this
to
happen,
it
has
to
be
tomorrow
because
I
think
we
need
this
open
was
this
issue
was
open
after
the
european
time
and
it's
something
that
would
like
the
entire
globe
to
to
see
it
at
least
have
a
chance
to
to
say
something.
C
B
Right
so
maybe
just
just
make
the
the
environment
variable
stable
for
now
and
then
the
code
configuration
everything
else
could
be
come
in
one
one
set,
but.
C
Sorry,
let
me
try
and
find
the
issue,
so
it's
in
1407
in
1407.
C
B
Yeah
I
mean,
I
think
it.
I
personally
think
it's
fine
to
say
like
the
there's,
this
one
environment
variable
everyone's
already
implemented
and
it's
stable,
as
is
like,
because
it's
there
and
we're
not
gonna
ask
people
to
remove
it.
We
just
don't
define
any
details
about
what
it
does
other
than
you
know.
It'll
spans
will
start
getting
dropped.
B
B
Right,
but
couldn't
you
just
leave
it
at
just
right
now,
the
only
thing
anyone
has
implemented
is
spamlin.
So
can
we
just
leave.
C
B
Yeah,
that's
what
I'm
saying
like
just
leave
it
at
the
environment,
variable
level
for
now
and
just
leave
in
the
bit
of
the
definition
here
around
span
limits
saying
that
you
know
like
that.
The
sdk
may
provide
a
way
to
just
be
explicit
that
we,
you
know,
we
don't
define
what
what
happens.
If
you
go
over
the
limit.
B
C
I'm
I'm
adding
this
concept.
This
is
my
main
concern.
Disney
span
limits
right
because
this
name
was
not
anywhere,
so
it
was
just
an
environment
variable
there
were
just
environment
variables
and
the
title
was
limits
on
span
collection
and,
and
there
was
no
object
like
define
that
by
code
you
can
configure
this
using
code.
So,
okay,
so
what
I
did
I
said:
okay,
I
think
this
object
should
be
named
span
limits.
C
That's
my
biggest
concern
that
people
people
any
any
rational
engineer
when
they
see
that
this
is
an
environment.
Variable
will
give
users
code
to
do
the
same
thing
and
we'll
name
it
very
randomly
so
so
I
think
I
think,
right
now
we
are
in
a
better
state
of
leaving
the
variables
out
because
that
forced
people
to
remove
them
and
force
the
to
remove
the
code.
That
does
it
so
we
either
define
the
code
as
well
to
not
end
up
with
a
situation
that
you
call
this
trace.
Config
and
the
other
causes
span
limits.
B
C
B
C
C
And
there
is
another
thing
that
includes
way
more,
like
log
level
sampler,
these
guys
put
an
umbrella
object
on
top
of
all
the
config,
which
is
fine,
like
all
the
entire
config
seems
like
to
have
log
level
sampler
trace,
and
they
call
these
trace.
Parents
seems
like.
B
D
B
C
C
C
I
have
four
out
of
the
seven
pc
members
approving
this,
but
I'm
still
I'm
still
willing
to
to
wait,
probably
until
tomorrow
morning
here
to
to
see
if
europe
has
to
say
something
and
android
will
probably
review
tonight
and
stuff
yeah,
I'm
just
trying
to
please
everyone
and
to
to
find
the
right
thing
and
not.
B
Yeah
well
you're.
The
only
person
that
can
be
pleased
is
riley
right
because
we
said
we
said
we
wouldn't
we
wouldn't
be
delaying
debating
this
stuff,
so
yeah,
let's
just
get
it
in
tomorrow
morning,
if
there's
like,
but
there
just
can't
be
any
kind
of
like
debate
about
it.
That's
like
people
just
have
to
like
think
it's.
Okay.
C
B
C
No,
I
think
everyone
should
configure,
because
otherwise
you
you
may
I
mean
you-
can
put
some
options
like
high
values,
like
a
thousand
that
we
have
defaults
or
whatever
we
have
defaults,
but
I
will
still
configure
if
I
would,
if
I
were
an
application
owner,
I
would
configure
them,
but
with
a
pretty
high
values.
C
B
Oh,
I
think
there
should
be
a
limit.
That's
I'm
not
saying
there
shouldn't
be
a
limit
and
yeah.
I
guess
it
should
be
configurable.
It's
just
it's
more
to
my
mind
if
you're
busting
through
the
default
limits,
it's
a
sign
that,
like
something
is
wrong
somewhere
else,
so
you
should
go
fix
that.
C
B
Important
part
we
we
like
report
this
to
people
and
then
and
that
when
we
report
it
to
people
that
has
enough
information,
they
can
find
what's
actually
doing
it
like.
To
my
mind,
that's
actually
the
the
important
part
like
if
I'm
just
hearing
like
oh
the
span
limits
getting
past
it's
like
or
like
too
many
attributes
getting
added
like
okay.
That
sounds
like
something
I
should
go
fix,
but
like.
C
B
Yeah,
it's!
I
think
that
it's
just
part
of
a
bigger
issue
of
of
like
ensuring
that
we
get
a
lot
of
good
diagnostics
into
our
stuff
in
the
in
the
future,
because,
like
debugging,
your
observability
system
is
like
madness
right.
It's
it's!
It's
like
one
of
the
worst
things
to
try
to
debug.
D
Think
so,
just
one
comment
I
might
have,
though,
is
that
since
we're
adding
those
two
new
limits,
that
might
be
a
bit
much
to
add
too
quickly,
but
like
we
added
the
attributes
per
event,
attributes
first
link
and
I
mean
there's,
for
example,
one
idea
would
be
to
not
have
separate
variables.
Just
have
the
globals
count
up
all
the
attributes
among
everything
in
the
span.
C
But
but
but
if
you
see
it's
a
may
so
yeah,
but
what
I
want
is
if
somebody
thinks
that
they
want
to
implement
this,
to
be
consistent
with
these
names,
because
if
we
decide
that
we
want
to
make
this
a
shoot
and
we
define
environment
variables
for
them.
I
think
this
will
be
the
names
that
we'll
use
so
so
kind
of
I
just
wanted
more
or
less.
I
wanted
to
reserve
the
needs
or,
if
you
want,
I
can
just
put
like
reserve
names
for
future
or
whatever,
but
kind
of.
B
Okay,
hey
I
gotta
run.
I
got
another
call,
but
yeah
just
just
merge
this
fast,
I'm
not
going
to.
C
B
D
C
The
sample
array
recommend
to
users
to
do
that.
Yeah
hey!
This,
has
an
undefined
behavior,
where
is
in
the
middle
of
the
traces
or
in
the
middle
of
a
trace,
because
we
don't
have
a
consistent
algorithm
across
things
and
we
not
guarantee
that
what
was
happened
here
would
be
something
whatever
we
said
because
of
that
just
just
make
it
just
use
it
as
a
root.
That's
where
we
guarantee
that
you
will
get
that.
D
C
C
I
think
it's
it's
it's
a
great
compromise
that
makes
sense,
and
there
is
a
discussion
with
an
issue
about
different
things,
that
we
talked
about
the
1413
about
this
and
we
will
after
yeah.
So
that's
that's
about
it
in
the
notes.
I
think
what
else
was
this
class?
I'm
looking
for
this.
C
D
C
C
If
you
know
what
that
the
fact
that
when
we
called
something
experimental-
because
there
was
this
con
trolling
confusion,
whatever
that
experimental
may
mean
that
we
are
experimenting
with
that
versus
we
are,
we
are
in
a
beta
or
whatever.
So
we
already
thought
about
that
thing,
but
we
mark
it
where
we
called
experimental
is
that
we
did
not
finalize
different
details
so
anyway,
okay,
the
ones
off,
is
this
well
thought.
Is
this
just
random
thing
playing
with
it
or
something
so
but
yeah?
I
don't
think
it
will
happen
pretty
soon
to
fix
that
part.
C
And
I
clarify
with
everyone
by
the
way:
when
do
you
expect
java
to
have
a
release.
C
C
C
Because
we
also
discuss
about
the
february
15-
and
I
was
like
where'd
this
happen,
so
the
decision
on
february
15,
which
everyone
agrees
is
gonna,
be
only
a
blog
post
that
will
announce
the
following:
spec
release,
one
zero
and
languages
that
are
in
rc
mode,
so
nobody
has
to
do
ga
or
1-0
by
february
15th.
It's
just
like
the
announcement
will
include
only
this
okay
make
sense.
So
there
is
no
rush
for
february
15.,
15th.
C
That
being
said,
delay
more,
but
I
was
just
trying
to
make
sure
that
I
don't
feel
rushed
and
doing
mistakes
just
because
it's
february
15th,
it's
not
february
15th,
because
this-
and
we
said
okay
for
february
16,
actually
because
15
is
yeah,
we
said
that
we
will
just
do
a
blog
post
of
the
spec
version,
spec,
one
zero,
which
will
happen
for
sure
and
then
languages
that
are
in
rc.