►
From YouTube: 2021-01-07 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
D
A
All
right,
I
was
just
chatting
with
laden
a
few
minutes
ago,
so
I'm
happy
to
get
started
before
we
before
he
shows
up.
He
said
he
might
be
a
few
minutes
late,
so
if
anybody
has
prs
or
their
issues
that
they
want
to
add
in
there
looks
like
some
people
are
already
filling
that
in
so
that's
pretty
great
okay.
I
guess
we
can
start
from
the
top
here.
Let
me
show
my
screen:
let's.
B
A
D
A
A
Hey
awesome,
thank
you,
okay,
so
if
you
want
to,
if
you
don't
mind
adding
yourself
to
the
attendees
list,
that'd
be
great,
then
I
guess
in
the
topics.
Yes,
it's
a
happy
new
year,
I'm
gonna
remove
that
because
it's
not
really
relevant.
Okay.
The
first
topic
that
I
wanted
to
discuss
was
the
open,
telemetry
sdk,
open,
telemetry
distro
packages.
A
A
This
one,
I
forgot
the
link
which
I
I
started
last
year
24
days
ago,
now
that's
a
long
time
ago
and
I
haven't
gone
back
to
it,
but
I'm
hoping
to
get
back
to
it
this
week.
A
A
So
I
created
a
separate
package
called
open,
telemetry
distro,
whose
sole
purpose
is
to
configure
like
the
default
exporter,
which,
let
me
see
if
I
can
find
it
right
here
right.
All
it's
doing
is
just
telling
it's
just
setting
the
environment
variable.
A
What's
up
everybody,
hey
lynn,
hi
guys,
so
some
of
the
some
of
the
questions
that
came
up
when
I
was
chatting
with
lynn
earlier
about
this
open,
telemetry,
sdk,
distro,
kind
of
separation.
So
there's
there's
currently
this
thing
called
the
configurator,
which
I
think
we
can
get
rid
of.
The
reason
why
the
configurator
exists
today
is
that
the
sdk
doesn't
really
have
a
way
of
interpreting
some
of
the
environment
variables
that
are
currently
being
interpreted
in
the
configurator.
A
So
I
think
that
needs
to
be
moved
into
the
sdk,
so
I
will
be
doing
that,
but
then,
once
the
once,
the
configurator
once
once
that
chunk
of
the
code
has
moved
out
of
this
configurator
code
path,
I
think
the
remaining
bits
of
the
configurator
which,
if
you
look
at
it,
is
actually
pretty
small.
Let
me
just
bring
this
up
here.
A
All
right,
so
the
the
only
remaining
bits
will
be
setting
up
the
like
the
trace
provider
and
setting
up
the
meter
provider,
and
I
think
that
could
be
done
inside
the
distro
package.
So
then
that
means
that
the
distro
package
is
really
the
thing
that
people
want
to
import
if
they
want
to
use
auto
instrumentation
with
the
default
sdk.
A
C
Yeah,
what
I
mean
is
that
people
can
do
that
by
hand.
People
can
select
the
the
exp
folder
by
hand.
People
need
something
else
somewhere
to
to
do
this
kind
of
selection
only
when
they
are
using
own
instrumentation
right.
C
A
But
I
don't
think
the
two
are.
I
don't
think
the
distro
is
necessary
for
auto
instrumentation,
because
other
vendors,
like
lightsaber,
for
example,
will
want
to
create
their
own
distro
and
and
we
don't
want
to
have
the
same
default
as
the
as
the
other
default
and
like
the
open,
telemetry
distro.
So
the
open,
telemetry
distro
is
just
like
an
example
package
of
how
someone
would
go
about
implementing
their
own
distros,
really.
D
A
I
don't
think
so
because
I
don't
think
it
can,
because,
if
you-
and
if
you
put
this
inside
the
open,
telemetry
instrumentation
package,
there's
no
way
to
ensure
that
the
configuration
of
like
another
distro
has
a
chance
to
like
there's
no
way
of
guaranteeing
which
distro
would
get
loaded.
At
that
point,.
A
C
E
C
No,
I'm
not
strongly
opposed
to
have
this
into
separate
packages.
Well,
what
I'm
thinking
is
that,
if
there
is
no
other
use
case
for
these
distro,
except
for
the
instrumentation
packages,
then
they
should
be
together.
E
But
we
want
to
encourage
users
to
write
their
own
distros
right
and
what
better
way
than
taking
the
default
open,
telemetry
distro
package
as
an
example
like
we
separate
it
out
as
its
own
piece
of
logic,
so
that
it's
not
confusing
for
users.
So
then
auto
instrumentation
package
would
only
include
stuff
that
is
related
to
auto
instrumentation,
and
the
disk.
Drills
will
only
be
like
a
lightweight
package
that
take
like
that
depends
on
the
auto
instrumentation
but
instantiates.
E
You
know
the
the
the
default
x,
otf,
exporter
and
stuff
yeah,
all
right.
So.
E
Wait,
sorry,
I
don't
think
it.
I
think
it
just
depends
on
the
otlp
exporter.
That's
it
right,
alex
the
the
distro.
A
B
E
Like
it
does
kind
of
make
sense,
because
it
only
works
for
auto
instrumentation
but
like
if,
if
vendors
were
to
write
their
own
distros,
it
would
be
the
same
thing
right
like
it
would
only
be
useful
for
auto
instrumentation.
We
don't
expect
everyone
to
add
their
distros
into
our
auto
instrumentation
package
right.
C
What
I
mean
is
that
let's
say
somebody
wants
to
create
their
own
distro
right,
so
they
need
to
have
these
requirements
filed
in
their
environment.
Variable
sorry,
they
need
this
comments,
file
which
leaves
the
dependencies
for
the
virtual
environments
and
there
they
will
have
two
lines:
instrumentation
and
distro.
A
A
A
A
E
C
Yeah
all
right,
okay!
Well
maybe
I
should
take
a
look
because
I
haven't
actually
looked
into
this
I'll.
Do
that?
Can
I
assign
you
to
it
yeah
sure,
please.
E
Wait
so
alex
so
so
the
if
the
distros
rely
on
the
base
distro,
it
would
have
a
dependency
on
the
auto
instrumentation
package.
Then
right.
D
E
I
did
yeah
so
do
we.
E
The
separate
api
sdk
packages
from
auto
instrumentation
and
they're
labeled
as
experimental.
We
talked
about
that
already.
We
have
not
talked
about
it
yet.
Okay,
sorry
did
you
have
a
question
on
what
I
added.
E
Okay,
so
we
could
talk
about
that
after
this
experimental
thing.
So
basically,
what
we
talked
about
before
the
only
issue
right
now
with
the
current
implementation,
is
that
the
sdk
depends
on
the
instrumentation
package,
and
you
know
my
only
concern
with
that
is.
I
think
we
talked
about
this
before
the
break
is
that
we
don't
want
api
and
sdk
to
stable
packages
to
rely
on
anything,
that's
experimental
and
since
nothing
auto
instrumentation
is
specked
out
or
anything.
E
We
must
label
those
as
experimental
or
we're
just
taking
it
upon
ourselves
to,
like.
You,
know,
support
this
in
the
future
as
like
non-breaking
changes
and
everything,
and
I
don't
really
want
to
do
that
until
it's
either
like
it's
like
promised,
by
open
telemetry
itself.
So
what
we
should
do
in
the
meantime
is
the
api
sdk
packages
should
have
nothing
to
do
with
auto
instrumentation.
It
has
it's.
E
Only
all
the
features
necessary
sdk
should
only
implement
stuff
from
the
api
and
nothing
in
it
should
be
related
to
auto
instrumentation
or
configuration
or
anything,
and
then
auto
instrumentation
should
be
moved
into
a
separate
package
out
or
everything.
That's
related
to
auto
instrumentation.
Right
now
in
the
sdk
package
should
be
moved
to
the
instrumentation
package.
E
I
keep
saying
instrumentation
instrumentation
as
if
there
was
two
packages
which
is
the
next
discussion
line,
but
anyways
the
the
the
thing
that,
for
this
bullet
point,
the
first
bullet
point
is:
we
will
want
to
move
everything
out
and
we
label
them
as
experimental
and
so
users
who
want
to
take
advantage
of
this
auto
instrumentation
feature
as
we're
going
to
call
it.
You
know,
is
they're
signing
up
for
potential
breaking
changes,
so
this
will
kind
of
cover
asses
in
terms
of
releasing
and
versioning.
A
Yeah,
so
I
did
talk
about
this
before
you
joined
the
call
in
around
moving
all
of
the
code
that
dependent
on
the
instrumentation
out
of
the
sdk
altogether.
So
like
the
the
still
depends
on
the
configurator
will
be
moved
into
the
at
the
distro
package.
So
so
that
dependency
is
going
to
go
away,
and
now
the
sdk
would
only
descend
on
the
api.
E
C
E
C
E
Yeah
well
as
long
as
as
long
as
we
still
have
the
release
schedule
for
api
sdk,
we
cannot
have
these
within
the
packages
that
we're
going
to
be
releasing
for
1.0,
like
that's
going
to
be
a
fact,
and
regardless
of
whether
or
not
we're
going
to
be
moving
it
out
into
a
separate
package
or
we're
just
going
to
be
having
it
like
experimental,
either
way.
The
sdk
package
cannot
contain
anything
related
to
auto
instrumentation.
C
No,
I'm
I'm.
Okay
with
that.
I
agree
that
the
sdk
package
should
not
have
anything
related
to
information,
I'm
just
curious
about
what
is
the
consensus,
maybe
in
the
open,
telemetry
community
or
among
us.
I
don't.
E
Know
I
have
in
terms
of
the
otep
I
haven't
looked
at
it
at
all,
to
be
honest,
yeah
and
if,
if
anyone
else
in
this
room
has
taken
a
look
at
or
if
you
could
link
what
that
is,
that'd
be
great.
E
Oh,
oh
nice
thanks
anyways
yeah
like,
and
it's
also
just
an
otep
right
now,
and
I
don't
think
people
are
very
concerned
with
it.
It's
it
was
like
last
updated,
may
4th
and
it's
not
in
the
specs
anywhere,
I
think
so
realistically,
like
we
cannot
act
upon
it
and
we
can't
delay
our
releases
based
upon
this.
C
So
I'm
okay-
I
just
I
just
wanted
to
make
sure
that
we
are
not
missing
anything.
E
E
All
right,
nice,
okay,
so
the
splitting
up
the
auto
instrumentation
and
instrumentation.
I
think
we
talked
about
like
away
and
alex,
and
I
I
think
we
brought
this
up
before
the
break,
but
I
don't
remember
that
the
consensus
was,
I
think,
with
the
original
thing,
for
this
was
like,
like
even
the
confusion
of
like
when
we
talked
about
those
previous
bullet
points.
E
It's
like
kind
of
confusing
when
we're
talking
about
instrumentation
right,
like
instrumentation
in
my
opinion,
should
only
relate
to
the
you
know
the
packages,
the
instrument
instrumentation
libraries
to
be
instrumented
right,
like
it,
should
only
be
like
a
simple
interface
for
like
pymongo
instrumentator.
You
know
the
the
request
instrument
like
that
it
shouldn't
have
anything
to
do
with
auto
instrumentation.
E
With
this.
In
that
case,
then,
we
can
actually
like
mark
instrumentations
as
stable
and
stuff
if
we
want
to
in
the
future,
without
relying
on
anything
auto
instrumentation,
because
auto
instrumentation
will
always
be
experimental,
or
at
least
until
it
gets
specked
out.
So
if
they
don't
have
dependencies
on
each
other,
then
we
have
can
have
like
separate
release
trains
for
them.
E
We
can,
like
you,
know,
mark
stuff,
stable
and
experimental
and
they're
not
related
to
each
other.
So
I
I
think
this
is
a
good
idea,
but
you
know
open
to
suggestion.
C
Okay,
so
if
what
you
mean
with
this
is
the
you're
proposing
to
separate
into
two
packages,
one
will
contain
the
instrument
or
base
class
and
the
other
one
will
contain
all
the
the
logic
for
and
the
command
that
is
executed
in
the
command
line
open
to
limit
for
instrumentation
and
all
that
magic.
That
happens
with.
C
C
C
A
C
So
I
mean
what
is:
doesn't
the
same
argument
apply
against
both
the
class
and
the
method
that
we
use
for
instrumentation
that
none
of
them
are
defined
in
the
specifications,
so
none
of
them
should
be
special.
E
Yeah,
that's
a
good
question.
If
you
take
a
look
at
the
versioning
specs
that
are
that
is
out
but
not
merged,
yet
we
will.
It
says:
there's
like
different
guidelines
for
instrumentation
library
packages
versus
the
api
and
sdk
packages
off
the
top
ahead.
I
can't
give
you
the
exact
verbatim
what
they
used,
but
basically
there's
like,
I
think,
there's
like
a
less
strict
protocol
for
that
and
this
there's
going
to
be
separate
releases
as
well.
E
For
those
and
we
don't
even
I
don't
even
know
whether
or
not
we're
going
to
be
calling
the
implementations,
instrumentation
stable
or
not
because,
like
like
the
community,
is
like
contributing
this,
and
you
know
us
saying
that
it's
like
ga
or
stable
or
not.
It
doesn't
really
make
any
sense
right
now.
So.
C
Yeah,
I'm
not
I'm
not
against
separating
the
things
like
in
in
this
way
I
mean
the.
The
only
question
we
have
is.
Is
that
one,
of
course
right
yeah,
where
how
do
you
draw
a
line
between?
What's
that's.
E
C
Yeah
and
the
other
question
that
I
have
that,
I'm
not
trying
to
pretend
like,
I
know
everything
right,
but
as
far
as
I
know,
the
the
only
way
to
make
our
instrumentation
happen
is
by
doing
it
in
the
way
that
we
are
doing
it,
or
at
least
the
the
only
I'm
gonna
air
quote.
This
word
correct
way
is
doing
it
in
the
way
that
we're
doing
it,
because
we
are
using
the
official
standard
library
python
component
to
to
this
exact
kind
of
action.
That
is
this
file.
B
C
Yeah
side
customize.
Yes,
so
we
can
consider
this
experimental
because
it
is
not
part
of
the
specification
but
realistically
I'll
I
I
say
that
it's
very
unlikely
that
that
we
make
a
substantial
change
in
the
implementation
of
this
mechanism.
A
Maybe
one
thing
that's
also
worth
kind
of
remembering
here
is
the
like:
the
instrumenter
library
and
all
of
the
third-party
kind
of
instrumentations
they're,
all
they're,
all,
hopefully
temporary,
in
the
sense
that
you
know.
Ideally,
what
will
happen
once
with
the
api?
Stable
is
libraries
will
implement
these
apis
themselves
and
then
the
instrumenters
will
just
kind
of
someday
disappear,
but
maybe
that's
just
being
optimistic.
A
The
open
telemetry
api,
so
currently
what's
happening,
for
example
in
java,
is,
is
different.
Library
owners
are
planning
on
implementing
open
telemetry
directly
into
the
library,
so
there
won't
be
a
need
for
like
an
additional
package
for
implement
for
instrumenting
spring,
for
example,
like
open
telemetry
will
just
be
built
into
spring.
A
Yeah,
so
it
just
means
that
instead
of
having
like
a
wrapper
library
that,
like
injects
open,
telemetry
start
spans
at
particular
points
they'll
just
be
like
those
apis
will
be
called
inside.
The
libraries
themselves
so
spring
will
implement,
like
the
open
telemetry
start
span
like,
for
example,
on
certain
operations
method,
and
because
it's
only
implementing
the
api,
then
you
know
as
long
as
it's
not
configured.
Nothing
will
happen.
They'll
just
get
like
a
no
op
or
whatever,
but.
C
D
A
Like
the
the
holy
grail
of
this
to
be
like,
ultimately
being
able
to
let
libraries
do
the
instrumentation
instead
of
having,
like
a
you,
know,
a
bunch
of
additional
packages
that
are
built
on
top
of
those
libraries.
So
just
this
is
just
obviously.
This
is
not
going
to
happen
right
away,
but
I
would
hope
that
that's
what
we're
going
to
be
shooting
for.
A
A
So
this
this
isn't
anything
new
like
there's,
there's
already
precedent
for
this.
For
for
metrics
gathering
right,
there's
different
like
mysql,
I
think,
or
maybe
postgres
one
of
those
two
implements
like
an
output
to
stat
c,
or
something
like
that.
So
it's
not
like
this
is
anything
new.
C
Yeah
yeah,
the
other
question
that
makes
me
think
about
this-
is
that
many
libraries
right
now
they
have
this
hook
mechanism
already
implemented
in
them
to
allow
third-party
stuff
to
do
things
like
class
right,
for
example,
it
has
this
hook
that
lets
you
do
whatever
you
want
before
and
after
the
request
so
well,
I
don't
know
if
we
will
be
able
to
persuade
flask
developers
to
not
use
their
hooking
mechanism
and
to
put
directly
over
limit
recalls.
H
F
E
A
E
Okay,
cool,
so
that's
that
I
think
that's
everything
that
we
determined
to
talk
about
for
those
packages,
issue
1494,
oh
right,
cool,
so
just
to
refresh
everyone's
memory
from
before
the
holidays,
we've
decided
that
basically,
the
current
issue
is
similar
to
what
we
were
talking
before.
We
don't
want
anything.
E
Talking
it
was.
G
F
I
E
I
guess
everybody
everybody
wants
to
talk
about
it.
Everyone
wants
to
talk
about
it,
okay,
anyways.
What
was
he
saying
right?
Yeah?
We
want
to
move
the
configuration
configuration,
not
configurator
configuration
api
out
of
the
api
package,
same
reasons
as
before.
E
I
think
diego
outlined
it
pretty
well
in
this
issue
and
if
you
just
want
to
read
the
tl
dr,
we
remove
the
configuration
api
and
replace
it
with
a
third-party
package,
I'm
okay
with
removing
it.
I
don't
know
if
I
want
to
rely
on
a
third-party
package
to
do
this.
I
I'm
okay
with
just
like
accessing
the
environment
variables
manually.
I
don't
know
how
much
work
that
is
but
like
I
think
this
is
what
other
languages
are
doing.
C
I'm
actually
arguing
against
my
own
creation.
I
guess
yeah
yeah,
sorry
guys!
I
I
didn't
know
we
will.
I
will
get
ourselves
into
so
much
trouble,
but
but
yeah.
What
I
think
about
configuration
right
now
is
that
we
should
we
should
not
have
it,
and
I
also
think
we
will.
It
will
be
very
hard
to
convince
or
to
persuade
people
to
put
this
into
a
specification,
because
configuration
has
absolutely
nothing
to
do
with
telemetry.
C
So
it's
completely
alien
to
the
project.
I'll
say
that
lately
you
ask:
if
we
can
just
manually
access
the
environment
variables
we
can,
we
actually
can
do
that.
It
is,
and
I
think
that
once
we
start
doing
that,
we
will
very
soon
have
somebody
open
a
pr
with
something
that
factors
you
know
the
configuration
stuff
into
one
single
place,
because
it
is,
it
is
a
pain
to
deal
with
the
strengths
and
boolean
value
and
all
that
kind
of
stuff
and
that
repeats
all
over
the
place
so
yeah.
C
I
I
think,
and
that's
exactly
why
this
configuration
thing
was
added
to
the
project
right.
So
I
think
that
we
can
try
just
accessing
that
manually,
but
I
don't
think
it
will
be
long
until
somebody
gets
tired
of
doing
repeating
the
same
code
everywhere.
Yeah.
E
Well,
yeah,
that
makes
sense,
and
I
could
see
that
happening
too
so,
which
is
why
it's
like
the
other
solution
of
what
we
talked
about
was
having
the
configuration
api
only
be
used
like
internally
or,
like
you
know,
mark
it
as
something
that
will
not
cause
anything
to
break
from
the
user
and
not
tie
it
with
anything.
That's
api
or
sdk
related,
which
I'm
fine.
E
C
E
Well,
it's
it's!
It's
pretty
much!
How
we'll
tell
people
not
to
use
the
auto
instrumentation
package
either.
You
know
like
it's
just
like
good
documentation
and
like
stuff.
That's
the
only
way
in
python.
C
That
that's
how
we
we
actually
tell
people
but
again,
even
if
we
do
that,
the
I
I'd
see
the
people
will
then
want
to
add
support
for
configuration
files
and
we'll
end
up
doing
the
exact
same
thing
that
this
other
thing
dynaconf
already
does.
I
know
this
is
a
third-party
package
and
I
know
I
also
feel
uneasy
about
having
a
third-party
dependency.
C
That
right,
yeah,
but
my
points
for
using
a
third-party
package
is
that
we
won't
be
reinventing
the
wheel
that
we
will
have
something
that's
already
much
better
than
we
have,
and
we
already
do
this.
We
already
do
that
with
rapt,
so
it
won't
be
the
first
time
that
I
don't
know.
What
kind
of
argument
is
that
right?
It's
not
much
of
an
argument.
A
C
Yeah,
in
fact,
I
think
that
the
best
thing
that
we
can
do
now
since
right
now,
we
are
only
supporting
environment
variables-
is
to
do
it
manually.
A
A
Do
you
diego,
do
you
want
to
take
this
on
since
configuration
is
kind
of
your
it's
kind
of
your.
A
E
E
E
A
F
Yeah
it
mentioned
like
3.4
it
added
now
for
3.4,
but
3.4
support.
We
dropped
three
one
support
longback,
true.
A
Yeah,
it
is
true,
I
don't
know
if
it's
still
being
used.
I
haven't
revisited
the
the
context
api
since
we
dropped
support
for
python34.
A
E
E
E
Oh
yeah,
all
right,
that's
like
it's
brought
to
my
attention
because
people
were
asking
like
how
we
maintain
our
contrib
repo
stuff
and
right
now.
E
Currently,
I
don't
know
if
it's
not
a
laziness
or
whatever,
but
we
have
the
exact
same
approver
list
and
maintainer
list
for
the
contributor
as
the
main
repo,
which
is
fine
for
now,
because
our
instrumentation
packages
are
at
a
reasonable
size
like,
but
we
could
foresee
many
like
issues
and
like
requests
for
features
and
fixes
once
we
go
open,
telemetry
goes
ga
so,
and
the
question
is
like:
if,
if,
if
random
people
are
able
to
come
and
make
their
own
instrumentations
right
and
then
they're
not
there
to
support
it
like
how?
E
How
would
we
handle
this
use
case
like
right
now,
our
current
thing
is
not
scalable,
at
least.
If
you
check
for
java,
it's
definitely
not
scalable.
We
have
like
hundreds
of
instrumentation
packages.
So
how
will
we
handle
like
this
in
the
future,
with.
H
H
And
with
the
with
the
collector,
we
sort
of
had
the
same
issue
and
what
we
I
think
settled
on
was
the
core
collector
repo
has
some
core
maintainers
and
approvers,
and
then
the
co
in
contrib.
Whoever
contributes
an
exporter
or
receiver.
What
would
be
equivalent
to
an
instrumentation
for
us
gets
to
maintain
that,
and
there
are
some
policies
that,
if
something
breaks
and
it's
not
fixed
in
a
timely
manner,
then
it's
up
for
removal
from
the
repo.
So
if
oh.
H
If,
if
someone
contributes
instrumentation,
it
doesn't
maintain
it.
B
D
H
C
E
C
Yeah
and
not
possible
to
be
an
expert
in
all
the
libraries
that
exist
just
a
technical
question.
Is
it
possible
to
give
permissions
in
a
repo
to
a
user,
but
only
for
some
set
of
specific
specific
files.
F
Yes,
yes,
like,
if
you
typing
one
link
in
the
chat
group
like
see
by
like
the
c
python,
has
this
thing
like
they
put
the
code
on,
for
you
know
separate
folders,
so
whenever
they,
whenever
people
open
some
pair
against
that
they'll
they'll
be
assigned
to
them,.
C
Okay,
but
that
means
that
they
will
only
have
like
merging
permissions
if
they
are
affecting
some
certain
files.
G
H
I
I
think
they
do
as
far
as
I
remember,
but
I
I
think
they
still
like
everything
gets
assigned
to
people
like
anyone
not
based
on
the
code
owner
thing,
but
there
was
some
talk
about
automating
it
so
like
automating,
the
pull
request
flow.
So
if,
if
someone
contributes
to
something
that
I
maintain,
then
I
get
assigned
to
it
but
but
but
I.
I
A
C
A
E
Oh
man
screw
that
man
they're
just
gonna,
leave
it
and
then
just
bounce
and,
like
you
know,
leave
it
to
us
to
maintain
it
now.
I
guess
that
that
also
comes
with
the
issue.
I
haven't
looked
at
the
away
like
the
policy
that
you're
talking
about
in
terms
of
if
it's
not
fixed
within
a
certain
amount
of
time.
It's
up
for
removal
like
what
happens
within
that
interim
time
or
that
that
thing
is
blocking
all
the
builds.
You
know,
because
the
test
is
failing
or
something.
H
Yeah,
I
don't
think
something
like
that
has
happened
yet,
but-
and
I
can't
find
the
document
that
that
lists
this,
but
I
remember
very
distinctly
that
we
had
decided
to
do
that.
So
if
there
are
issues
with
with
some
components
that
block
the
release
for
more
than
a
more
than
a
few
days,
I
think
policy
is
to
just
skip
that
component
from
that
that
specific
release.
C
Okay,
but
that
does
that
mean
that
an
issue
in
a
country
package
can
block
the
release
of
the
sdk.
H
E
E
Nice
I'll
I'll
take
a
I'll,
create
an
issue.
E
Okay,
do
we
need
to
start
talking
about
these
policies
or
like
it's
just
we
just
leave
it.
Let
go.
I
guess
collector.
Has
these
policies
somewhere
in
contributing
yeah.
A
If,
if
oa
can
find
a
policy
and
add
it
in
this
in
this
stock
somewhere,
we
can
just
kind
of
copy
it
out
and
start
from
there
and.
A
E
E
I
I
The
actual
zoom
app
we
can
only
use
like
the
chrome
extension
so.
I
E
Yeah,
do
you
wanna,
speak
your
mind.
E
Okay,
cool
cool!
So
what
we've
been
discussing
make
sense
to
you:
aaron
everything's,
fine,.
I
I
guess
the
only
thing
I
was
going
to
say
was
regarding
the
environment
variables.
I
don't
think
right
now,
they're
in
the
yaml,
but
you
know
how
there's
like
the
semantic
convention
yaml
in
the
spec.
I
think
there
might
be
plans
to
add
the
environment
variables
that
are
like
listed
in
the
spectrum.
I
Can
generate
code
from
that
and
all
the
other
languages
can
which
might
sort
of
like
mitigate
that
problem,
because
it
would
have
like
a
type
field.
So
we
would
know
what
we're
expecting
beforehand.
I
I
Basically,
there's
a
bunch
of
yaml
files
that
say
things
like
the
type
of
like
certain
resource
attributes
or
trace
attributes
right.
So,
for
instance,
like
I'm
sure
this
one
so,
for
instance,
they
have
like
http
dot,
flavor
and
stuff
like
that
and
there's
an
enum
with
the
possible
fields.
So
these
aren't
environment.
I
I
So
let
me
show
you
like,
like
we
could
just
generate
like
a
getter.
We
could
just
generate
constants
something
really
simple
like
that,
but,
for
instance,
an
open
telemetry
java.
F
I
think
there's
one
already
issue
in
my
independence.
I
think
one.
I
That
generates
that
it's
generated
for
java
and
you
can
see
it's
generating
all
the
semantic
invention
attribute
constants
for
like
gates.
I
think
these
ones
are
resource
attributes
or
actually,
maybe
just
all
of
them
so
like
we
could
already
do
this,
there's
a
tool
that
that
lets.
You
generate
these
from
a
ginger
template
and
I
think,
if
we
just
added
environment
variables,
we
could
do
something
similar
where,
instead
of
doing
like
dynamic
access,
we
would
know
the
type
beforehand
and
we
can
handle
the
parsing
and
everything.
E
I
E
I
D
Yeah
no
idea,
dude,
okay,
cool.
E
Oh
sorry,
eric
could
you
add
that
link
to
the
word
doc,
sure
sure,
yeah
and
just
kind
of
briefly
talk
about
what
we
discussed?
E
Okay,
nice.
We
have
seven
minutes
left.
I
think
that
was
pretty
good.
I
don't
like
talking
about
pr's
anyways,
but
I
could
just
jump
right
into
it.
Right,
shikon's.
Pr,
that's
a
sign
to
me
and
alex.
E
Do
you
want
to
just
talk
about
it?
Real
quick
kind
of
forgot
about
this.
F
Yes,
like
so,
the
current
current
wrapper
is
just
an
available
function
when,
when
it's
used
with
the
context
manager,
it's
giving
an
error
so
yeah.
This
is
this
changes
in
this
week's
session.
I.
A
I
would
like
to
point
out
that
you're
you're
setting
a
very
dangerous
president,
mr
khan,
are
you
telling
me
that
if
we
wait
for
a
month
before
reviewing
any
pr's,
we'll
get
more
poetry
from.
F
H
About
this,
so
so
we're
using
the
whole
sql
statements
as
span
names
and
this
pr
changes
it
to
use
only
the
statement
and
the
table
name,
but
for
most
for
db
api
and
for
sql
alchemy
for
raw
queries.
We
just
get
the
whole
statement,
not
the
broken
down
sql
statement
and
the
spec
says
we
shouldn't
be
parsing
sql.
H
So
what
I
have
done
here
is,
I
was
taking
the
first
word
from
the
statement
like
very
basic,
basically
just
truncating,
the
statement
to
first
space
or
first
tab
character
and
using
all
the
the
substring
before
that
as
the
as
the
statement
name,
so
not
really
sql
parsing,
but
very
bare
bones.
Yeah.
H
H
I
think
those
are
the
only
two
sequel
instrumentations.
We
have.
H
Okay,
so
yeah.
The
concern
was
that
if,
if
that
counts
as
burst,
sql
parsing,
I
don't
think
it
does
like
truncating
a
statement
to
just
the
first
word,
but
just
want
to
bring
bring
this
to
everyone's
attention
and
yeah.
B
H
B
E
H
I
I
think
it's
enough
in
in
our
instrumentations.
We
are
capturing
the
first
word,
which
for
sql
is
mostly,
I
mean
almost
always
the
operation
that
you're.
H
H
E
I
think
I
think
should
it
I
see,
should
it
not
be
the
the
operation
and
the
table
name
and
then
the.
H
H
E
H
We
can,
in
some
cases,
extract
that,
like
in
for
cycle
pg,
there's
a
yes
there's
a
different
api.
Where
you
have
structured
statements
there,
we
can
extract
it,
but
for
raw
sql
queries
we
have
to
then
do
sql
parsing,
which
is,
I
think,
not
worth
it
just
to
actually.
E
This
would
be
something
that,
if
we
decide
on
right
now
like
customers
would
have
to
use
right.
So
is
it
okay
for
customers
who
are
using
like
sql
instrumentations,
to
only
be
limited
to
name
plus
database
name.
This
will
probably
be
what
it
is
forever
right.
H
I
think
it's,
I
think
it's
good
yeah.
It
definitely
improves
on
what
we
have
now,
which
is.
H
F
One
other
thing
also
to
consider
here
is
like
they:
they
call
the
store
procedures
instead
of
writing
some
sql
commands.
That
should
also
be
considered
because
then,
in
that
case,
it's
not
the
operation.
It's
the
stored
procedure
that
they're
called.
F
F
No
I'm
just
saying
like
that:
zero
does
not
always
mean
an
operation
like
it's,
it
could
be
other
things.
Oh.
E
Yeah
cool
yeah,
so
I
think
we're.
H
For
what's
right
for
what
it's
worth,
I
think
hotel
node.
Does
this
as
well
the
exact
same
thing
I
just
looked
today.
A
E
A
So
there's
there's
a
couple
of
comments
to
resolve
here.
There's
a
conflict
and
there's,
I
guess
linting
still
to
be
to
be
fixed.
Do
you
want
to
fix
those?
Oh
yeah.