►
From YouTube: 2021-07-15 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
As
I
was
saying
before,
I
accidentally
welcome
everybody
to
another
edition
of
the
python.
B
A
All
right,
we
have
a
great
thing
for
you
all
today,
because
we
have
a
a
couple
of
very,
very
interesting
subjects
to
discuss.
A
A
Instrumentation
back
to
core-
and
I
guess
alad-
can
we
talk
about
this
last
week?
Should
we
talk
about
the
release
that
we're
trying
to
machine.
B
At
first
yeah,
that's
that's
why
I
put
the
instrumentation
back
to
core
discussion
topic
in
the
in
the
list
here.
I
just
put
it
after
nathaniel's
1.0
contribute.
C
C
A
Now,
definitely
in
fact
we
were
just
taking
a
look
at
your
vr.
Let
me
see
if
I
can
share
my.
D
A
A
Nice
all
right,
so
since
we
have
a
lot
to
talk
about,
let's
say
we
start
right
now.
First
topic,
nathaniel
reasons
why
we
should
move
contribute
to
one
o
go
ahead.
A
C
Yeah,
so
I
definitely
want
to
come
here
and
find
out
what
we
need
to
do
to
get
to
1.0
and
maybe
discuss
any
blockers
for
not
going
to
1.0,
at
least
on
aws
side.
We're
trying
to
like
give
a
date
and
understand
when
we
can
put
all
the
languages
together
at.
F
C
And
for
many
of
the
other
languages
they're
right
now
in
discussions
of
either
they
already
went
to
1.0
or
they're,
coming
up
with
timelines
and
the
last
few
things
that
they
need
to
get
there.
So
I
know
python
has
progressed
a
lot.
I
know
we
have
it
for
sdk
and
api,
like
I
mentioned
here,
java.net
javascript
didn't
go
are
all
hoping
to
be
1.0
by
the
end
of
next
month.
So
for
us,
what
would
that
mean
specifically
for
contrib
all
the
instrumentation
packages
and
everything
to
say
we're
at
1.0?
A
Well,
I'm
not
sure
if
we
have
even
had
discussed
this
before
just
to
answer
to
your
question
that
if
there
is
something
stopping
us
from
doing
that
right
now,
I
can't
think
about
any
reason,
any
technical
reason
not
to
do
it,
except
maybe
for
one,
and
that
could
be
that.
Maybe
we
don't
want
to
keep
updating
everything
in
in
loksa,
but
instead
updating
every
package
individually
depending
on
your
development
progress,
which
is
something
that
I
think
we
had
discussed
before.
C
A
D
That
kind
of
stuff-
hey,
hey
alex,
wasn't
the
reason
why
we
were
doing
the
whole
not
pinning
the
versions
anymore.
So
we
could
do
this,
so
it
could
release
different
versions.
D
D
Yeah,
so
I
guess
that's,
I
think
the
releasing
different
versions
is
fine.
I
think
the
issue
for
moving
and
contributing
like
taking
something
as
stable
is
is
pretty
enormous.
Effort
like
it
took
us
like
months,
even
after
code,
completion
to
get
api
and
sdk
and
all
the
other
ones
to
a
stable
state.
So
like
are
you
asking
like
whether
or
not
we
can
move
it
to
1.0
like
some
alpha
version
or
actually
like
1.0
stable,
like
mark
it
as
stable.
C
D
To
think
about,
like,
like
think
about
all
the
the
workarounds
and
hacky
stuff,
that
we
and
issues
that
we
had
to
face
because
we
put
api
and
sdk
to
1.0,
and
then
we
found
some
like
breaking
stuff
later
on
like
like,
namely
like
diego's
whole,
like
public
symbol
thing.
This
suppressed
instrumentation
thing
like
so
much
right,
and
I
know
that,
like
the
like
ultimate
open,
telemetry
has
a
migration
guide
of
like
backwards
breaking
changes
and
stuff
like,
but
then
we
have
to
apply
that
every
single
time.
D
So
we
have
to
be
very,
very
sure
that
the
arguments
for
doing
this
is
like
is
worth
what
we're
going
to
be
doing
right.
So
if
the
argument
is
that,
like,
oh
okay,
other
companies
will
not
take
a
dependency
on
this
unless,
if
it's
stable
right,
that's
fair
but
like
then
there
comes
the
issue
of
like
okay.
We
we
have
contrib
as
a
repository
to
exist
for
like
instrumentations
and
extensions
that
you
know
the
the
the
support
ability
and
the
maintenance
hasn't
really
been
clearly
defined.
D
Yet
so,
if
we,
if
we
put
this
to
1.0-
and
we
don't
have
a
clear
like
supportability
structure
and
or
the
resources
to
do,
this,
then
we're
just
like
kind
of
digging
our
own
grave
here
right
as
soon
as
we
put
it
at
1.0
then
like
like
whoever's
name,
is
on
it.
It's
like
okay,
you're
you're,
like
in
charge
of
like
fixing
everything
and,
and
since
you
said
it's
stable,
if
it's
breaking
you
have
the
responsibility
to
fix
it
like
who
is
gonna.
Do
that
right
like
we
cannot?
D
Possibly
you
know,
have
this
promise
for
every
single
instrumentation
to
do
this
in
a
timely
manner.
That's
one!
That's
one
problem
right!
Well,
that's
sorry!
That's
the
second
problem!
Besides
the
whole,
you
know
backwards
compatibility
thing
so.
B
D
B
I
think
some
of
the
stuff
is
what
is
what
nathaniel
is
suggesting
in
this
checklist
below
right,
like
like
things
like
identifying
code
owners
for
packages,
if
you
can
just
scroll
scroll
down
a
little
bit
diego,
so
maybe
the
the
way
to
move
this
forward
is
to
capture
these
concerns
and
and
try
and
figure
out
how
we
can
address
them.
B
Like
I,
I
agree
that
ensuring
that
we
have
all
of
the
changes
we
want
to
prevent
us
from
having
to
deal
with
backwards,
incompatible
changes
in
the
future
or
or
having
to
write
hackarounds,
essentially
for
not
breaking
backwards.
Compatibility
is
important,
but
I
guess
I
guess
understanding
what
that
looks.
Like
is
probably
the
the
most
like
the
biggest
unknown
for
me
is
like
I.
I
don't
know
what
that
finish
line
looks
like
for
instrumentations,
for
example.
I
you
know
there's
obviously
more
than
just
instrumentations
in
that
control
repo,
but.
D
I
mean
why
can't
we
release
contrib
like
individually
for
two
1.0
like
when
we're
saying,
can
we
move
we'll
contribute
to
one
point:
does
that
mean
move
all
instrumentations
to
1.0
or
everything
that
exists
in
contributor
1.0?
What's
the
what's,
it's
not
really
like
that
either
right
like
core
like
not
everything
in
core
is
1.0.
Only
selective
packages
are
1.0.
F
C
D
Oh,
no,
that's
not
the
issue.
It's
like.
Obviously
we'll
go
to
one
point.
Eventually,
it's
just
that
like
we're
the
timing
of
it
like
we
want
to
do
it
now,
but
ideally,
like
everything
is
specked
out,
everything
was
marked
as
stable,
so
we
have
open
telemetry
staff
of
approval,
so
you
know
then
we're
comfortable
with
putting
it
1.0.
D
B
B
I
guess
two
things
that
come
to
mind.
One
of
them
is
like
today,
the
instrumentation
api
is
not
even
in
the
stack
for
example,
and
like
these
contrib
packages
will
eventually
rely
on
this
instrumentation
api
and
like
what?
What
does
it
mean
to
release
a
package
for
1.0
if
the
spec
is
not
even
present
like?
What
are
we
actually
saying
we're
supporting
there.
C
G
B
D
D
F
It's
kind
of
related,
so
what
what
I
was
trying
to
like?
Why
why?
I
think
this
is
like
there's
a
lot
of
effort
like
people
are.
You
know
like
there's
a
lot
of
effort
going
on
to
to
on
this
area,
so
it
it
might
be
risky
to.
You
know
to
right.
Go.
D
C
C
A
Oh
okay,
sure,
so,
no
sorry,
there's
something
else
is
the
fact
that
these
that
the
third-party
libraries
for
which
the
country
packages
instruments
may
also
introduce
making
changes
by
releasing
a
new
major
version.
So
we
also
need
to
be
prepared
to
know
what
to
do.
If,
for
example,
there's
a
new
class
version,
that's
not
compatible
with
the
current
instrumentation.
B
Right,
I
guess
the
I
guess
that
was.
The
second
thing
that
I
want
to
talk
about
is
what
does
1.0
mean
for
the
requests
package,
for
example
like
I,
I
would
expect
that
this
would
mean
we
have
a
very
clearly
defined
matrix
of
versions
that
we
support
for
requests
with
this
version
and
anything
that's
outside
of
that
scope,
like,
if
request
launches
a
new
version.
I
don't
know
what
they're
at
now,
but
if
they
release
a
new
version
and
it
has
a
bunch
of
backwards
compatibility
incompatible
changes.
What
does
it
mean
for
our
release?
Like?
A
H
C
I
opened
an
issue
here
we
talked
about
this
a
few
weeks
ago
and
I
ran
into
that
with
last
to
your
point,
diego
our
instrumentation's
pinned
the
version
that
they're
doing
right
now,
so
even
if
flask
updates,
it
won't
break
us
because
we
pin
what
version
of
flask
this
is
compatible
with,
but
we
do
have
a
pending
issue
that
I
mentioned
in
the
chat
and
I'll
put
on
the
doc
to
solve
this,
because
we
don't
have
a
solution
for
it.
Yet
correct.
I
B
B
Very
clear
make
it
very
clear,
but
also
make
it
tested
like
currently
our
testing
pipeline
basically
tests,
whatever
version
of
like
requests
you
install
and
like
if
it
works
great.
If
not,
then
it
causes
a
problem,
but
I
feel
like
we.
We
should
have
at
least
like
different
version
tested
in
ci,
so
that
we
can
confirm
that
right.
It's
working.
D
Hey
so
nathaniel
yeah,
so,
besides
from
everything
that
we
talked
about
in
this
list,
this
great
list
that
you
identified
it's
also
like
after
the
one
to
do
1.0
we
kind
of
just
have
to
do
this
exact
same
thing.
We
did
with
the
api
sdk
and
everything
else.
It's
like,
oh,
you
know
make
sure
our
docs
are
good.
You
know
read
the
docs
are
built,
you
know,
ci
does
exactly
what
we
expect,
etc,
etc.
D
Yeah
we
kind
of
have
been
not
as
diligent
with
like
documents,
documentations
and
stuff
and
examples
for
instrumentations
in
the
contrib
repo.
But,
like
you
know,
it's
just
some
more
work
that
we've
got
to
do.
There's.
A
Some
other
sorry,
I
just
wanted
to
point
out
that
there
is
some
other
scenario
that
we
might
need
to
consider
and
I'm
guessing
that
nobody's
going
to
like
this.
But
probably
if
we
decide
to
have
separate
release
processes
for
everything
in
country,
it
may
be
more
convenient
to
have
one
ripple
for
every
country
package.
A
I'm
sure
it's
doable,
it
just
may
be
more
convenient
to
separate
this
into
multiple
reboots.
First
reason
that
comes
to
my
mind
is
that
if
we
don't
do
this,
in
fact,
we
have
the
problem
that
same
problem.
Right
now
is
that
there
is
no
meaningful
history
for
a
package
I
mean
the
history
is
just
a
bunch
of
commits
that
relate
to
a
bunch
of
different
projects.
So
you
you
can't
read
the
history
and
find
a
meaningful
development.
D
Well,
I
think
the
the
history
would
just
be
a
bit
harder
to
find,
but
it's
still
there
right,
like
the
commits,
might
relate
to
multiple
packages,
but
you
can
still
always
find
out
what
the
origin
behind
it
is
right.
B
D
H
Yeah,
I
don't
want
to
prolong
the
discussion
too
much
in
the
interest
of
time,
but
I'm
I'm
curious
about.
Like
you
said,
the
symmetry
conventions
are
essentially
stable,
but
then
you
said
cementing.
Conventions
for
trace
are
experimental,
which
is
true.
I
think,
like
yeah,
my
my
my
biggest
concern
besides
just
the
api
and
all
that
stuff
we
said
was,
is
the
actual
like
output
telemetry,
that
we
make
needs
to
be
stable
and
there
is
a
scammer
thing.
H
I'm
not
super
familiar
with
it
to
be
completely
honest,
but
I
don't
think
the
like
compatibility
between
scammers
like
there's
supposed
to
be
some
transformation
between
minor
versions.
For
instance.
I
don't
think
that
it's
implemented
anywhere.
So
if
we
did
have
that
and
sure,
maybe
maybe
we
could
we
could
guarantee
like
stability.
H
C
Yeah,
I
know
what
you
mean:
the
skin,
the
schema
posted
a
they
post,
a
yama
file,
every
time
they
update
and
from
1.4
to
1.5.
There
was
nothing
to
update,
but
you're
right.
I
don't
think
on
the
python
site.
We
have
a
way
to
read
those
files
and
then
make
the
translations
to
like
have
backwards,
compatible
attributes
for
all
that,
when
you
mentioned
that
the
semantic
conventions
is
experimental,
it's
only
experimental
like
on
the
attributes
right,
so
the
apis
and
the
the
other
points
trace
are
stable.
It's
just
like
you
know.
C
B
Hey
is
the
I'm
I'm
also
not
super
familiar
with
the
schema
guide,
or
the
schema
itself
is.
Is
the
idea
there
that
each
instrumentation
will
like
identify
which
schema
it's
adhering
to.
I
Has
yeah,
I
think,
that's
the
yeah,
that's
the
idea
that
sdk
would
inject
the
schema
version
in
spans
or
metrics
and.
F
H
G
H
Yeah,
does
that
also
mean
we
have
to
remove
like
any
hard-coded
string
and
only
use
semantic
convention
attributes
in
our
like
official
instrumentations,
for
instance,
because
like
how
would
be?
How
would
we
even
know
this
gamma,
if
we're
not
using
like
a
semantic,
the
semantic
invention
package
right.
C
Yeah,
so
all
this
being
said
right
like
that's,
why
I'm
saying
we're
very
interested
in
helping
us
get
to
1.0
for
contrib,
so
this
is
the
list
that
I've
identified
right
now.
Wait
for
instrumentation
api
otep
to
get
merged.
Wait
for
this
issue
for
major
upstream
packages
bumps
to
happen,
probably
make
another
issue
to
make
all
the
attributes
and
contribute
use
the
semantic
conventions
package.
F
D
What
add
like
an
excerpt
somewhere
of
what
it
means
to
be
a
code
owner
share
responsibilities?
Yeah
sounds
good.
H
G
A
C
I
mean
we
can
talk
about
the
in
the
issue,
but
personally
I
think
yeah
you're,
right
dale.
I
think
it'll
be
really
hard
to
pick
a
code
owners
for
packages.
I
honestly
find
that
to
be
a
harder
requirement
to
get
and
I
feel
like
we
should
have
like
remove
that
requirement
from
putting
things
to
1.0,
because
we
won't
be
able
to
find
co-ownership.
B
A
B
If
you
have
no
idea
if
it's
actually
like,
if
you
don't
have
enough
expertise
to
know
that
it's
doing
the
job
that
we're
saying
it's
doing
right
like
I
feel
like
that's
that's
kind
of
ultimately,
what
we're
up
against
there's
just
a
bajillion
libraries
that
none
of
us
have
maybe
worked
with,
and
I
I
don't
think
it's
it's
not
necessarily
like
you
know
if
someone
is
just
doing
a
drive-by
commit
and
they're
they're
like
hey,
I'm
using
this
library
cool
like
I
want
to
commit
this
code.
Great,
that's
fine.
I
D
C
Yeah,
I
think
what
you
said
alex
is
a
good
point.
If
someone
wants
it
badly
enough
and
like
they
could
read
the
code
and
they
say
oh
yeah,
this
is
fine
like
I.
I
believe
that
this
would
be
okay
with
my
expert
knowledge
of
sklearn.
Then
they
can
own
it,
and
then
you
know
hopefully
best
case
scenario.
It
never
breaks
and
people
can
forever
use
it,
but
if
it
does
at
least
we
have
someone
to
email.
B
A
Excellent,
that's
excellent
question.
Is
there
something
else
that
we
need
to
discuss
about
that
or
can
we
move
to
the
next.
D
Yeah,
sorry,
oh
man,
just
like
sticking
up
a
long
time,
but
in
terms
of
timelines
like
nathan,
I
know
you
have
like
a
lot
of
stuff
like
a
lot
of
issues
and
pr's
out
already
like.
Is
this
something
that
you
want
us
to
focus
on
or
like
prioritize
rather
than
the
other
stuff
or.
C
I
I
I
mean
I
think
end
of
august
would
be
nice
to
get
these
then
like
this
is
probably
what
I'm
going
to
spend
most
of
my
time
now
is
getting
these
issues
fixed
and
ready
so
that
you
guys
can
look
at
it.
I
just
will
mention
them,
as
I
finish
them,
and
if
we
can
finish
by
august,
that's
great,
if
not
that's
fine
too
I'll,
just.
C
A
A
We
have
moved
it
since
then
to
country,
and
now
we
are
considering
moving
it
back
to
core,
because
to
be
honest,
because
the
the
release
process
for
this
release
has
been
affected
by
a
bunch
of
issues
related
to
this
alex
piece
right.
B
Yeah
I
mean
so
the
the
I
think
the
symptom
that
we're
seeing
is
there
is
a
dependency
on
installing
instrumentation
in
the
core
repo
because
of
the
suppress
suppressing
api,
key
to
press
key
or
whatever,
and
I
think
a
that.
That's
really
just
a
symptom
like
that
key
should
shouldn't
be
probably
in
the
instrumentation
package.
But
then
this
created
a
bigger
discussion
around
well.
B
What
should
and
shouldn't
be
in
the
core
repo,
and
I
think
I
think,
there's
no
real,
compelling
argument
to
keep
the
instrumentation
packaged
into
the
contributor
because,
as
as
maintainers
and
as
approvers
of
double
come
to
python,
we're
obviously
very
concerned
if
people
are
making
changes
to
the
instrumentation
package
because
it
impacts
everybody
who's
using
it,
which
is
all
the
instrumentations.
B
So
I
think
I
think
we
should
just
move
it
back
again.
Ultimately,
the
the
real
solution
to
this
weird
dependency
that
we're
having
with
the
with
the
builds,
is
to
not
have
that
suppressing
key
in
there
and
have
it
somewhere
in
the
api,
but
until
we're
confident
that
there's
a
mechanism
that
we
can
call
supported
for
that
we're
probably
not
gonna
move
it.
So
this
solves
our
current
build
issues,
but
it
also
like
logically,
there's
no
reason
why
it
should
be
in
contro
versus
core.
A
No,
yes,
I
agree
with,
without
the
reason
why
I
think
mutation
should
been
construed
in
cold
weather.
It's
because
it
defines
an
api
that
others
follow
and
that
api
is
defined
by
ourselves.
We
define
that
api
and
pretty
much
everything
else
that
is
in
the
country.
Repo
can
be
implemented
by
people
outside
of
this
call.
B
I
think
the
original
reason
to
move
it
out
was
that
there
wasn't
any
definition
for
the
actual
instrumentation
in
the
spec,
but
at
the
same
time
that's
currently
in
progress.
I
think
the
first
otap
you
know
talks
about
instrumentation
and
other
instrumentation
as
part
of
the
like
core
of
open
telemetry.
B
D
I
D
Yeah,
I
think
instrumentation
is
important
enough
now
that,
especially
with
the
auto
instrumentation
stuff
and
the
disc,
the
the
digital
stuff,
you
know
that,
like
we,
we
would
need
to
maintain
it.
D
All
right
sounds
good
guys,
easy
decision.
Anybody
have
an
objection
to
this
quick
question.
H
Where
does
the
the
auto
instrumentation
live?
Is
that
in
core.
H
So
like
with
oa's
argument
that,
if
that's
going
to
be
maintained
by
the
open
slum
tree,
like
authors,
shouldn't
that
be
in
the
corby
bow
too,
it's.
I
If,
if
a
package
has
a
mentor
who
is
not
a
hotel
python
engineer
or
approver,
then
it
has
to
live
in
the
country?
Otherwise
it's
our
country.
C
C
A
Yeah
yeah
we're
trying
to
move
it
first:
okay,
that
will
solve
a
bunch
of
issues
that
we're
having
with
this
release
and
talking
about
releases
here,
there's
a
pr.
C
A
And
that
it's
just
me
trying
to
learn
the
release
process
so
sorry
about
that,
okay!
Yes,
this
is
the
pr
that
we
hope
turns
into
a
new
release.
A
We
had
a
few
technical
issues
with
the
release
script.
Those
are
sold
right
now
and
now
we
are
having
a
more
important
issue
that
is
being
caused
by
the
transformation
package
in
the
country.
We
have
already
decided
to
move
it
back
and
that
should
fix
this
issue
now
I
don't
want
to
take
credit
away
from
nathaniel
who
kindly
submitted
a
pr
to
fix
permanently.
The
temporary
fix
that
I
tried
to
add
to
solve
the
issue
caused
by
open
telemetry
instrumentation
being
in
the
country
with
people
and
nodding
the
core
one.
A
So
I
think
that
if
we,
when
we
move
this
back,
none
of
these
fixes,
my
temporary
fix
or
the
better
fix
that
nothing
you'll
propose
will
be
necessary.
Still.
Thank
you
very
much
nathaniel
for
your
efforts
in
providing
one
better
fix
than
mine.
C
It
made
me
rethink
why
we
needed
it
in
the
first
place
and
I
think
regardless
this
will
still
be
helpful
because
it's
kind
of
confusing,
I
think,
right
now
to
say
docs
requirements,
because
our
talks
build
downloads,
these
docs
requirements,
but
the
only
reason
we
added
these
links
was
because
the
read
the
docs
build
was
breaking
because
it
didn't
have
these
ones
because
read
the
docs
downloads
from
this
file,
but-
and
so
therefore
downloads
from
the
latest
repo.
But
talks
shouldn't
be
downloading
from
this.
C
It
should
be
downloaded
from
whatever
people
are
committing
on
their
branches
on
the
local
directory,
because
tox
has
access
to
it,
but
read
the
docs
doesn't
have
access
to
it.
So
after
you,
after
we
move
the
instrumentation
package
to
core
I'll
look
out
for
this
pr
to
see.
If
we
can
fix
that
with
the
same
fix
that
I
have
right
now,
all
together,
so
that
we
don't
have
this
ugly
get
evs
vcs
thing
in
the
file
anymore,
oh
yeah,
we
can
follow
up
with
that
later.
A
Yeah,
there
is
only
one
point
that
I
think
alex
mentioned
before
was
that
for
the
documentation
we
kind
of
need
to
pull
code
directly
from
the
main
branch,
because,
if
not,
we
can't
pick
documentation
changes
is,
is
that
is
that
right,
alex?
That's.
D
G
A
later
discussion
right,
we
can
talk
about.
Aaron
commented
on
okay,
okay,
yeah,
sorry,.
A
Okay,
yes,
so
I
think
the
well
this
issue,
I
guess,
can
be
solved
by
fixing
this
one
and
we
can
move
to
this
one
from
nathaniel
go
ahead
and
assemble
these.
C
Yeah,
so
this
will
just
solve
the
issue
or
we'll
just
make
it
cleaner.
After
we've
moved
the
instrumentation
one
aaron
made
a
good
point
that
we
can't
download
it
from
pi
pi,
because
the
the
docs
also
needs
the
latest
changes.
So
I
think
the
only
thing
that
we
need
to
fix
is
this
read.
The
docs.yaml
file
will
also
install
using
that
ugly
get
url.
C
If
you
scroll
down
a
little
bit,
it
says
using
pip
download
from
here
from
the
repository,
and
that
should
fix
this
so
that
talks
uses
the
files
in
its
own
repository
and
read.
The
docs
still
uses
the
latest
by
pulling
from
the
repo.
Although
now
that
I
look
at
it,
I
think
it
might
need
if
it's
doing
latest
it
might
need
a
hash
to
be
able
to
do
it,
because
otherwise
this
might
just
pull
the
latest
tag,
but
either
way
we
can
close
this
pr
and
solve
that
later.
C
H
What's
the
difference
between
having
that
in
the
constraint
file
versus
having
it
in
that
yellow
file,
I'm
not
sure
I
understand.
C
I
think
it's
just
a
bit
cleaner.
I
think
it
defines
the
intentions
better
because
right
now
in
the
talks
that
in
I
file
here,
you
see
we
already
had
like
in
the
red
it's
installing
the
toxin.
Is
there
open
source
instrumentation
right,
which
is
in
the
repo,
but
then
in
the
docs
requirement
file.
It
was
also
downloading
instrumentation,
so
they
were
both
trying
to
install
it.
B
So
yeah
the
one.
The
one
thing
that
I
wanted
to
call
out,
though,
is
if
we,
if
we
do
decide
to
do
this,
like
we
wouldn't
be
aware,
when
the
builds
for
docks
break
the
so
like,
if,
if
tox
is
breaking
or
not
breaking,
for
example,
but
then
the
actual
rededocs
that
are
breaking,
we
wouldn't
know
it.
B
H
F
D
Also
question:
does
anybody
know
what
like
the
docs
requirements?
Text
purpose
is
like
what
is
that
used
for.
H
Yeah,
it's
used
for
read
the
docs
specifically,
so
you
see
it's
the
first
line
in
this
reading
docs.yaml,
but
you
can't
run
like
arbitrary
code
for
read
the
docs.
You
can
only
specify
whatever's
in
the
cmo.
You
can't
I
mean
you
could
probably
hack
around
to
do
it,
but
but
that's
the
reason.
It's
in
a
separate
file
like
that.
D
Okay,
so
like
is
that
only
because
we
we
put
the
requires
in
the
rededicamo
like
conceptually.
If
we
didn't
have
wreath
docs
right,
like
was
what's
the
docs
requirement
used
for,
like
my
understanding
before,
was
that,
like
users
can
see
their
docs
requirement.txt
and
then
pip
install
that
and
then
I
should
be
able
to
run
all
the
examples
or
something
like
that
was
my
understanding
before.
That's
nothing.
To
do
with.
H
D
No,
it
doesn't
okay,
so
in
that
case,
then,
in
terms
of
like
the
examples
and
stuff
like
we
just
it's
up
to
the
user's
discretion
to
to
set
up
everything
themselves
right.
D
H
H
A
All
right
so
can
we
move
to
the
next
topic
this
case
we
have
daniel
again.
G
D
C
Sorry
I'll
be
quick
about
this.
This
is
something
I've
been
working
on
for
a
while.
It's
something
that
we
need
to
have
parity
between
all
the
languages.
We
already
do
this
on
javascript.
In
java,
I
just
added
in
our
same
sdk
extension
a
bunch
of
resource
detectors
for
users
who
are
running
open,
telemetry
python,
on
aws
services.
I
added
unit
tests
as
much
as
you
can
test
without
being
on
the
actual
environment,
and
this
is
my
colleague
who
already
approved
it
and
another
one
hopefully
will
have
a
chance
to
review
it.
F
C
C
A
C
Yeah,
so
there's
been
quite
a
few
long
comments
that
even
I
haven't
read
through
in
the
last
few
days
on
these
pr's,
but
I
did
want
to
highlight
that
the
two
pr's
should
be
independent
of
each
other,
like
I
think
the
biggest
thing
that
we're
worried
about
is
that
distros
are
conflicting
and
can
you
have
more
than
one
district?
What
does
it
mean
to
install
a
distro,
but
this
pr
should
be
mostly
independent
of
those
decisions.
C
This
is
just
to
move
out
some
of
the
items
that
are
in
open,
telemetry,
distro
up
into
sdk
in
private
classes,
I'll
mind
you
as
a
way
for
other
distros
to
make
use
of
these
really
helpful
methods.
So
it
doesn't
say
anything
about
whether
you
can
install
multiple
distros
or
you
can
only
have
one
it's
just
to
make
it
available
for
other
people
to
make
distros,
because
otherwise
we're
just
going
to
be
copying
a
lot
of
code.
It's
a
pretty
small
pr.
It
just
kind
of
moves.
C
A
Yeah,
I
think
these
two
issues
are
actually
very
related:
the
location
of
the
distro
code
and
the
decision.
If
we
want
to
have
we
want
to
allow
for
allow
for
more
than
one.
This
will
be
installed.
Let
me
explain
so
I
am
proposing
something
different
and
what
I'm
proposing
is
that
we
have.
A
We
allow
the
user
to
have
multiple
displays
installed,
and
if
that
there
is
more
than
one
distro
being
installed,
then
the
user
must
use
and
then
define
an
inverter
variable
to
decide
which
distro
should
be
used
and
the
reason
why
I
think
this
will
affect
this.
Other
discussion
about
the
common
code
is
that
if
we
follow
this
approach,
I
believe
that
we
will
not
be
moving
any
code
into
the
sdk,
but
instead
we'll
just.
A
Have
the
distro
code
exist
in
the
in
the
open,
telemetry
register
package,
probably
as
part
of
an
abc
that's
defined
and
makes
an
interface
the
others
should
implement,
and
the
way
that
code
will
be
reused
and
shared
between
these
rows
will
be
just
the
usual
inherited
from
a
parent
class.
A
C
I
see
you're
kind
of
on
the
other
spectrum,
then
because
on
one
side
we
have
people
who
say
we
should
only
have
one
distro.
But
if
we
go
with
your
solution
and
we
don't
move
out
this
useful
functions,
then
the
only
way
you
can
have
open
damage-
distro
aws
is,
if
you
have
that
one
and
you
have
the
open
symmetry
distro
installed
at
that
point,
you
must
have
multiple
distros
installed.
Am
I
correct.
A
Yes,
with
one
exception,
is
the
sorry
it's
some
detail
I
didn't
mention.
I
believe
that
we
should
provide
a
default
distro
that
will
be
like,
like
we
have
in
like
in
everywhere
else,
like
we
have
like
a
default,
you
little
provider
base
or
some
of
that,
and
that
default
this
road
does
not
count.
I
mean
only
when
you
have
three
distros
the
default
one.
A
A
C
E
C
I
Okay,
so
so
I
was
saying
that
there
are
probably
there
are
two
problems
here
and
we're,
in
my
opinion,
we're
like
mixing
up
mixing
them
up.
So
one
issue
is
whether
users
should
be
able
to
install
multiple
districts
and
then
without
uninstalling,
one
just
specify
which
one
they
want
to
use.
I
cannot
think
of
a
use
case
where
a
user
would
want
to
do
that
it.
I
tried
very
hard,
but
couldn't
come
up
with
the
use
case
for
this,
so
the
other
problem
is
all
distro.
I
Authors
want
to
reuse
other
distros
as
libraries,
but
if
they
do,
then
we
are
essentially
installing
multiple
plugins
and
then
we
have
this
concept
about
which
plugin
is
being
used.
So
I
what
natalian's
approach
is
looks
quite
good
to
me.
I
I
think
it's
a
in
in
practice
the
simplest
one,
but
if
we
really
wanted
to
be
able
to
use
other
distros
as
libraries,
I
think
a
very
simple
solution
would
be
to
have
would
be
for
distros
to
have
some
additional
metadata,
and
in
that
metadata
we
would
have
lighted
weight
or
a
priority,
which
would
be
just
a
number.
So
the
default
district
would
ship
with
zero
and
we
have
light
steps.
Plunk
and
negative
registers
will
shift
with
10
and
then
the
open
telemetry
instrument
command
just
sorts
by
this
weight
and
just
fix
the
highest
one.
I
And
if
someone
wants
to
use
aws,
destroy
as
a
base
and
then
create
another
industrial,
all
they
have
to
do
to
ensure
that
users,
when
they
install
their
distro,
that's
the
one
that'll
be
used.
They
just
need
to
bump
the
priority
from
like
oneplus
or
the
number
should
be
higher
than
the
library
they're
using
right.
I
So
if
I,
if
I
use
it
to
list
this
row
as
base-
and
it
has
priority
10,
all
I
have
to
do-
is
to
set
my
priority
20
in
metadata
and
I'm
guaranteed
when
users
install
my
distro,
even
though
it
will
pull
in
two
or
three
other
distros
mine
will
be
used
100,
so
on
only
issue.
Here
is
what,
if
users
manually
install
multiple
distorts
that
have
the
same
priority.
In
that
case,
we
just
place
an
exception,
because
we
don't
support
end
users
to
install
multiple
systems.
I
G
A
But
but
I
mean
in
this
case,
if
you
were
sorry,
we
only
have
like
two
minutes
and
I
don't
think
this
is
going
to
be
enough
time
for
us
to
completely
discussed
this
issue
right
now.
I
think
the
the
arguments
for
and
against
all
these
ideas
that
we
have
are
distributed
in
several
pr's
and
several
issues.
A
So
I
suggest
this
I
will
create
a
new
discussion
and
I
will
try
to
bring
in
that
discussion
all
the
arguments
that
have
been
proposed
so
that
we
can
put
all
the
discussion
in
only
one
place
and
then
hopefully
make
make
a
decision
a
little
bit.
C
Oh
go
ahead,
so
what
I
want
to
point
out
is
that
we
already
voted
on
this
right.
We
made
an
issue
several
weeks
ago
and
people
commented
and
already
voted
for
one
or
the
other.
That's
why
I
went
ahead
and
made
the
pr
and
got
approvals
for
it
and
put
it
so
it's
it
seems
kind
of
redundant
to
me
to
make
a
new
issue
with
all
the
points
again.
A
Other
side
right
yeah
and
I
apologize
because
I
actually
forgot
to
vote,
and
then
I
saw
that
some
people
had
voted
already.
I
introduced
my
comments
and
then
a
new
discussion
came
out
of
it.
So
I'm
sorry
if
this
feels
redundant
to
you
nathaniel
it
surely
is
it's
truly
it's
redundant,
but
right
now
our
situation
is
that
these
ideas
have
been
spreading
into
a
lot
of
different
places.
So
I'll
do
an
effort
to
bring
them
back
in
because.
C
Yeah
there's
only
this
pr,
I'm
saying
is,
should
be
separate
from
the
overall
distro
discussion.
So
if
you're
looking
for
them,
you
should
find
just
one
issue
and
then
two
pr's
at
the
very
least,
this
first
pr
should
be
able
to
go
independently
because
it
works
with
your
solution
too,
but
yeah.
If,
if
you
want
to
open
a
new
one
I'll
I'll,
be
happy
to
add
my
comments
on
it
too,
and
we
can
come
up
with
a
discussion
there
next
week,
all
right.
Thank
you.
Thank
you.
A
D
Yeah,
sorry,
if
you're
not
getting
to
your
pull
request,
we
could
add
it
to
the
top
for
next
week.
A
All
right
so
we'll
be
discussing
this
next
week.
Thank
you,
everybody
for
your
time
and
your
ideas.