►
From YouTube: 2021-07-01 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
so
what's
happening,
y'all
just
having
a
good
time,
networks,
metrics,
stuff
cool,
it's
a
little
bit
past
nine,
so
we
can
just
get
started.
Damn
we
have
eight
people
today.
What
what
that's
crazy
guys!
I
remember
when
I
used
to
be
like
four
like
a
couple
weeks
ago
and
ever
since
the
nathaniel
joined
it's
like
what
the
hell
cool
you
guys
got
traces
out.
We
got
very
busy,
then
people.
B
There's
no
new
people
or
anything
so
yeah
as
usual.
Just
add
your
names
to
the
attendees
list,
nathaniel,
always
on
point
with
adding
the
topics
and
issues.
B
So
I
guess
we
can
just
get
started.
First,
one
topics
timeline
for
1.0
release
of
packages
in
contrib.
Can
they
be
released
separately?
B
I
guess
yeah,
then
you
can
just
take
it
away.
I
just
about
your
question.
B
D
That's
a
good
question.
I
mean
since
you're
a
representative
of
aws.
I
feel,
like
that's
that's
kind
of
up
to
up
to
you
to
decide
when
you
feel
like
that
package
is
ready
to
be
marked
as
stable
it
does.
It
does
bring
up
the
the
point
of
it
doesn't
make
me
think
about
assigning
code
owners.
Like
we've
talked
about
doing
previously.
C
Yeah
is
it,
I
remember,
we
talked
about
this
a
while
ago
about
the
packages
moving.
E
B
Yeah
right
now,
the
all
the
instrumentations
are
released
like
in
lockstep,
but
I
that
might
be
changing
soon,
especially
if
some
of
them
are
gonna
be
stable
and
some
of
them
aren't,
and
especially
if
we
have
code
owners
who
decide
that
hey.
I
want
this
to
be
1.0
by
xdate
and
then
they
make
strides
to
push
that
towards
that
goal.
So.
C
Okay,
thanks
yeah,
that's
really
helpful,
just
to
be
able
to
say,
because
I
think
our
thing
only
depends
on
api
and
sdk
and
since
those
are
1.0
then
I
guess
ours
could
go
1.0
but
yeah.
Okay,
thanks.
That
gives
me
an
answer
there.
That's
all
I
needed
to
know.
B
Yeah,
if
you
want
to
know
like
in
general,
not
just
for
like
specifically
the
like
the
sdk
extensions,
that
you're
interested
in
instrumentations
right
now,
like
until
the
semantic
conventions
can
be
marked
as
stable.
We
can't
mark
the
instrumentations
as
1.0,
yet.
E
B
C
No
just
if
they
can
be
released
separately
and
even
like
when
we
think
all
of
them
will
be
1.0,
but
it
sounds
like
it
depends
on.
You
know,
code
owners
and
semantic
conventions
that
that
was
the
answer
I
needed.
D
D
Part
is
so
because
we're
currently
doing
the
releases
at
the
same
time
there's
no
there's
no
real
way
for
someone
to
like
easily
maybe
create
a
hot
fix
or
whatever
and
release
it
without
involving
one
of
the
maintainers.
C
B
Oh,
I
think
I
think
we
would
have
to
like,
like
if
something
worked
well
like.
I
think
what
alex
was
referring
to
was
that,
like
right
now,
currently
only
maintainers
can
release
right.
B
So
if
there
was
ever
like
a
hotfix
issue
for
one
of
the
instrumentations
or
the
sdk
extension
that
you
care
about,
like
you
would
have
to
involve
one
of
us,
even
though
you're
the
code
owner
right
right,
so
that
that
process
needs
to
be
thought
of
like
better
and
like
one
of
the
suggestions
is
like
to
move
it
that
xdk
extension
to
your
to
your
own
repo
or
to
a
separate
repo.
So
you
don't
have
this
issue
right
right,
yeah,.
G
I
I
think
we
can
probably
use
some
sort
of
github
actions
like
some
checks
and
could
have
actions
on
that
around
tags
and
then
and
then
let
the
code
orders
push
tags
for
specific
packages.
So
if
I
let's
say
maintain
django
instrumentation,
I
can
push
django
v
1.2
tag
and
it
would
run
in
ci
and
release
the
package.
D
It
just
feels
like
right
now
we're
we're
talking
about
in
a
snake,
and
that's
that's
great,
but
if
we
could
have
a
concrete
proposal
and
and
even
like
a
the
technical
approach
that
we
could
use
to
do
this,
I
feel
like
that.
Would
that
would
give
us
a
lot
more
confidence
that
we
can.
That
will
be
able
to
manage
those
use
cases.
B
Yeah
and
also
proposal
of
like
outlining
specifically
like
what
what
ownership
means
and
like
what
what's
the
responsibility
of
actually
being
a
co-owner
of
a
specific
package,
at
least
right
now,
it's
like
currently
it's
like.
If
your
stuff
exists
in
our
repos,
then
we
we
own
it
and
we
care
about
it
right.
It's
been
all
right
so
far,
especially
for
like
a
core,
but
the
trip
is
kind
of
getting
getting
to
that
point.
Where,
like
we
can't,
we
don't
have
the
breath
or
experience
to
handle
all
those
anymore.
B
So
I
think
the
proposal
should
cover
that
as
well,
including
what
it
means
to
release
it
like
support,
hot
fixes
and
etc.
So.
D
C
It's
too
much
work
guys.
I
I
like
always
the
idea
with
the
being
able
to
push
with
you
know,
actions
too.
Another
thing
we
could
do
is
start
separating
them
separately,
like
put
them,
and
then
you
know
just
have
like
a
frequency
at
which
contrib
gets
released
because
you
just
push
them
like.
Oh
flask
has
a
breaking
change,
so
you
push
it
to
1.1
and
then
every
two
weeks,
eventually
you
know
it'll
get
in.
I
don't
think
anything
is
so
urgent
that
it
needs
to
be
more
than
that,
but
yeah.
I
agree.
C
C
Right,
that's
cool,
I
I
think
a
lot
of
I
don't.
I
know
a
lot
of
other
people's
actually
doing
it
too.
Javascript
is
getting
close
to
releasing
contrib
1.0.
So
that's
actually
why
this
one
got
brought
up
and
I'm
not
sure
exactly
how
they're
doing
it,
but
it
looks
like
they're
just
going
to
release
the
whole
repo
as
1.0.
So
I
could
look
over
what
they're
doing
really
interesting
yeah.
F
I
don't
think
they're
doing
the
contrib
1.0,
because
how.
C
D
Right,
if
you
can,
if
you
can
link
it
in
the
the
python's,
like
notes,
that'll
be
great
yeah
I'll.
Do
that
and.
C
D
I
added
a
an
action
item
in
here
that
I
can.
I
can
take
on
to
just
open
up
a
discussion
in
the
core
repo
to
put
together
a
proposal
on
how
we
should
solve
this
awesome.
B
Cool
any
more
questions
on
that
assassinate,
linked,
a
otep
in
the
chat,
looks
like
a
proposal
for
an
instrumentation
api.
B
I
personally
haven't
take
gotten
a
chance
to
take
a
look
at
this.
Yet
so
you
want
to
go
over
this,
like
real,
quick,
like
what
you
wanted
to
talk
about
or
bring
up.
B
Yeah,
thanks
for
bringing
that
up
cool,
all
right,
no
more
comments
on
that
next
up
daniel.
Is
this
the
right
way
to
merge
multiple
resource
detectors,
and
then
this
code.
C
Excerpt,
actually,
I
think,
aaron
led
me
to
what
I
was
looking
for.
He
just
posted
this
function.
That's
used
to
get
aggregated
resources
from
multiple
detectors,
so
this
looks
really
interesting.
I
think
this
answers
my
question.
Then
it
takes
in
a
list
of
resources
and
will
return
some
final
resource,
which
is
what
I
wanted.
I'm
just
asking
because.
C
A
Yeah,
but
maybe
instead
of
creating
a
new
method
or
even
passing
a
list
just
make
the
marriage
accept
multiple
positional
arguments.
C
Yeah,
it's
I
guess
it.
It's
weird
that
or
it
could
have
been
nice
if
we
had
some
definition
in
the
specifications
to
the
name
of
this
function,
because
I
showed
in
javascript
that
they
have
one
and
that's
what
I
was
looking
for.
They
had
their
function
is
called
detect
resources
and
they
take
in
a
detector,
a
library
with
the
detectors,
a
library
dictionary,
with
a
detector's
key
and
an
array
of
detectors.
F
F
I
don't
know
so
I
think
that's
part
of
it,
but
I
remember
when
this
was
worked
on.
It
was
like
sort
of
left
really
open-ended
on
purpose.
But
to
your
point,
diego,
are
you
talking
about
the
one?
That's
already
there
changing
the
signature,
or
are
you
saying
that
something
new
is
added?
You
want
to
change
the
signature.
A
Yes,
I
was
just
pointing
out
the
fact
that
you
can
just
kind
of
make
the
emerge
method
receive
multiple
of
them
without
having
to
create
a
new
one.
Just
a
python
implementation
detail.
D
D
F
I
think
it's
probably
it's
probably
in
java,
but
I
do
think
it'd
be
an
interesting
idea,
especially
since,
since
we
have
like
the
auto
instrumentation
agent.
B
B
B
Yeah,
but
whatever
it
is,
I
don't
think
it's
I
don't.
I
haven't
seen
anything
in
the
specs
regarding
that,
so
whatever
it
is,
it's
a
language
exactly.
D
B
Yeah
speaking
of
that
they're,
probably
like,
should
we
do
like
a
comprehensive,
like
components
in
which
you
can
configure
kind
of
thing
for
auto
instrumentation.
B
Right,
yeah,
I'm
pretty
sure
we
covered
the
majority
of
what
can
be
configured
early,
but
I'm
sure
we've
we
haven't
covered
all
of
them
a
lot
more
people
are
getting
more
invested
and
interested
in
auto
instrumentation.
So
I
think
we
can
expect
some
more
feature
requests
in
the
future,
so.
B
F
C
Follow-Up
to
that,
just
to
ask
for
these
detectors
again
in
java
and
javascript.
They
actually
have
the
detectors
as
like
a
package
like
aws
detectors.
Both
of
them
have
them
in
their
core
repo,
but
I
think
we're
all
pretty
well
set
up
to
have
things
in
they
contribute
both.
So
I
just
want
to
ask
if
you
guys
got
feeling
that
makes
sense
if
I
make
a
pr
to
put
it
in
contrib
repo,
if
that's
the
right
place
for
it,.
D
I
I
would
be
awake:
okay,
what's
up
there,
hello
aaron,
do
you
have
a?
Is
there
a
gcp
resource
detector
and
where
does
that
live.
F
B
D
B
Not
yet
anyways,
and,
and
also
now,
that
you
said
that
we
haven't
decided
on
where,
to
put
it
yeah
like
we
definitely
talked
about
it,
but
mike
my
gut
is
going
to
be
going
to
some
specific
microsoft
repo,
it's
interesting
that,
like
they,
they
put
semantic
conventions
for
the
specific
cloud
providers.
B
Does
that
lead
me
to
believe
that,
like
it's
going
to
be
widely
accepted
that
like
they
could
exist
in
open,
telemetry
owned
repositories?
I
don't
know
if
that's
safe
to
assume
that,
but
I
still
don't
know
the
fine
line
between
like
what
is
allowed
to
contribute.
Not
so
I
believe
a
lolita
was
supposed
to
drop
a
kind
of
a
guideline
on
that,
but.
F
Yeah,
I
think
so,
actually
the
js1,
the
js
gcp
resource
detector
is
actually
in
their
contrib
repo.
I'm
not
really
sure
why,
but
I
think
I
think
it's
sort
of
okay
as
long
as
like
you're,
okay,
with
the
licensing
as
microsoft
or
whatever
and
you're.
Okay
with,
like
you,
know,
the
copyright
being
whatever.
B
Right,
I
think
that's
the
only
reason,
or
one
of
the
only
reasons
that
we
wanted
in
the
microsoft
repo,
because
licensing's
kind
of
annoying
when
it
comes
to
open
source
for
us.
So.
F
Yeah
same
and
I
think
the
that
cloud.platform
resource
attribute
that
has
like
gcp,
you
know
like
dke
and
stuff,
like
that.
I
think
that
one
was
added
by
somebody
from
aws,
so
they
they
were
nice
enough
to
add
all
the
gcp
and
azure
ones.
So
yeah.
B
I
see-
and
I
guess
besides
that
there's
also
the
whole
like
ownership
issue
that
we
still
gotta
resolve
for
that
so
yeah.
D
I
guess
if
I
guess,
if
someone
from
like
microsoft
can
own
the
the
resource,
detector
and
the
converter
in
that
repo,
I
mean
I
I
I
think,
as
a
project
we've
all
accepted
that
the
contrib
repo
could
have
vendor
specific
code
in
it.
You
know
we
have
the
data
dog
exporter.
Currently
we
have
aws
sdk,
like
extension
there's
you
know,
there's
definitely
vendor
specific
stuff
in
all
of
the
contrib
repos
or
most
of
them
anyways.
So
yeah.
I
don't
think
it's
problem
from
that
side.
B
Yep
and
I
think
that
just
further
stresses
the
importance
of
outlining
this
process
or
proposal
quickly,
because
we're
getting
to
that
point
now.
F
Yeah
yeah,
it's
interesting,
I
feel
like
the
resource
detector
part
is
maybe
a
little
underspecified
was
actually
wondering
what
other
vendors
or
other
like
cloud
providers
are
doing
in
terms
of
like.
Are
you
going
to
provide
one
resource
detector
that
that
everybody
would
use
for
all
of
azure
aws,
and
then
it
would
output
like
this
specific,
like
ec2
or
whatever
or
you're
gonna,
have
like
individual
resource
detectors,
and
they
have
to
choose
the
right
one.
It
just
fills
in
instance,
attributes
like
I'm,
not
really
sure
what
the
best
design
is.
B
D
C
Yeah
thanks
guys,
yeah,
you
answered
my
question
and
brought
up
good
discussion
points
too.
I
don't
know
I'm
going
to
add
a
link
of
how
the
js
one
does
to
answer
aaron's
question.
I
I
like
how
they
do
it
because
they
have
a
bunch
of
separate
files
for
each
detector
and
they're,
very
lightweight,
which
is
nice
but
yeah.
I
think
that's
why
I
was
asking
a
lot
of
questions
about
you
know.
C
D
Cool
sweet,
I
guess
the
next
point
is
fine.
We're
doing
a
release
next
week,
and
I
think
I
think
the
plan
is
to
I
know
we.
We
talked
about
doing
the
release
on
tuesdays,
but
I
think
the
plan
is
to
delay
it
to
maybe
wednesday
or
thursday,
because
next
week
is
a
bit
of
a
weird
week
for
a
lot
of
folks
in
the
us.
D
B
A
Well,
I
can
give
an
update
if
that's
what
you
consider
to
be
useful.
It's.
B
Yeah
yeah
it'd
be
great
for,
like
you
know,
like
nothing
for
the
people
that
weren't
here
last
week
or
like
you
know,
not
me
and
alex
to
bring
them
up
to
speed
about
like
where
we're
at,
and
what
the
plan
is
all
right.
A
A
There
is
some
specification
written
down,
which
is
experimental
as
the
case.
The
specification
is
missing,
particularly
so.
What
I'm
doing
right
now
is
pretty
much
trying
to
base
my
base.
My
code
on
what
legend
has
done,
incorporate
the
stuff
that
is
written
down
and
filling
up,
what's
not
being
specified
yet
so
instruments
are
pretty
much
done
in
on
my
side.
Also
aggregators.
A
What's
missing
now
is
views
which
is
a
big
component
and
an
exporter.
The
aim
of
this
mini
project
is
to
implement
a
prototype.
A
There
are
a
couple
prototype
examples:
specifications
implement
them
both,
hopefully
and
then
bring
that
to
the
matrix
seg
see
if
what
can
be
done
after
after
that,
I
guess
it
will
require
an
input
from
that
sake,
to
define
the
next
step.
B
Yeah,
that
was
great
good
job
yeah
awesome.
So
I
think
it'll
be
good
for
us
to
have
some
sort
of
like
tracking
issue
that
we
discussed
with
just
like
a
bunch
of
check
boxes,
to
see
the
progress
of
what
we're
doing
and
like
it
would
be
great
to
for
people
who
aren't
as
familiar
in
the
metric
space
to
know
what
the
components
are
like
that
you're
working
on
are
actually
doing
or
if
they're
done
yet.
You
know
that's
good.
A
Yeah
definitely,
oh
I'll.
Let
the
this
explanation
be
in
an
issue
there
I'll
also
try
to
keep
the
components
documented
and
yeah.
That
should
help
other.
B
People
hey
just
curious,
the
does
like
the
processor
and
the
batcher
and
stuff
like
that
still
exist
like
I
haven't
taken
a
look
in
a
while.
A
Yes,
sorry,
I
I
did
not
mention
good
processor
in
the
indie
components,
right
yeah
right
now.
We
currently
have.
B
Instruments
aggregators
I'm
assuming
like
like
meter,
provider,
meter
and
stuff.
Those
are
still
components
right,
yeah.
B
Nice
thanks
diego
cool.
Does
anyone
have
any
other
topics
to
talk
about
in
general
before
we
dive
into
the
prs
and
issues.
B
B
All
right
cool
both
of
these
pr's
are
for
me,
each
of
them
relatively
straightforward.
I've
had
more
time
to
actually
work
on
stuff
and
open
telemetry.
I
haven't
put
out
a
pr
in
a
while
so
cool,
so
this
pr
in
the
contribu
repo
pertains
to
an
issue
in
which
we
want
to
have
a
consistent
mechanism
to
avoid
double
instrumenting.
So
when
users
call
instrument
multiple
times
and
as
you
guys
know,
some
of
the
instrumentations
also
have
like
specific
instrument.
B
Underscore
component
kind
of
methods
like
instrument
app
instrument,
connection
want
to
make
sure
that
the
relationship
between
them
is
defined
and
like,
if
there's
actual
specific
use
cases
for
them.
B
For
example
like
if
a
user
calls
instrument,
and
then
they
want
to
un-instrument
a
certain
app
we'd
expect
it
to
you
know
not
produce
any
telemetry
like
this.
This
could
happen
when,
like
you
know,
user's
app
is
auto
instrumented
or
something,
but
they
know
that
they
don't
want
a
certain
application
in
their
app
to
produce
anything.
B
B
This
underscore
is
instrumented
by
open.
Telemetry
is
the
kind
of
the
key
word
that
we're
using
for
all
of
the
functionality
related
to
identifying
whether
or
not
a
component
is
instrumented
or
not
whether
or
not
we
use
that
for
preventing
double
instrumentation
is
just
like
one
feature
of
that,
but
this
is
a
generic
mechanism
that
we're
going
to
be
using,
obviously
feel
free
to
like
suggest
improvements
for
this.
B
This
is
just
like,
what's
been
being
used
for
the
majority
of
the
instrumentations,
so
there's
also
also,
I
also
made
some
other
like
consistency
based
changes,
but
don't
be
scared
about
the
number
of
files
changed.
It's
it's
all,
pretty
pretty
straightforward.
D
Any
questions
I
I
just
added
a
question
at
the
bottom
of
the
tying
this
back
to
what
tricondrt
was
posting
earlier.
I
want
calendar
of
this
mechanism
for
preventing
double
instrumentation,
something
that
should
be
specified
in
this.
B
I
wasn't
aware
of
instrumentation
api,
but
yeah.
It
seems
very
geared
towards
java
right
currently.
D
B
B
In
this
discussion,
oh
it's
not
a
discussions.
No
tab,
yeah
yeah,
makes
sense
to
me.
B
D
B
B
Okay,
awesome
yeah.
I
will
go
ahead
and
do
that
oh
looks
like
srikant
left
a
comment
I
didn't
address.
Should
we
rather
delete
this
attribute
when
uninstrumented?
B
I
don't
see.
Why
not?
I
only
did
this
because
previously
the
change
was
just
to
leave
it,
but
I
don't
mind
removing
it
at
the
same
time.
I
don't
know
like
if
there's
any
big
repercussions
of
just
leaving
the
field,
because
I
think
we
chose
this
key
to
specifically
specified
to
be
only
used
by
open
telemetry.
So
I
don't
know.
D
I
don't
think
sorry
to
go
back
to
the
instrumentary
question.
I
don't
think
instrumental
with
an
e
r
is
a
word.
It's
not
a
word
right,
but
it's
it's
a
verb
in
french,
though.
B
D
B
Okay,
cool
so
yeah.
If
people
can
just
take
a
look
at
this
that'd
be
great,
I'm
just
trying
to
get
some
consistency
across
the
instrumentations
and
then
maybe
we
could
probably
use
this
to
drive
the
otep
so
good.
B
B
Okay,
next
issue:
this
is
the
bug
from
a
while
ago
that
alex
filed
basically
right
now,
the
otlp
exporter,
the
spans
that
are
coming
in
are
grouped
based
off
of
only
the
the
resource
and
the
exporter
finds
like
the
first.
B
Instrumentation
info
grouping
that
is
found
and
uses
that
to
group
all
of
the
spans.
So
that's
why
you
can
see
here
the
otlp
or
the
collector
output
that
everything
all
the
spans
are
placed
under
this
instrumentation
library.
You
know
the
requests,
and
rather
we
expect
span
one
to
be.
Oh
sorry,
span
0
to
be
this
span,
1
to
be
the
internal
instrumentation
info,
which
is
the
name
of
the
file,
so
this
change
just
fixes
that
it's
very
straightforward.
B
So
please
take
a
look
at
this
when
you
have
the
time,
that's
pretty
much
it
that
any
questions.
E
So
yeah
I
I
brought
up
this
question.
Like
the
question
that
you
asked
in
in
log
c,
I
haven't
gotten
any
response,
I'll
I'll,
read
I'll.
Try
like
I'll
try
to
like
dm
the
people.
The
respect
log
expect
people
and
see
what
they'll
have
to
say
about
this.
B
Cool
cool
and
so
for
more
context
for
everyone.
I
believe
so.
The
current
the
current
implementation
of
the
log
processes
right
now
we're
trying
to
mirror
the
tracing
pipeline
as
much
as
possible.
Currently,
the
tracing
pipeline
only
allows
the
tracer
provider
to
flush
which
will
flush
everything
in
the
corresponding
span,
processors,
which
is
fine
and
the
tracers,
don't
have
the
ability
to
flush
or
anything.
B
B
Logs
pertain
to
which
log
emitter-
and
this
was
never
an
issue
with
tracing
because
tracers
cannot
flush
individually,
but
log
emitters
can
so.
This
is
the
issue
that
sukanth
was
bringing
up
to
the
sig
and
we'll
just
wait
for
what
guidelines
should
be
done
for
that
so
cool,
but
anyways
yeah.
So
I
wouldn't
let
that
block
this
vr.
B
You
know
it's
just
a
maybe
a
2d
or
anything,
because
everything
else
looks
good.
So.
B
B
C
B
All
right,
this
is
what
we
talked
about
last
week,
great
more
specifically
option
two
moving
into
the
sdk.
Yes
exactly
yeah.
I
think
this
was
like
majority
of
the
decision.
I
think
it'd
be
great
if
yeah
I
think
alex
did
like
if
people
could
comment
on
it,
so
we
have
like
history
and
like
tangible
support.
I
also
agree
with
this
solution.
B
So
let
me
just
just
do
that
real,
quick,
so
yeah
that
thing
that's
pretty
much
what
you
got
to
do
you
just
bring
it
up
at
a
sig
and
then
people
do
it
on
the
fly.
So
I
know
I
love
it.
You
get
a
lot
of
response
yeah,
so
I
would
I
would
I
would
I
think,
just
maybe
like
wait
until
end
of
this
week
or
beginning
of
next
week.
Just
wait.
If
anyone
has
any.
You
know
big
objections
for
this,
and
then
we
can
just
deem
this
as
resolved.
D
Yeah
awesome
cool
thanks
if
you
wanna,
if
you
wanna,
if
you
wanna
use
my
unbiased
option,
one
option:
two
mechanism
to
vote,
you
can
feel
free
to
do
so.
C
C
No,
I
guess
maybe
just
tldr,
for
the
people
who
weren't
here
last
week
sure
so
we
have
been
noticing
that
sometimes
the
packages
that
we
instrument
like
flask
or
other
python
packages
they
release
major
version
pumps
or
breaking
changes,
will
either
cha
break
or
not
break
our
instrumentation
packages.
So
it
makes
it
kind
of
confusing.
So
do
people
expect
to
install
the
instrumentation
package
and
that
works
for
all
the
breaking
changes
across
that
library
across
anything?
D
I'm
curious
what
people
like
to
me.
It
always
helped
me
think
through
these
when
we're
talking
about
specific
packages
and
I'm
curious,
how
like
something
like
boto
3,
for
example,
would
would
look
in
in
either
cases
like
if
I'm,
if
I'm
a
user,
it's
a
you
know
for
those
who
aren't
familiar
with
boto.
I
think
both
photo
one
and
two
are
being
deprecated
and
voter
three
is
kind
of
the
package
that
people
know
about.
D
There's
a
I'm
asking
I'm
bringing
this
up,
because
someone
specifically
asked
for
photo
three
support
earlier
this
week,
but
I'm
I'm
curious
like
would
we
release
open,
telemetry
instrumentation
photo
and
that
would
cover
one
through
three,
even
though
most
people
know
photo
three
as
like
photo
three
and
not
photo.
G
G
C
I
think
django
is
a
good
example.
I
think
bottle
three
actually
uses
photocore
and
we
already
have
instrumentation
for
both
core
and
that's
why
you
know
transitively.
We
have
instrumentation
from
boto3,
but
we
could
check
into
that
yeah
this.
This
issue
came
about
because
flask
just
recently
upgraded
to
version
2.0
and
they
didn't
break
any
changes
with
our
instrumentation,
but
through
auto
instrumentation.
This
is
important
because
we
say
that
our
instrumentation
package
only
supports
version
one,
but
really
it
does
support
version
two.
C
We
just
you
know
someone
needs
to
verify
it
and
confirm
that
on
the
package,
but
maybe
for
version
three.
We
won't
be
so
lucky
and
at
that
point,
what
do
we
do?
Do
we
release
instrumentation
for
flask
version
three
without
releasing
version
two,
or
do
we
just
logic
branch
in
the
original
package
and
make
sure
we
instrument
if
flask
is
version
one
if
flask
is
version
two
flask
because
of
version
three,
so
something
like.
B
That
I
think
I
think.
B
Something
that
oh
sorry
for
interrupting
that
potentially
was
already
different
and
breaking
these
issues
related
to
that
apparently
there's
a
new
way
to
add
middlewares
for
django
in
the
2.0
upgrade.
So
sorry,
oh,
wait
go
ahead.
G
Yeah
yeah,
I
think
that's
a
good
good
example.
Alex
commented
on
the
pr
and
brought
this
up.
I
think
I
think
we
need
to
look
at
like
what's
more
common
is,
are
differences
more
common
or
like
commonalities,
more
common.
Like
a
better
word,
I
think
if
we
do
multiple
instrumentation
packages,
then
like
95
percent
of
the
instrumentation
for
django,
two
three
four
is
going
to
be
the
exact
same
code.
G
So
how
do
we
share
that
code
and
if
we
need
to
fix
a
bug
or
at
a
future,
we
need
to
do
it
in
three
different
places?
So
it's
going
to
be
a
huge
pain
to
maintain
this.
So
do
we
then
does
the
django
three
instrumentation
depend
on
do
import
it
and
right
like
build
on
top
of
it,
or
so
there
are
going
to
be
differences
in
logic,
and
but
I
think
overall,
like
if
you
look
at
the
bigger
picture,
that's
having
some
logic.
G
Branches
is
going
to
be
probably
a
lot
more
manageable,
so
I
I
suggest
we
keep
it
the
way
it
is
for
now
and
just
look
at
it
as
case
case
basis.
So,
for
example,
if
let's
say
if
flask
3
is
extremely
different
from
plus
two
completely
re-engineered,
maybe
for
that
case
we
can,
as
a
special
case,
have
a
different
instrumentation
like
on
the
case-to-case
basis,.
B
B
D
Yeah,
I
mean
I
wonder
if
we
should
have
some
kind
of
like
some
kind
of
compatibility
checks.
That's
common
across
instrumentation
libraries
we're
going
to
go
with
option
two
here,
just
so
that
at
least
that
code
is
separated
out
from
the
rest
of
the
instrumentation.
But
I'm
I'm
looking
for
inspiration
from
the
the
dd
trace
and
contrib
packages
that
were
donated
when
we
originally
started.
D
Looking
at
instrumentations
for
the
python
contrib
repo
and
you
can
get,
you
can
get
a
sense
for
how
much
work
had
to
be
done
there
because
they
have
there's
an
instrumentation
for
a
bunch
of
different
versions
of
things.
So,
if
you're
looking
for
patterns,
that's
a
good
place.
B
B
All
right
so
in
order
to
drive
this
forward
yeah,
just
please
thoroughly
look
through
the
options
we
have
maybe
there's
even
a
third
option,
but
no,
I
can't
think
of
one
currently
and
please
express
your
opinions
and
concerns
with
each
and
hopefully
we'll
come
up
with
the
conclusion.
B
D
One
one
thing
to
keep
in
mind
is
that
creating
a
matrix
for
a
matrix
for
different
versions,
supported
for
instrumentation
packages
is
not
it,
it's
not
an
insignificant
amount
of
work
and
it
will
make
build
times
longer,
but
I
mean
maybe
that's
just
something
we
have
to.
B
C
Just
a
quick
one
comes
to
mind
now
that
alex
said
that,
on
the
original
thing
that
I
mentioned
about
releasing
country
packages
separately,
if
they
were
in
their
own
repos
then
build
times
wouldn't
be
too
bad,
because
I
agree:
build
times
are
pretty
bad
right
now
so
might
be
related.
You
know
the
build,
wouldn't
be
so
bad
if
it
had
a
separate
repo,
but
personally
I
think
it's
better
to
have
it
all
in
this
repo.
C
F
F
B
F
C
Well,
I
also
mentioned
that
one
of
the
big
reasons
why
this
came
up
was
because
this
is
for
auto
instrumentation
right,
I
feel,
like
most
users
are
going
to
eventually
use
auto
instrumentation
for
everything,
so
it
having
separate
packages,
I
think,
makes
it
easier
to
verify
at
least
that
you
have
support
for
that
specific
major
version.
Instead
of
you
know,
you
have
to
go
back
to
the
other
one
and
you
have
to
like
make
sure,
through
logic,
branches
that
it
does
work
for
both
of
them.
C
So
if
it
was
just
for
auto
instrumentation
people
would
just
you
know,
open
someone's
instrument,
and
it
would
find
all
the
packages
for
you
without
you
having
to
do
it.
I
agree
if
you
do
manual,
it's
going
to
be
harder,
but
I
think
honest
rotation
is
the
biggest
win
here
too.
So
there's
that
to
consider
too
that's.
B
B
Okay,
cool
yeah-
that
was
great,
like
you
know,
please
just
comment
on
this
issue
for
whatever
opinions
that
you
have
might
have
or
what
we
talked
about
today.
B
And
I
think
that
was
the
last
issue
that
we
had
on
the
agenda.
Oh
looks
like
we're
perfectly
on
time.
Does
anyone
have
any
last
minute
things
topics
they
want
to
talk
about
before
we
end
the
meeting.