►
From YouTube: 2021-09-23 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).
D
Hey
this
is
something
that
I
posted
about
in
slack,
I
don't
know
if
you
guys
had
a
chance
to
look
at
my
message.
Okay,
I'm
not
sure
you
might.
A
No
sorry,
what
am
I
doing.
D
A
D
D
We
just
need
to
update
the
rules
on
both
the
repos
to
not
have
such
strict
rules
on
the
github
pages.
Branch
main
would
be
continue
to
be
a
protected
branch.
Then
we
need
to
explicitly
add
github
pages
to
have
no
permissions,
no
nothing
special,
and
then
we
add
these
other
two
rules
to
say
everything
else
that
would
be
on
this.
Repos
is
protected.
D
A
Sure
so
so,
what's
the
action
item
is
there
an
issue
opened
already.
D
D
Okay,
do
you
think
you
can
and
you
can
take
charge
on
this?
It's
just
adding
these
settings.
I
showed
the
the
screenshot
here.
You
just
go
to
the
settings
branch
protection
rules,
you
leave
main
protected,
create
a
rule
for
github
pages
to
say,
not
protected,
and
then
the
bottom
two
you
can
say
protected.
Everything
else
doesn't
matter
it's
just
this
one
should
fix
the
tests.
D
D
A
This
thanks
all
right.
Next
topic:
oh
yeah,
we
we
skipped
the
first
topic,
which
is
that
we
need
to
make
a
decision
on
the
on
the
website.
Docs
topic.
Another
few
fellows
have
been
able
to
take
a
look
at
this
issue.
A
A
So
read
this
real
quick
a
while
ago-
and
I
think
it's
better
if
we
move
our
documentation
here
because
of
these
advantages
that
are
mentioned
here-
not
completely
sure.
How
does
it
work
if
we
need
to
make
a
change?
Probably
we
just
make
a
pr,
and
I
mean
who's
gonna-
prove
it
right.
E
A
A
E
A
Yeah
me
neither
so
well,
I
guess
maybe
we'll
need
to
read
this
with
more
details
before
we're
able
to
make
a
decision,
but
it'll
be
good
to
kind
of
set
a
time
to
make
the
decision
so
that
we
can
inform
them
about
what
we
are
going
to
do
in
order
not
to
block
them.
If
that's
the
case,.
A
E
It's
different
from
the
read
the
dark
stocks.
Yes,.
B
C
Yeah,
so
I
I
did
the
initial
work
to
get
this
pr
kind
of
nonsense
going,
and
I
guess
the
website
sig
decided
that
that
wasn't
working
for
them.
So
that's
why
they're
switching
over
to
either
some
modules
or
moving
the
docs
completely
out
of
the
repos
from
what
I'm
seeing
it
looks
like
most
of
the
repos
are
continuing
to
like
either
self-host
and
share
by
a
sub
module
or,
like
just
add
a
link
to
the
to
their
own
site.
So
I
don't
know
I
mean
I
guess
I
don't.
C
B
E
E
B
Yeah
and
then
on
the
other
hand,
we
don't
really
have
that
much.
We
don't
really
have
that
much
in
this
getting
started
guide.
So,
in
terms
of
I
mean
obviously
the.
B
Most
of
our
docs
are
in
read
the
docs,
which
would
need
to
be
internationalized
on
their
own.
So
I
don't
know
it
looks
like
most
of
the
stuff
in
the
in
the
actual
getting
started
guide.
I
don't
know,
is
anybody
reading
through
there?
It's?
Let
me
put
the
link,
it's
almost
all
like
staple
tracing
stuff
from
what
I
can
tell
so
I
doubt
we're
changing
it.
That
much.
E
C
If
you
look
at
some
of
the
other,
some
of
the
other
content
on
open
telemetry.io
for
like
javascript,
for
example,
they
have,
they
have
a
bunch,
more
content
and
just
getting
started.
They
have
like
instrumentations
and
exporters,
and
examples
and
stuff
like
that.
So.
E
So
yeah,
like
it's,
the
problems
like
the
problem
set
right.
One
is
like
all
the
benefits
that
we're
losing
from
moving
to
open
source
io,
mainly
the
the
language
internet
internationalization.
But
the
second
is
the
fact
that
we
will
have
docs
in
many
many
different
places
right
so
like
if
we
move
our
stuff
to
open
some
of
your
I
o
like
like,
will
we
have
more?
Is
it
worth
to
just
like
add
everything
instead
of
just
getting
started
there
right,
it's
worth
a
at
everything
that
we
have
in
read
the
docs.
B
E
B
Sorry,
I
was
just
gonna
say
I
know:
javascript
has
auto-generated
documentation
for
their
api
and
stuff
separate,
and
I
imagine
java
has
a
javadoc
page
separate
too,
but
since
since
we
have
like
so
much
actual
code,
like
all
the
documentation
is
inline
in
our
code,
it
seems
really
difficult
to
move
more
stuff
into
here
without
duplicating
it
at
least.
A
Yeah,
well
maybe
it's
not
that
well
defined
how
big
the
documentation
living
in
this
website
has
to
be.
Maybe
they
just
want
us
to
have
minimal,
getting
started
examples
in
the
most
basic
stuff
and
if
that's
the
case,
okay.
A
B
Yeah,
I
think
of
this
kind
of
like
as
hey,
I'm
looking
to
have
open
telemetry
at
my
company
or
in
my
like
polyglot
services,
and
I
want
to
see
all
like
the
features
and
things
that
are
supported.
So
I
can
quickly
tell
if
this
will
help
and
then
there's
like
a
short
getting
started
section,
so
you
can
see
sort
of
what
the
code
might
look
like
and
then
we
have
more
detailed
documentation
separate.
Obviously,
so
is
that
maybe
the
value
of
it
at
least
that's
that's
what
I
see
it
as.
A
Well,
maybe
the
value
it's
also
kind
of
being
able
to
compare
languages
to
make
maybe
someone's
making
a
decision
on
which
language
to
use
for
their
framework
and
and
they're
gonna
base
that
decision
on
implementations
of
open
telemetry.
So
maybe
they
want
to
compare
them,
and
this
presents.
E
C
So
is
it
fair,
so
one
thing
one
thing
to
keep
in
mind
is
that
the
it
is
possible
to
generate
docs
for
this
website
using
sphynx,
build
there's
like
a
jekyll
plugin
that
you
can
install
that
allows
you
to
generate.
That's
how
I
generated
the
getting
started
in
the
format
that
was
close
to
what
the
website
needed.
C
So
if
auto
generation
is
something
we're
concerned
about,
maybe
we
can
spend
some
time
there,
but
I
guess
is
it
fair
to
say
that
we
should
move
at
least
the
examples
that
aren't
like
either
code
documentation
or
or
whatever
out
of
our
repo
and
put
that
into
this
repo
and
then
at
least
they
live
only
in
one
place
or
and
then
those
could
be
translated
or
whatever
like.
If
that's,
if
that's
the
value
of
this
website
here.
C
C
E
E
B
B
A
E
B
If
you
find
a
channel
for
me,
I
could
just
put
it
in
the
general
or
ask
somebody
sure
I
can
help
that
all
right.
Thank
you.
Aaron.
E
Nice
yeah,
it
looks
like
I'm
taking
a
look
at
the
meeting
notes.
It
doesn't
look
like
they
meet
that
often,
and
both
of
the
leaders
are
out
today.
So.
A
Okay,
something
else
we're
going
to
discuss
about
this
topic.
A
Topic:
okay,
okay,
here
we
go,
I
have
a
presentation
for
you,
it's
regarding
error
handling
and
this
can
be
quite
impactful
to
the
entire
project.
So
let
me
just
show
you
real
quick,
so.
A
Yes,
okay,
there
is
this
section
in
the
specification
name,
narrow
handling.
A
This
applies
both
to
the
api
and
to
the
sdk,
and
we
have
a
problem
here.
So
let's
take
a
look
at
our
most
basic
examples.
A
A
A
A
Code,
the
problem
is
that
I'm
trying
to
run
this,
but
it's
giving
me
another
error,
because
maybe
I
can
just.
A
Yeah,
I
don't
have
a
conflict
just
if
you
do
this.
If
you
try
to
run
this
example,
and
you
don't
pass
the
name
here,
okay,
you
will
get
an
error,
not
this
one
right,
but
something
else,
but
it
fails.
My
point
is
that
this
should
not
happen.
Okay
shouldn't
happen
because
this
text
says
that
a
bad
usage
of
the.
A
A
It
should
not
fail
because
the
idea
is
the
telemetry
should
not
cause
the
application
code
to
fail.
What
should
happen
is
that
telemetry
should
stop
measuring
or
working,
but
the
application
code
so
should
not
be
affected.
E
So
wait!
Sorry,
diego
before
we
go
on
the
first
slide
in
which
you
found
the
the
error,
handling
principles.
B
A
Okay,
okay,
so
anyway,
let's
go
back
here
and.
A
So
we
have
rolling
and
we
need
to
figure
out
how
to
solve
it
right.
The
I
have
made
a
prototype
that
may
fix
this
problem,
and
I
wanted
to
show
it
to
you.
This
pretty
much
happened
because
of
the
conversations
we
had
regarding
the
metrics
api,
with
josh
from
google
and
josh
from
bicep
and
riley
from
microsoft
and
other
folks
that-
and
this
is
something
that
I'm
trying
to
incorporate
now
in
my
matrix
api
implementation,
so
that
we
have
met.
A
If
somebody,
for
example,
passes
a
bad
argument
to
when
creating
an
instrument,
they
will
get
a
no
up
instrument
instead
of
raising
an
exception.
The
previous
approach
we
had
in
my
metrics
api
implementation
was
just
log
and
error,
but
that's
not
enough,
because
if
we
don't
return,
something
that
matches
the
type
of
what
the
method
should
have
returned.
A
Of
course,
that's
gonna
fail
in
the
next
operation
right,
because
the
the
application
code
expects
an
instrument,
object
and
they're
going
to
call
a
method
from
the
api
defined
for
that
kind
of
instrument
right,
and
that
attribute,
of
course,
is
not
going
to
be
there.
If
we,
if
we
pass
return
on
or
something
like
that,
okay,
so
okay,
so
the
idea
I
have
is
pretty
much
this
imagine
that
our
api
only
has
classes
and
functions
okay.
A
So
when
that's
the
case,
we
have
a
problem,
because
even
if
we
wrap
the
entire
code
of
functions
in
try
except
it
can
fail
before
if,
for
example,
the
positional
arguments
are
not
passed
in
as
required.
So
imagine
this
case
right.
We
have
a
class.
It
has
these
two
positional
arguments
that
are
mandatory
and
if
the.
A
A
Same
thing
happens
with
functions.
If
someone
passes
a
that
argument
here,
sorry
or
a
misimpositional
argument,
it's
gonna
fail
as
well.
Okay,
so
a
solution
that
I
have
in
mind
is
having
classes
that
will
return
nano
app
when
instantiated,
directly
and
functions
that
will
also
return
nano
up
when
called
with
the
wrong
parameters.
A
B
I
I
I
have
a
quick
comment.
I
wanna
read
the
room
too:
can
you
go
back
and
slide
sure
one
more
to
the
code,
so
I
think
like
for
me
this.
This
should
be.
I
like
that
this
error
comes
up
because
I'm
trying
to
imagine
writing
instrumentation.
If
I
didn't
get
an
error
and
like
if
everything
just
just
passed,
it
would
be
really
really
tough
so,
and
I
think
there's
also.
B
A
Okay,
so
you
mean
that
if
someone
passes
doesn't
pass
a
required
positional
argument,
we
should
still
raise
an
error.
Yes,
okay,
I
disagree
not
not
because
I
don't
think
that
your
arguments
have
value.
I
just
disagree
because
I
think
the
the
specification
says
otherwise,
in
fact,
if,
if
I
had
to
choose,
I
will
probably
I
prefer
to-
I
prefer
to
fail
fast,
inform
the
user
of
an
error.
Yes,.
B
A
B
Of
hiding
them
like
this,
but
there
is
one
specific
section
that
says
an
api
or
sdk
may
fail
fast
and
cause
the
application
to
fail
on
initialization
yeah.
So
for
for
creation
of
instruments,
we
could
maybe
call
it
that.
But
I
understand
that
for
like
a
span
or
something
like
that,
we
can't
that's
not
gonna
fail
fast.
A
A
Let's
continue
the
discussion
because
I'm
gonna
introduce
later
a
feature
that
will
allow
the
user
to
fail
fast,
even
with
this
approach,
so
it
may
fulfill
what
you
intend
to
have
fulfilled
okay,
so
yeah.
A
This
is
the
general
idea
for
new
ops.
Imagine
that
we
have
a
mirror
class,
that's
an
abstract
class,
maybe
the
api.
It
says
that
cha
cha
classes
must
have
this
great
counter
method.
We
have
a
no
up
meter
which
returns
an
old
counter,
and
then
we
have
an
sdk
mirror.
This
is
the
actual
implementation,
and
this
inherits
from
here,
of
course,
because
we
must
implement
this
api
and
also
inherits
from
this
base
safe
class
that
I'm
gonna
explain
soon
and
also
has
this
method
decorated
as
a
save
function.
A
E
I'm
sorry
before
we
go
on
in
too
much
into
the
implementation.
I
just
wanted
to
like.
E
Like
summarize
what
the
issue
is
that
we're
talking
about
right
so
right
now,
like
the
specs
say
that
we
shouldn't
be
throwing
uncaught,
exceptions
right
and
I
think
most
of
our
code,
we
catch
actual
exceptions
that
we
that
we
expect
like
any
invalid
input
or
stuff
like
that.
But
the
only
thing
that
we
don't
is
this
missing
positional
arguments
is
that
is
that
a
specific
use
case,
or
is
that,
like
the
only
time
when
this
could
happen
specifically
for
python,
it
goes
way.
E
Because
okay,
but
no
no
ops,
is
for
instantiation
right.
No,
no,
no,
no
ops
is
the
idea.
Is
this.
You.
A
Have
or
like
when
you
call
like
a
method
or
something
right,
you
call
a
method
or,
for
example,
you
create
this
method.
A
That
creates
a
counter
right,
that's
supposed
to
create
a
counter,
and
something
goes
wrong
and
instead
of
an
exception
being
raised,
we
should
return
a
noaa
counter,
because,
even
if
we
put
all
the
all
our
code
in
create
counter
in
a
triaxial
plot,
this
object
that
will
be
returned
needs
to
be
something
that
behaves
like
an
old
counter,
because
the
next
operation
that
the
application
code
will
do
is
to
use
this.
Yes
as
a
counter.
So
if
we
return
none,
for
example,
by
just
following
the
exception
and.
E
Yeah,
that's
fair
yeah,
I'm
just
wondering.
Is
there
anything
in
in
our
can
we
have
like
a
specific
example
in
tracing
in
which
we
don't
do
that
or
our
current
code
today,
in
which
we
don't
do
that.
A
E
A
Context
manager,
what
should
have
happened
is
like
a
span.
I
think
right
something
like
that,
and
then
you
can
just
explain
here.
Okay,
this
object
must
be
a
no
app.
E
No,
no!
No,
but
like
the
start
is
current
span
like
method
right
would
would
error
out
even
before
it
is
treated
as
a
context
manager,
because
we're
missing
a
positional
argument,
yeah
right,
but
that's
so
I
know
that's
a
specific
example,
but,
like
is
will
this
happen
anywhere
else
in
our
code?
A
I
mean
I
haven't
taken
a
look
at
all
the
code
so
that
I
can
answer
the
question,
but
I
I
would.
I
wouldn't
be
very
sure
that
that
doesn't
happen.
A
E
Yeah
right
because,
because
the
if
this
is
like
a
complete
set
of
like
the
issue,
then
it's
pretty
specific
to
like
dynamic
typing
languages
right,
but
if
it's
not,
then
we're
we're,
not
handling
the
error
cases
properly.
In
other
cases
right,
I
don't
think
this.
A
A
C
A
Yeah,
what
I
mean
is
that
imagine
this
example
in
a
in
a
static
language
right
and
you
pass
the
right
name
perfect,
but
the
function
that
calls
the
actual
time
to
record
the
moment
when,
when
this
span
starts,
fails
by
some
reason.
Okay,
so
an
exception
is
raised
and
it's
not
caught,
and
if
that
happens,
then
an
exception
will
be
raised
here
and
you
will
not
have.
I
know
up
here
as
it
should
be.
C
Yeah
sure
I
I
just
think
there's
two
different
cases
right
like
there's
there's
the
case
of
someone
is
using
the
api
incorrectly
in
the
code
that
they're
writing.
So
this
is
like
a
misuse
of
the
the
the
apis
which,
in
a
static
language,
you
wouldn't
have
an
issue
with,
in
that
particular
case.
You're
right
like
something
could
happen
as
you're
using
the
api
and
like
at
that
point,
you
should
return
a
new
op
and
I
understand
that
portion
like.
C
A
Yeah
yeah,
I
understand
the
difference
that
you
see
in
these
cases,
but
there
are
also
additional
requirements
added
by
the
spec
itself.
So,
for
example,
the
name
of
of
a
meter
or
an
instrument
must
be
no
longer
than
63
characters.
Something
like
that
and
you
can
pass
a
valid
string
there.
That
will
not
be
detected
by
the
compiler
right
because
the
type
matches.
But
there
is
an
additional.
C
A
Same
problem
happens
right,
so
yeah,
let's
go
back
to
this
later.
Do
you
have
more
questions.
A
A
So,
for
example,
if
someone
takes
the
sdk
meter
class
and
tries
to
instantiate
it
directly
here
with
valid
arguments,
this
still
should
return
a
noaa
meter.
A
That's
why
we
have
these
methods
like
get
meter
or
get
meter
provider
or
stuff
like
that.
Those
methods
should
be
the
only
way
of
instantiating.
These
objects
and
the
api
says
so,
for
example,
in
the
metrics
case,
it
specifically
says
it
should
not
be
any
other
api
to
create
a
counter
besides
the
create
counter
method.
A
A
Now
going
back
to
aaron's
comment,
he
mentions
that
it
is
convenient
to
be
able
to
detect
errors
fast
and
to
be
able
to
fix
them
and
not
having
to
wait
to
run
time.
I
agree
completely.
The
specification
seems
to
agree
as
well,
because
it
has
this
section
where
see.
A
Yeah
sdk
implementation
must
allow
and
users
to
change
the
library
folder
handling
behavior
for
relevant
errors,
so
they
they
may
want
to
run
with
stricter
handling
and
staging
environment
to
catch,
involve
the
uses
of
the
api,
for
example,
just
what
aaron
mentioned,
and
so
the
idea
that
I
have
for
this
prototype
is
not
to
use
not
to
log
errors,
as
we
have
been
doing
so
far,
but
to
raise
warnings.
So
a
python
warning
is,
is
an
exception-like
object
of
this
module
that
can
be
erased.
A
But
when
you
raise
a
warning,
it
doesn't
kill
the
execution
like
an
exception
world.
It
just
shows
the
warning
message.
It
looks
like
an
exception,
but
it
doesn't
kill
anything,
but
you
may
invoke
the
interpreter
with
an
option
that
will
turn
warnings
into
actual
exceptions
so
that
the
user
can,
in
this
way,
run
in
a
strict
way,
as
the
specification
requires.
A
A
These
know
classes
they
will
return
a
default,
always
there,
then
the
sdk
class,
which
is
the
actual
implementation
here.
It's
from
the
api
class,
of
course,
because
it
implements
this
api
and
also
from
base
safe
class
so
that
it
cannot
be
instantiated
directly
and
it
has
this
method,
which
is
a
save
function.
A
That
cannot
be
instantiated
directly,
but
we
do
so
by
passing
a
private
argument,
name
underscore
safe
here,
so
that
this
is
outside
of
the
api,
because
it's
private
protected
and
the
the
end
users
are
not
supposed
to
be
useless,
but
we
can't.
Okay.
Let
me
just
show
you
what
happens
when
we
run
this.
A
A
A
So
we
are
all
almost
out
of
time,
but
I
wanted
to
ask
you
for
your
opinions
on
this
matter,
because
I
think
this
may
require
changing
our
apis
and
classes
and
tracing
as
well,
not
only
metrics.
B
I
guess
I'll
start
since
no
one's
talking,
I
I
like
the
switch
here.
I
think
that's
pretty
cool.
I
just
I
wonder,
like
I
feel
like
there's
a
certain
level
of
responsibility
on
the
person
writing
the
code
to
just
you
know
like
use
apis
correctly,
and
I
think
this
goes
for
anything
like
python
standard
library
or
you
know,
basically
anything.
B
I
wonder
if
there's
ways
that
this
would
still
break
and
and
sort
of.
I
guess
I
just.
B
I
don't
know
like
I
I'm
worried
this
could
hide
hide
errors
that
should
come
up
like
like,
for
instance,
if
you
use
incompatible
versions
of
the
api
and
sdk,
you
might
get
a
bunch
of
warnings
instead
of
actually
seeing
the
failure
and
fixing
it
and
you
might
ship
something
to
production
with
no
telemetry.
A
That
is
the
same.
Take
that
I
have
on
it
me
personally.
I
don't
like.
I
prefer
when
things
fail
as
fast
as
possible
and
clearly
as
possible,
but
again
this
is
what
this
specification
requires.
So
I
don't
think
that
well
on
that
front,
we
have
much
choice.
I
think
I
also
understand
why
the
specification
was
really
in
this
way
and
the
goal
of
do
not
affect
the
application
code.
A
If
telemetry
goes
wrong
right,
just
let
it
run
and
the
user
prefers.
It's
like
a
basic
principle
of
open
2003
that
the
user
prefers
their
application
to
keep
running,
even
if
they
don't
have
arrangement.
E
E
E
There
are
still
like,
as
diego
pointed
out,
there
are
still
ways
that
the
the
api
can
be
used
incorrectly,
but
not
explicitly
by
the
user.
Right,
for
example,
like
I'm,
looking
at
the
great
get
tracer
method
from
the
tracer
provider,
and
we
we
make
it
so
that
the
get
tracer
cannot
have
a
missing
module
name
for
the
instrumentation
module
right,
and
we
just
log
an
error
for
that,
and
we
still
return
a
regular
tracer
that
we
don't
throw
an
exception
or
anything
right.
E
Oh
and
we
also
had
a
time,
but
this
is
like
one
of
the
examples
where
we're
not
actually
explicitly
using
the
api
incorrectly,
so
it
won't
catch
this,
but
you
know
it's
like
just
throwing
an
error
and
we're
not
failing
or
anything
like
in
those
use.
Cases
like
I
might
see
that
there's
value
for
doing
this,
but
you
know
I
might
have
to
have
another
discussion
about
this.
So
here.
C
Maybe
that
this
would
be
a
good
discussion
to
have
at
least
asynchronously,
so
that
the
folks
that
weren't
in
this
call
can
participate
and
also
we're
out
of
time.
So.
E
Yeah
yeah,
I
would
also
add
this
to
next
week's
agenda
just
to
continue.
Okay,
all
right.
So
thank
you.
Everybody
all
right!
Thanks,
guys
see
each
other
again.
Thank
you
later.