►
From YouTube: 2021-11-29 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
Hello,
let's
get
started
by
the
way.
Can
people
hear
me?
I
switched
microphones,
but
this
is
the
first
time.
Okay,
I
see
a
thumbs
up
great
okay
agenda
kind
of
redone
it
for
this
group
because
we're
already
on
the
call,
but
if
you're
in
an
empty
room,
you
only
did
switch
meetings
just
to
answer
daniel's
question:
why
the
link
isn't
in
the
dock
anymore.
The
link
in
the
calendar
is
now
stable
until
we
go
make
changes
to
the
meeting,
in
which
case
zoom
will
probably
generate
a
new
link.
A
A
A
All
right,
daniel
added.
How
often
will
that
be
at
a
minimum
once
a
year,
because
the
zoom
links
will
only
last
one
year
they
need
to
get
reset
every
year,
possibly
more
frequently,
though,
if
people
just
make
small
changes
or
edits
to
the
calendar,
I
think
under
there's
certain
circumstances
where
zoom
will
re
re-regenerate
the
link
all
right,
let's
proceed
into
the
sig
check-in,
so
specification
sig,
no
updates,
we've
released
next
week
for
the
metric
sig
moving
the
needles.
A
A
Anyone
want
to
speak
to
this
in
more
details.
I
don't
know
if
we've
riley,
oh
yeah,.
B
Because
I'll
I'll
be
on
vacation
for
the
entire
december,
I'm
trying
to
do
as
best
as
I
can
and-
and
one
thing
I'm
trying
to
see-
is
by
sending
a
pr
to
mark
the
metrics
I
seek
as
stable.
I
want
to
see
people's
reaction
and
so
far
it
seems
the
reader
exporter
part
is
fairly
stable.
I
I
don't
see
any
outstanding
comments
or
a
blogging
issue
for
baggage
exemplars.
B
I
I
think
there's
some
concern,
especially
I've
seen
that
in
multiple
six
people
like
saying
they
don't
have
enough
cloud,
I'm
trying
to
overcome
prototype,
but
meanwhile
I
I
I
think
we
have
two
options
in
front
of
us.
One
is
do
nothing
about
like
trying
to
make
anything
stable
this
year.
Another
one
is
trying
to
get
as
much
like
many
things
possible
as
stable
before
and
now
this
year,
and
for
things
that
we
have
less
confidence.
The
market
has
a
mixed
state
by
leaving
those
sections
experimental.
B
Okay,
I
think
that's,
probably
the
the
best
interest
for
everyone
and
given
like
the
original
plan
for
matrix,
was
to
ship
stable
last
year
and
we
already
delayed
it
for
a
year.
I
think
it
makes
sense
for
us
to
push
it
harder
for
histogram.
I
I
think
we
have
good
confidence.
There's
no
question
mark.
B
A
With
what
you
said,
riley,
I
think
it'd
be
great
to
show
some
progress
by
marking
as
much
as
we
can
to
stable,
which
is
the
core
parts
of
the
spec
that
most
people
want
to
use
and
if
baggage
handling
and
exemplars
aren't
stable.
That's
probably
okay,
because
those
are
not
like
super
critical,
important
parts
of
the
spec
that
everyone's
going
to
be
using
on
day.
One.
B
Yeah,
so
baggage
is
one
important
thing
that
ties
the
matrix
and
traces,
so
you
have
correlation
like
exemplars,
and
so
both
features
are
important
for
open
telemetry,
but
so
far
we
think
it's
a
very
nice
to
have
feature
that
can
be
added
later.
Instead
of
having
to
block
the
entire
stack
you
can
see,
both
of
them
are
kind
of
related
to
the
correlation
between
matrix
and
traces
yeah.
C
I
mean
one
thing
makes
me
feel
confident
is
none
of
those
are
features
that
have
api
surface
area.
That's
all
stuff
that
happens
under
the
hood
as
long
as
people
are
far
enough,
along
with
implementing
sdks
in
various
languages
that
you
know
they
can
have
an
opinion
about
feeling
confident
about
certain
areas
because
they've
implemented.
It
sounds
like
it's
true
and
as
long
as
there
isn't
a
feeling
that
these
remaining
experimental
issues
would
impact
the
design
of
the
rest
of
it
in
a
in
a
heavy
way.
C
Yeah,
then
I
totally
agree
that
pushing
forwards
and
just
being
clear
about,
what's
locked
down
would
be
great.
B
Yeah,
and
especially
considering
the
fact
that
the
api
is
already
stable,
a
lot
of
folks
are
ready
to
adopt
it
without
the
like
any
part
of
the
isdk
market
stable,
and
I
I
I
think
this
will
be
a
pressure
on
us.
So,
yes,
I'll
change
the
the
spec
pr
trying
to
call
some
sections
that
we
have
very
high
confidence.
B
A
D
A
B
B
A
All
right,
I
will
poke
them
and
a
have
them
antennas.
Well,
bogdan's,
usually
here
actually
get
t
grind
to
attend
this
a
little
more
regularly
and
also
find
out
if
something's
missing.
B
A
A
Metric
stabilization
work
is
ongoing.
Planning
for
api
stable
in
1.10.0
java,
instrumentation
1.9.0
release
includes
exemplars
and
android
support,
javascript
metrics
api,
three
to-do's
foreign
progress,
15
done
vectors,
sdk
five
to
do
forward
progress
for
done,
wow
daniel.
It
looks
like
pretty
rapid
progress.
A
Not
that
here,
okay,
python,
no
majorupdates.net
additional
features
are
added
to
the
existing
exporters,
including
jager
otlp
and
others.
1.2.0
release
candidate
is
expected
to
be
released.
Today,
has
more
memory,
optimizations
visible
api
changes
are
in
the
export
interfaces,
so
people
writing
their
own
exporters
will
see
changes
in
parenthesis.
A
1.2.0
stable
release,
which
has
the
metrics
sdk,
is
blocked
until
the
metrics
sdk
spec
is
stable.
That
makes
sense,
go
no
major
updates,
c,
plus
1.1.0
was
released
last
week.
This
has
bug
fixes
for
traces.
The
metrics
api
matrix
sdk
implementation
is
ongoing.
Slow
and
steady
progress
contributors
are
welcome.
Great.
A
Daniel
I
see
you're
celebrating
this-
is
that
because
jss
dependency
you're
just
excited
over
c
plus
I'm
curious.
A
Oh,
I
see
yeah,
I
got
it.
Ruben
swift,
no
updates,
collector
0.40,
0.40.0
release
came
out
last
week
and
for
rest,
carlos's
initial
technical
discussion
on
current
progress
looks
good,
expected
release
in
q1
yeah.
That's
great.
D
Yeah
yeah,
just
for
for
the
context
we
have
been
losing
contacts
on
the
roads
to
seek
so
I
attended
their
seat,
which
was
very
interesting.
We
talked
a
little
bit
about
technical
details
here
and
their
expectations.
It's
looking
good,
there's
actual
progress
there,
even
though
they
are.
They
seem
to
be
quiet
that
that
group
and
yeah
look
things
looking
good
q1
for
for
the
first
release.
A
That's
great
fantastic
and
no
updates
from
erlang
first
topic
from
carlos
added
a
new
hotel
traces
processor.
D
Yeah,
this
is
not
like
super
important,
but
it
I
think
I
probably
put
the
oh
yeah
there.
It
is
basically
it's.
The
idea
is
for
adding
a
new
environment
variable
and,
of
course,
the
reason
is
that
we
already
have
something
for
for
exporters.
For
example,
I
think
it's
helpful,
for
example,
for
our
instrumentation
components,
and
I
think
that
a
lot
of
the
those
components
are
they
are
already
using
the
batch
processor
under
the
hood.
D
This
does
make
sense
to
me,
but
I
think
that
this
is
something
that
all
the
maintainers
would
need
to.
You
know
to
digest
and
think
whether
this
makes
sense
for
them
or
not
nikita
from
java.
He
already
approved
that.
So
I
guess
he's
fine
with
that.
But
please
take
a
look
and
comment
on
that.
D
F
D
F
C
C
The
other
use
case,
like
you
mentioned,
is
if
someone
has
some
kind
of
like
streaming
processor.
That's
that's
just
trying
to
slam
these
out
as
fast
as
possible
and
doesn't
want
batching.
I
guess.
F
G
Yes,
but
I
think
this
also
gets
to
like
this
other
problem
is
like
we're:
adding
an
environment
variable
for
spam
processor,
but
there's
like
a
multi-dimensional
path
here.
Right,
like
you,
can
have
n
number
of
span
processors
and
those
can
all
link
to
different
exporters
and
shutting
into
like
this
is
again
kind
of
pointing
out
the
fact
that,
like
the
sdk
configuration
is
woefully
in
need
of
help,
because
I
think
that,
like
this
is
a
tough
one
to
say
like
yeah,
you
have
this
export,
but
what
about
this
other
exporter?
G
G
How
do
you
like
resolve
that
that
path-
and
I
think
that
this,
like
just
points
out
the
fact
that,
like
our
environment,
variable
configuration
is
just
not
going
to
serve
us
in
the
long
term,
and
this
might
be
one
of
those
breaking
points.
F
H
I'm
not
sure
that
this
is
generally
applicable
in
any
event,
given
that,
for
instance,
in
the
go
sdk,
you
have
to
explicitly
configure
spam
processors,
there's
no
generic
spam
processor,
that
has
an
exporter
that
can
decide
batch
or
simple
spam
processor
at
run
time,
and
even
if
we
added
one,
the
developer
would
have
to
explicitly
choose
to
use
that
to
enable
this
environment
variable.
It
wouldn't
be
something
that
would
work
with
any
application
that
uses
the
go.
Sdk.
B
Yeah,
I
I
see
a
problem
on
otlp,
because
when
we
use
the
batch
way
we
can
we
can
have
one
connection
established
and
try
to
send
things
in
a
batch
if
we
have
multiple
like
threads,
calling
the
simple
processor
concurrently,
what
would
happen
if
one
thread
is
exporting
and
it
got
stuck?
For
example,
the
receiver
side
is
blocked,
should
other
threads
wait
or
they
should
establish.
Another
connection
I
I
figure
is,
is
trying
to
open
a
count
of
worms.
Maybe
we
need
to
clarify
the
behavior
before
we
add
this.
H
B
C
What
what
is
the,
why
why
is
there
an
attempt
to
add
this
department
variable?
I
assume
someone
wants
it
for
something.
Oh.
B
D
C
I
think
what
tyler's
mentioning
that
the
sdk
doesn't
isn't
very
well
specced
out
and
as
we
keep
tacking
on
environment
variables
like
this
keeps
this
problem
keeps
coming
up,
which
is
we're
kind
of
just
tacking
things
on
without,
like
a
general
concept
of
of
what
it
means
to
have
like
a
very
fully
configurable,
declaratively
configurable
sdk
part
of
it
is
that
the
sdks
all
work
a
little
bit
differently,
especially
around
areas
when
it
comes
to
say,
like
loading,
plug-ins
and
stuff
like
that,
because
languages
work
differently,
but
we
also
don't
have
like
in
the
collector,
for
example,
there's
a
clearly
defined
pipeline
architecture
and
a
configuration
language
for
defining
pipelines
and
a
lot
of
like
the
questions
john
brings
up.
C
You
know
kind
of
implies
to
some
degree
like
the
sdks
are
like
mini
collectors.
Right
like
you,
might
have
a
chain
of
of
processors
and
exporters,
and
that
might
be
different
from
another
chain
of
processors
and
exporters.
But
we've
never
defined
anything
like
that.
It
would
probably
be
painful
to
some
sdks
to
to
retrofit
something
like
that
onto
them
and
then
again,
all
of
these
languages
want
to
have
a
different
loading
mechanism
for
all
this
stuff.
So
continuing
to
just
tack,
things
on
feels
a
little
bad.
C
The
degree
to
which,
like
the
environment
variables,
are
supposed
to
make
the
easy
path,
easy
being
able
to
say
like
if
you
configure
a
certain
exporter,
it's
just
going
to
configure
it
the
not
dumb
way
so
like.
Yes,
you
could
technically
attach
the
otlp
exporter
to
a
simple
span
processor,
but
we
think
that's
silly,
so
we're
just
going
to
give
you
the
option
to
say:
if
you
want
the
otlp
exporter,
then
you
just
configure
that
and
we're
not
going
to
allow
you
to
kind
of
micro
configure
this
stuff
for
the
time
being
set.
H
E
H
I
I
think
this
lack
of
configuration
is
a
pain
point
that
I'm
starting
to
feel
as
I've
been
tasked
with
defining
how
we're
going
to
configure
the
go
sdk
within
the
collector
and
the
collector.
As
you
mentioned,
that's
been
a
very
well
structured
configuration
and
the
go.
Sdk
does
not,
and
there's
kind
of
this
impedance
mismatch
between.
H
Do
we
configure
the
collector
all
in
the
cml
file
and
then
say
the
sdk
that
it's
going
to
use
internally,
it's
going
to
be
configured
by
all
of
these
environment
variables
that
are
kind
of
floating
around
and
disconnected
from
that
yaml.
Or
do
we
have
to
define
some
sort
of
ammo
structure
just
for
the
collector?
That's
that
that
configures,
its
sdk
but
isn't
usable
elsewhere?
C
Yeah,
I
I
think
this
is
I
know
bogdan
has
mentioned,
configuration
something
interesting
to
him,
but
you
know
he's
stretched
really
thin.
I
think
the
last
time
this
came
up
with
environment
variables.
We
decided
we
should
actually
put
a
moratorium
on
adding
more
of
them.
C
For
this
very
reason,
so
I
don't
know
I
I
kind
of
feel
like
like
some
coherent
approach
to
to
this
stuff
would
be
helpful
before
we
start
adding
in
configuration
options
that
are
going
to
really
start
conflicting
with
each
other
and
create
a
lot
of
confusion.
D
I
think
that
one
of
the
interesting
things
is
that
if
we
tell
users
these,
but
at
the
same
time
we
are
not
doing
any
progress
on
the
configuration
side
that
probably
wouldn't
make
sense,
and
since
boxing
is
probably
bc
I
I
would
say
that
probably
we
need
a
different
champion
like
bogdan
is
very
busy
doing
a
lot
of
stuff,
and
if
somebody
could
actually
take
a
stab
at
this,
it
would
be
nice.
D
I
can
probably
try
to
ask
for
cycles
next
year,
but
but
in
any
way,
in
any
case,
somebody
needs
to
actually
take
a
stab
there.
I
think
it
has
been
a
pain
point
for
some
time
now
and
it's
time
to
actually
fix
that.
G
Yeah
I
mean
I,
I
agree.
I
think
that
we
need
to
prioritize
this.
I
think
that's
also
something
that
we
need
to
keep
in
mind.
I
think
josh
has
came
out
with
a
you
know
where
where's
the
road
map
for
open
telemetry,
and
I
think
this
was
included
in
there
if
I'm
not
mistaken,
but
like
I
just.
I
think
that
we
need
to
understand
that
priority.
I
definitely
would
not
suggest
like
if
we
don't
prioritize
this
to
just
keep
adding
environment
variables,
because
that
just
digs
the
whole
deeper
but
yeah.
G
G
I
I
mean,
I
know
it's
really
tough,
to
say
right
now,
because
it's
going
into
the
holidays
and
the
amount
of
time
that's
able
to
be
committed
is
limited.
I
would
like
to
I'd
like
to
be
able
to
consider
throwing
my
hat
in
in
january,
but
it's
yeah.
It's
tough
to
say
right
now
is
all
I
can
say
great.
C
Let's,
let's
hit
this
up
again
in
january,
and
my
feeling
is
also
people
will
have
more
cycles
freed
up
after
metrics
is
over
the
finish
line.
It
would
be
great
not
to
wait
if
there
are.
Is
there
there's
a
small
group
that
wants
to
just
start
coming
up
with
proposals,
but
I
think
we'll
we
will
have
more
more
cycles
from
more
maintainers
once
once
they
aren't
aren't
buried
in
metrics.
Just
my
hope.
B
C
Yeah
we
we
did
this
at
the
gc
level,
not
on
technical
direction,
for
the
project,
but
just
more,
like
general,
like
what?
What
does
the
project
need
from
a
structural?
You
know
capacity.
Do
we
need
you
know
more
maintainers?
Do
we
need
more
structure
for
being
able
to
level
people
up
through
the
organization?
You
know
how?
How
can
we
improve
things?
C
Maybe
something
like
this
for
technical
direction,
not
necessarily
like
a
binding
thing,
but
some
kind
of
just
just
having
like,
like
a
summit
on
this,
where
people
can
throw
up
ideas
and
vote
on
them.
We
can
just
see
where
the
community
is
at
as
far
as
like.
What's
what's
important
feels
important
to
the
community,
something
like
that
could
help
help
maybe
help
us
build
a
roadmap
for
2022.
C
It
is
definitely
a
project
goal
to
have
more
of
a
road
map
laid
out
there
and
certainly
having
like
community
feedback
into
what
that
roadmap
should
look
like
would
be
a
good
step
forward
for
the
project.
So
maybe
that's
something
we
can
look
at
doing
in
january.
D
I
B
We
don't
have
a
clear
spike
or
anything
saying
like
how
many
replies
will
be
an
indication
that
we'll
create
the
sig,
but
so
far
it
seems
the
reply
wasn't
quite
active,
so
I
I
guess
we
should
just
wait
for
more
signals.
Meanwhile,
I
I
I
feel
that
julia
is
a
fairly
new
language.
If
you
look
at
the
like
the
even
the
julia
language,
stick,
they
they
seem
to
have
less
people,
but
each
one
is
trying
to
cover
a
wide
range
of
things,
so
I'm
not
even
sure
like.
B
If
we
keep
waiting
here,
that's
a
good
model
or
not,
but
so
far
I
would
say
there
are
only
two
folks
reply
to
that
thread
that
doesn't
seem
to
be
very
convincing.
C
Well,
I
think
we
can
definitely
there's
definitely
a
middle
ground
of
encouraging
people
to
continue
developing.
C
You
know
and
unofficial
implementation
in
a
language
right
like
and
getting
more
contributors,
and
we
can
help
try
to
funnel
people
over
there.
I
do
think
it's
helpful
to
have.
C
To
keep
a
project
in
that
state
until
there's
some
evidence
that
there's
enough
enough
long-term
momentum
there,
especially
if,
like
the
rest
of
the
you
know,
just
if,
until
there
are
a
bunch
of
people,
stepping
up
saying
we're
we're
gonna
we're
definitely
going
to
invest
in
this
thing.
Trying
to
to
stay
in
touch
with
and
encourage
an
unofficial
implementation
feels
like
a
good
good
middle
zone.
C
And
that's
just
again
because
I've
seen
this
with
other
projects.
It
certainly
happened
with
open
tracing
where
you
had
one
kind
of
like
excited
individual
and
we
pushed
a
button
said
yes
you're
great,
and
then
you
know
that
individual
moves
on,
because
life
happens
and
then
there's
like.
We
now
have
like
a
dead,
a
dead
project
and
that
that's
the
thing
I
really
really
want
to
avoid.
With
with
open
telemetry.
B
Yeah,
or
is
there
a
way
that
we
can
mark
individual
project
as
like
as
they
grow
on
the
maturity
level,
for
example,
some
product
when
market
has
graduated
some
is
still
elementary
school
or
his
wild
project.
Whatever
you
want
yeah
just
trying
to
find,
what's
the
right
balance.
C
G
C
This,
but
in
like
in
the
meantime,
I
think
we
should
be
very
open
and
encouraging
to
people
who
are
doing
this.
We
shouldn't
be
shutting
the
door
on
them.
It's
great
for
the
you
know
like
having
a
tc
review
of
their
work
is
great.
You
know
we
just
want
to
just
make
it
clear
that
until
we
we
have
some
mechanism
for
ensuring
that
it's
gonna
be
like
a
self-sustaining
group.
We
don't
wanna,
we
don't
wanna,
just
haul
it
in
quite
yet.
I
B
I
have
a
question
so
I
I
checked
I
remember.
Last
year
we
have
a
maintainers
vacation
calendar,
I'm
not
sure
like
if
we
should
still
use
that,
because
that
information
was
not
publicly
available
right.
We
only
have
a
link
and
not
all
the
maintainers
have
access
to
that
and
it's
not
communicated
anywhere
on
the
on
the
repo
or
the
dock.
A
A
A
B
B
A
A
A
No,
it
doesn't
okay,
so
with
google
calendar
you
can
at
most
just
make
it
visible
to
people
of
the
public.
You
always
have
to
explicitly
share
it
with
someone,
though
I
suppose
we
could
also
use
the
open,
slumpage
calendar
invites
mailing
list
or
something
to
share
access
that
should
pretty
broadly
share
the
access
across
the
community.
A
Yes,
I
can
yeah
people,
don't
know
you
watch
me
real
time.
All
right,
I
will.
I
will
make
it
editable
to
anybody
who's
on
the
open,
telemetry
sort
of
calendar
invite
mailing
list
that
is
distinct
from
having
access
to
the
calendar,
but
I
think
most
people
on
that
mailing
list,
because
it's
like
100
people,
strong,
so
I
I
will
give
access
to
them
and
then
everyone
should
go
and
add
their
vacations
to
the
calendar.