►
From YouTube: 2021-07-14 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
A
B
I
know
we're
still
waiting
on
people,
but
since
I'm
new
I
figured
I'd
introduce
myself
briefly,
I'm
john
john
church,
I'm
open
source
contributor
member
of
the
node.js
package
maintenance
group
who
sent
me
over
here
to
open
telemetry.js.
B
I
guess
maybe
a
couple
weeks
ago
at
our
after
our
meeting,
I
was
looking
for
a
project
to
start
getting
involved
in
again
and
to
contribute
to,
and
somebody
said
that
maybe
open
telemetry
could
use
some
help,
and
so
I
spent
the
past
couple
weeks
trying
to
get
up
to
speed.
I'm
mostly
here
just
to
observe-
and
you
know
maybe
ask
a
couple
questions,
but
I'm
not
trying
to
get
in
the
old
way
or
anything
like
that
today,
but
just
want
to
say
hi
to
y'all.
B
I've
talked
to
to
daniel
and
also
valentin
personally
or
just
we've
connected
online
and
I'm
starting
to
look
at
some
of
the
docs
and
examples
and
basically
just
wrap
my
head
around
the
project
and
whatnot.
So
hi
y'all.
C
B
D
Okay,
before
we
get
started
here,
there
was
another
entry
at
the
top
here,
but
it
looks
like
it
got
removed,
I'm
not
sure
who
added
it,
but
probably
bart.
Are
you?
Do
you
not
want
to
talk
about
that
anymore?.
D
So
I
guess
the
first
item
we
have
here
is
browser
stack
testing.
I
know
I've
been
saying
I
was
gonna
do
this
for
a
while,
but
I
did
reach
out
to
the
browser
stack
team
and
I
was
put
in
touch
with
their
open
source
team
and
they
do
sponsor
open
source
projects
with
full
access
to
the
platform.
So
we
will
have
five
user
licenses.
D
I
def.
I
know
that
bart
definitely
wants
one,
but
anyone
else
that
needs
a
user
license
for
browser
stack
for
open,
telemetry
testing.
D
One
small
limitation
is
that
it
they
are
for
testing
websites
and
mobile
apps,
not
necessarily
for
libraries,
so
we
may
need
to
create.
I
don't
know
like
a
sample
application
to
start.
I
I
really
don't
know
I've
never
used
browser
stack.
So
I
don't
know
if
bart,
if
you
have
more
familiarity
with
their
platform
but
yeah
I'll
get
in
touch
with
you
after
the
speeding
and
try
to
get
you
a
license.
Does
that
sound?
Okay,
yeah?
D
Okay,
second
item
on
the
agenda:
here
I
created
a
project
to
track
all
of
our
blocking
issues
for
ga.
I
went
ahead
and
created
a
couple
more
this
morning.
Just
the
things
that
off
the
top
of
my
head,
I
could
think
of
that.
I
know,
are
blocking
our
release
currently.
D
If
you
think
that
something
should
block
the
ga,
I'm
not
sure
who
has
permission
to
add
things
to
projects,
but
if
you
don't
go
ahead
and
comment
on
an
issue-
and
I
will
add
it
to
the
project,
if
you
do,
you
can
go
ahead
and
add
it.
The
worst
thing
happens
is
I'll,
just
remove
it.
If
I
don't
agree
so
this
is
sort
of
what
what
I'm
gonna
use
to
track
our
progress
as
we
go
so
yeah.
That's
all.
I
really
have
to
say
about
that.
D
D
Yeah,
just
a
small
definition
of
what
it
what
I
mean
by
blocking
here,
bugs
obviously
block
the
release
any
required
tooling,
for
the
release.
I
know
that's
something
that
that
I've
been
handling,
but
I
don't
know
if
anyone
else
has
any
issues
here
that
they'd
like
to
bring
up
anything
required
by
the
spec
is
obviously
blocking
the
release.
D
I
think
that
we've
actually
covered
everything
in
the
1.0
spec.
At
this
point,
carlos
did
our
spec
review
a
while
ago,
and
we've
already
knocked
out
the
issues
that
he
brought
up.
So
I
think
we're
good.
There
changes
to
the
instrumentation
api,
I'm
not
sure
about
this
one.
D
I
actually,
I
have
a
an
item
to
talk
about
a
little
bit
later,
whether
we
think
the
instrumentation
api
should
be
part
of
the
initial
release
and
then
things
that
change
the
setup
and
configuration,
because
once
we
go
to
1.0,
anyone
that
has
a
setup
should
continue
working
when
we
make
new
releases,
so
yeah
go
ahead
and
add
any
issues
or
prs
that
you
think
belong
in
that
project.
F
So
once
once,
the
sdk
goes
to
ga
or
1.0,
we'll
contrib
packages
that
are
using
the
1.0
apis,
also
able
to
go
to
1.0.
D
The
contrib
1.0
is
being
considered
separately.
I
know
that
ted
zwo
is
working
on
an
instrumentation
working
group
to
define
you
know
what
is
the
stability
guarantee
of
a
1.0
instrumentation
like?
Does
the
the
output
in
terms
of
the
attributes
and
stuff?
Does
that
count
as
part
of
the
stability
guarantee
or
not,
and
and
some
things
like
that,
I
think,
still
need
to
be
decided.
F
And
so
will
the
contrib
repo
also
be
switching
to
independent
versioning
like
like
the
core
repo
is
so
that
it
can
have
like
different
packages
when
they're
at
different
states
of
readiness
go
to
1.0
independently?
I
think,
ideally,
we
will
yeah.
D
F
Yeah,
I
know
I
think,
that's
the
direction
that
some
other
cigs
are
heading
as
well
for
different
states
of
readiness.
So,
like
just
one
last
question
for
contrib
packages,
if
it's
not
instrumentation
things
like
propagators
and
stuff
like
that
like
and
those
have
kind
of
like
easier
stability
requirements
than
the
nuances
of
an
instrumentation
library,
will
those
potentially
be
able
to
go
earlier
or.
D
D
So
as
three
maintainers
as
the
contrib
grows
to
you
know
tens
or
hundreds
of
packages
we're
not
going
to
be
able
to
pay
attention
to
all
the
small
details
on
every
single
one.
So
for
a
package
to
go
to
1.0,
I
want
to
be
able
to
assign
someone.
You
know
you
for,
for
instance,
on
the
amazon
packages
to
say
this
person
is
responsible
for
reviewing
and
ensuring
the
stability
of
this
package
and
things
like
that.
But
I'm
sure
there
will
be
other
requirements
also,
but
that's
the
one
that
it
really
sticks
out.
G
Yeah,
I
have
a
quick
question:
do
we
have
like
any
date
that
we're
targeting
to
finish
this
project
by.
D
You
know
the
original
target
date
I
think
was
july
of
last
year,
so
I
mean
yes
and
no.
A
lot
of
the
other
sigs
have
started
to
go
ga
what
they're
tracing,
but
not
all
of
them.
I
think
we're
fairly
middle
of
the
pack.
At
this
point
I
would
like
to
have
it
done
certain
like
by
the
end
of
august.
I
I'll
be
pretty
disappointed
if
we
don't
have
it
done
by
the
end
of
august,
but
I'm
hesitant
to
assign
a
date,
because
it
seems
like
that.
G
Yeah
yeah,
I'm
just
in
terms
of
like
assigning
bugs
that
are
in
this
project
to
people
it
might
be
good.
You
know
if
we
know
what
we're
targeting,
how
how
many
people
we
need
to
take
up
the
bugs
and
how
like
how
many
need
to
be
assigned
and
stuff
like
that.
G
G
Yeah
cool
and
then
I
had
another
question
so,
like
you
put
bugs
here,
like
obviously
you
know,
we
can't
fix
everything
before
because
you
know
there's
there's
probably
a
big
backlog,
but
I
was
wondering
like
what
do
we
consider
like
a
bug
that
we
can
fix
in
a
in
a
stable
way,
something
that
maybe
would
be
in
like
a
minor
release,
verse
things
that
we
absolutely
want
to
finish
before
we
do
the
1.0.
D
Yeah,
so
I
guess,
when
I
say
bug
I
mean
a
bug
that
would
that
where
the
fix
requires
a
breaking
change,
I
suppose,
if
it's
an
internal,
you
know
like
a
regular
bug,
fix
releases
can
happen
after
ga
and
I'm
sure
will
happen
all
the
time
after
ga.
D
So
just
because
it's
a
bug
doesn't
mean
it's
blocking,
but
if
it
requires
a
change
to
an
interface
or
something
like
that,
then
I
you
know.
I
suppose
we
would
consider
it
on
a
case-by-case
basis,
most
bugs
probably
don't
qualify,
but
some
bugs
might.
G
Yeah
definitely
yeah
just
asking
because
in
the
python
zig
we
sort
of
we
did.
We
did
the
api
and
sdk
1.0
a
while
ago,
and
we
we've
of
course
run
into
bugs
and
stuff
and
things
where
we
would
need
to
break
an
interface
we've
sort
of
worked
around
that
like
adding
a
different
method
or
or
leaving
the
old
one
available
and
stuff
like
that,
so
yeah
yeah.
I
agree
with
what
you
said.
It
makes
a
lot.
D
Yeah,
it's
definitely,
you
know
always
possible
to
fix
it
in
a
backwards
compatible
way,
but
sometimes
you
know,
while
we're
not
at
ga
it's
nice
to
fix
things
the
right
way
while
we
can
without
having
to
do
backwards,
compatibility
hacks.
G
D
All
right
severn
it
looks
like
you
just
joined
the
call,
or
just
put
your
name
on
the
list.
Do
you
have
an
update
on
the
the
documentation
for
the
core
repository,
or
would
you
like
to
talk
about
that
at
all?
I
apologize
if
you
already
talked
about
it
last
week.
I
wasn't
here.
A
Yeah,
no,
don't
don't
worry
so,
as
you
might
have
seen.
I
I
the
first
thing
I
did
is
a
quick
update
on
the
docs
in
general,
so
because
some
of
the
examples
have
not
been
working,
I
think
I
I
reached
reached
out
to
wired
a
around
that
also
with
the
examples,
because
there
we
have
some
same
requirements
around
the
docks
and
examples
to
to
to
ask
the
question
like
hey:
how
can
we
make
them
consistent
like
work
again
and
again,
but
yeah?
A
A
All
of
them
are,
let's
say
optional,
but
I
thought
like
yeah,
maybe
they're,
like
I
put
another
page
for
the
exporters,
so
that
they're
easier
to
find
yeah.
That
has
been
the
things
I
I
looked
into
so
far.
D
Okay,
thank
you.
I
appreciate
the
work
you're
doing.
E
Yeah,
so
let's
play
it
yeah,
I'm
still
looking
into
it.
So
I
I
gonna,
I
think
busy
with
work,
would
hope
to
pick
it
up
like
from
next
week
on
I'm
just
gonna
work
together
with
with
him
on
it
and
see
if
we
can
come
up
with
a
good
way,
good
approach
that
works
for
us.
A
D
That
doesn't
mean
it's
not
happening,
I'm
sure
that
some
sigs
probably
have
more
integration
testing
than
we
do,
but
I
don't
know
if
that
is
specifically
around
their
examples
or
anything
like
that.
D
Yeah,
if
we
could
run
the
examples
as
tests
that
would
sort
of
kill
two
birds
with
one
stone,
we
would
not
only
make
sure
the
examples
are
consistently
working,
but
that
would
work
well
as
an
integration
test.
So
if
we
could
do
something
like
that,
I
would
for
sure
be
in
favor
of
that.
H
Hey
guys,
I
can
mention
just
on
the
python
side
for
the
docs
the
examples
check
for
import
statements
that
they
work
and
those
need
to
all
be
aligned,
but
I
think,
actually
running
the
code.
It
doesn't
do
that.
So
that's
just
on
the
python
site,
there's
probably
a
different
javascript
solution
that
we
can
come
up
with
here.
H
D
H
D
Okay,
yeah,
our
our
examples
are,
are
currently
linted
but
they're
not
run,
which
I
think
would
be
a
huge
advantage.
If
we
could
get
that
working.
D
I
was
going
to
say
only
run
if
they
get
updated,
but
then,
if
you
update
something
that
you
know
one
of
their
dependencies
or
something
like
that,
I'm
not
sure
how
difficult
that
is.
If
we
include
them
in
the
learn
on
monorepo.
That
makes
it
easier
because
you
can
do
you
can
filter
by
dependencies
with
learner
sub
commands.
D
D
D
Okay,
this
one
is
a
question
for,
for
everybody,
I'd
like
to
get
input
from
everybody,
but
at
the
end
of
the
day
the
maintainers
will
end
up
making
this
decision
together.
D
But
when
we
do
release
ga
do
we
want
to
release
all
of
our
tracing
packages
at
the
same
time
as
1.0,
or
would
we
prefer
to
release
individual
packages
as
1.0?
One
example
that
I
can
think
of
is
the
semantic
conventions
package
that
one
probably
will
be
ready
to
go
to
1.0
before
any
of
the
others
it
may
already
be.
D
D
D
G
Okay,
I
think
the
the
actual
conventions
aren't
super
stable.
So
I
don't
know
if
that
that
one's
actually
a
good
candidate,
because
you
know
like
if
you
change
a
key
or
something
it
would
be-
a
breaking
api
breakage.
D
Well,
the
the
conventions
are
included
as
part
of
the
1.0
specification,
so
they
should
not
change
in
a
breaking
way.
G
I
know
like
since
the
resource
ones
changed,
maybe
like
a
month
ago
we
just
when
we
when
we
regenerated
in
python
it
was
changed.
G
D
D
I
admit
that
I'm
not
all
of
that
familiar
with
telemetry
schemas,
but
it
was
my
understanding
that
that
was
the
goal
was
to
be
able
to
map
those
sorts
of
changes
so
that
the
sdks
don't
have
to
worry
about
it
and
that
the
the
backwards
compatibility
concerns
could
be
sort
of
loaded
to
the
collector
right.
D
I
guess
probably
we
would
want
to
reach
out
to
the
tc
about
that
yeah,
but
that's.
D
From
my
perspective,
1.0
just
means
once
somebody
has
an
application
that
uses
the
you
know
an
instrumentation
that
uses
those
semantic
inventions.
Then
we
shouldn't
push
a
change
that
makes
that
not
compile
or
anything
like
that.
If
the,
if
the
values
change,
that's
more
of
a
a
less
obvious
answer,
and
I
suppose
that
the
tc
probably
would
need
to
weigh
in
on
that.
G
Yeah
yeah,
so
just
one
more
note
on
that,
I,
if
you
open
that
link,
it
does
say
they're
experimental
for
like
missing
semantic
conventions
at
the
top
there
and
I
believe
in
python
we
haven't.
We
did
not
include
that
as
part
of
our
stable
release.
G
Link,
oh
in
the
chat.
Sorry
sorry.
D
G
Okay,
cool
then,
maybe
back
to
the
original
question,
my
only
concern
there
would
be
like
if
you
dependency
wise,
like
if
you
don't
release
them
in
an
order
where
you
can
actually
install
something.
So
I
I
think
that
that
would
just
have
to
make
sure,
but
I
think
at
a
certain
point,
you'd
probably
have
to
release
a
bunch
of
them
together
right.
D
At
the
very
least,
we
need
to
release
them
in
like
dependency
tree
orders,
so
you
have
to
release,
leaves
first
so
like,
for
instance,
core
doesn't
depend
on
anything
else,
so
that
could
go
to
1.0
and
all
the
0.x
packages
could
still
depend
on
the
1.0
version
of
that
the
same
way
they
depend
on
the
1.0
version
of
the
api,
but
there
there
might
be
some
packages
that
have
to
be
released
at
the
same
time,
but
I
don't
want
to
release
anything
like,
for
instance,
the
tracing
package
depends
on
the
core
package.
D
E
E
D
So
I
don't
think
there
have
been
any
breaking
changes
between
1.0
and
1.5.
I
would
say
anything
required
by
1.0
specification
would
block
the
ga
release
if
it's
required
by
a
later
version
of
the
spec,
then
it
won't
block
rga
release,
but
it
will
be
a
high
priority
after
ga.
D
If
anyone
knows
of
breaking
spec
changes,
please
let
me
know,
but
I
don't
think
there
have
been
any.
D
H
D
It
is,
but
it's
not
part
of
the
trace
api.
This
is
just
essentially
the
data
that's
produced
by
the
the
tracing
sdk.
So
oh.
G
D
So
I
guess
we
didn't
really.
We
had
some
discussion,
but
nobody
really
voiced
an
opinion.
Is
that
because
people
don't
have
strong
opinions
or
because
they
don't
want
to
say
them
or
is
this
at
the
end
of
the
day
like
I
said,
this
is
something
that
the
maintainers
will
end
up
deciding,
but
if
people
have
input
now
is
the
time.
G
Yeah,
I
would
say
for
me
I
I
kind
of
prefer
them
to
be
released
together.
Maybe
that's
just
based
off
the
precedent
of
other.
What
other
sticks
have
done
in
terms
of
like
having
a
nice,
blog,
post
and
stuff
like
that,
I
think
people
would
be
a
little
confused
if
all
the
packages
weren't
1.0,
when
we
do
like
say,
hey,
we've
reached
reached
that
milestone
and
I'm
I'm
I'm
curious.
What
kind
of
like
safety,
like
you
mentioned,
daniel
that
it
would
be
a
little
bit
safer?
What
were
you
thinking.
D
I'm
thinking
if
we
release
10
packages
as
1.0
all
at
the
same
time
the
chances
that
one
of
those
packages
has
some
bug
that
requires
an
immediate
fix
is
higher
than
if
we
release
one
package
at
a
time.
So
if
we
say
we
release
10
packages
on
on
wednesday
and
two
of
them
have
bugs
that
immediately
need
fixing,
then
we
have
two
high
priority
bugs
that
need
to
be
done
kind
of
at
the
same
time
right
around
the
release.
D
G
D
That's
just
I
don't
know
if
that
even
makes
sense,
but
that
was
the
way
that
I
was
thinking
about
it.
Yeah.
J
But
yeah,
I'm
just
going
to
say,
as
a
consumer,
I've
seen
recommendation
to
use
the
same
version
for
all
the
hotel
packages,
so
I
feel
that,
like
even
the
customers
of
ours
would
now
probably
wait
until
everything
was
100
to
even
like
start
using
them.
I
don't
know
that's
kind
of
an
assumption.
I
don't
have
any
like
data
to
support
that,
but
that's
what
I
would
do
if
I
was
a
consumer.
D
What
I'm
talking
about
is
like
the
internal
packages
that
end
users
don't
necessarily
depend
on,
but
I
do
see
what
you
mean.
It's
it's
a
little
bit
more
confusing,
I
guess
with
the
semantic
inventions
again
as
an
example,
even
though
it's
not
a
good
candidate
end
users
do
depend
on
that
one.
So
I
guess
it
wouldn't
be
obvious.
J
D
Yeah
and
the
other
benefit
of
releasing
one
at
a
time
is
deciding
with
each
package.
You
just
you,
can
look
at
one
package
and
say:
is
this
package
stable
and
done
and
ready
to
be
released?
Yes
or
no?
And
then,
if
you
don't,
then
release
it
as
1.0,
it
can
be.
You
know
we
would
just
have
to
track
which
packages
have
been
sort
of
reviewed
as
ready
for
release.
I
suppose.
D
Yeah
yeah,
so
we
could,
I
guess,
on
the
read
me
of
each
package
or
something
like
that:
have
a
a
code
freeze
flag
that,
like
that
or
a
an
api
freeze
that,
like
the
the
the
external
interface
of
this
packet,
is
no
longer
changing
that
may
be
a
decent
workaround
and
then
once
they're
all
frozen.
We
would
then
be
ready
for
release.
D
Yeah,
I
I
completely
understand
that,
and
we
we've
had
issues
like
that
in
the
past,
with
the
api
and
the
sdk
and
the
instrumentations
versioning
being
really
confusing
for
end
users,
and
I
know
that
that
has
been
sort
of
a
sticking
point
in
the
past,
which
is
why
we
switched
everything
to
be
the
same
version
again
recently.
G
Of
daniel,
I'm
also
wondering,
if
you
released
say
like
the
core
package
as
1.0,
you
would
still
have
to
roll
out
a
release
of
the
other
ones.
To
now
depend
on
the
1.0
right.
Yes,.
G
So
from
like
a
bug
perspective,
it
probably
wouldn't
like
the
bugs
like,
if
you
had
two
bugs
that
scenario
you
were
mentioning
it
would
still,
it
would
still
be.
G
G
D
Then
it
would
give
us
sort
of
a
built-in
priority
order
only
only
if
it
had
gone
to
1.0
and
we
found
it
and
you
know
we're
able
to
fix.
You
know
something
and
maybe
the
core
package
that
we
have
to
fix
in
a
backwards
compatible
way.
But
in
the
tracing
package
that's
not
gone
yet.
Maybe
we
can
fix
it
in
a
way
that
breaks
the
interface
because
it
hasn't
gone
to
1.0.
Yet.
G
D
I
guess
we'll
move
on
to
the
next
question,
which
is
very
related.
Do
we
think
that
the
instrumentation
api
should
be
part
of
the
1.0
release?
So
this
would
be
the
instrumentation
package
itself.
D
D
On
the
other
hand,
it
only
depends
on
the
api
it's
not
tightly
coupled
to
the
sdk,
so
it
is
entirely
possible
to
release
the
tracing
sdk
without
having
the
instrumentation
go
to
1.0
and
everything
would
still
work
and
the
contribs
still
will
not
be
at
1.0.
So
I
don't
know
if
it
really
makes
sense
to
push
the
instrumentation
api
to
be
stable.
Yet.
D
I
had
initially
sort
of
assumed
that
it
would
be
part
of
the
release,
but
valentine
actually
this
morning
sort
of
reminded
me
that
there
is
no
real
requirement
for
it
to
be
he's.
Unfortunately,
not
at
the
meeting
today.
D
For
this
I
think
actually
amir,
I'm
sort
of
looking
for
your
input.
Since
you
maintain
a
lot
of
instrumentations
more
than
anyone
else.
I
think.
D
So
when,
when
we
go
to
1.0
for
tracing,
do
we
believe
that
the
instrumentation
api,
so
that
the
base
class
that
all
the
instrumentations
use
should
be
included
as
part
of
that
stable
release
or
not.
D
So
if
we
do
include
it
as
part
of
the
stable
release,
then
I
think
it
makes
it
easier
for
people
to
write
instrumentations,
knowing
that
the
api
that
they're
writing
against
won't
change
the
disadvantage,
I
guess
would
be-
I
don't
know
if
the
instrumentation
api
is
finished.
D
Ted
swore,
like
I
said
earlier,
is
still
working
on
an
instrumentation
working
group
and
they
may
come
up
with
a
different
solution
than
what
we
had
that
might
require
releasing
a
different
instrumentation
package
or
something
to
be
compatible
with
that
there's
also
at
least
one
issue.
Currently
that
is
requesting
a
change
in
the
instrumentation
api
around
the
configuration
types
and
things
like
that
once
it
goes
to
1.0
it'll,
be
much
harder
to
make
those
changes.
K
I
think
we
don't
need
to
wash
with
moving
to
1.0.
We
can
keep
it
the
way
it
is
now
until
we
feel
that
it's
stable
enough.
Okay,
that's
my
opinion,
but.
D
Yeah,
I
I
don't
expect
it
to
be
very
unstable.
I
don't
think
the
interface
will
be
changing.
All
that
often
anyways,
but
going
to
1.0
is
definitely
obviously
a
stronger
guarantee
than
than
me
just
saying.
I
feel
like
it
doesn't
change
that
often
yeah.
K
I'm
used
to
update
all
the
instrumentations
on
every
release
of
open
telemetry.
So
for
me
it
doesn't
really
matter,
but
I
see
the
point
in
keeping
it
on
zero
until
it's
stable,
okay,.
C
D
D
That
said,
I
don't
really
want
to
have
a
lot
of
version
churn
and,
as
vera
mentioned
earlier,
having
all
of
the
versions
on
the
same
major
version
across
the
board
is
definitely
more
obvious
for
users,
if
you
just
say,
if
you're
on
one.x
everything
should
work
together
is
much
more
obvious
than
saying
oh,
but
the
instrumentations
can
be
on
two
or
three
or
four.
C
I
I
totally
agree
with
that
point,
although,
like
I
don't,
I
don't
see
any
strong
reason
that
it
that
we
can
eventually
guarantee
that
right
like
there
might
be
some
other
forces
in
play.
That
might
force
us
to
actually
bump
the
major
versions
in
in
some
of
the
areas
of
open,
dormitory,
js,
eventually
anyways
right.
D
Yes,
and
so
that
the
instrumentation
major
versions,
I
expect
eventually
to
not
match
the
sdk
major
versions,
just
because
I
think
that
they
will
turn
over
more
quickly
and
the
sdk
I
expect,
will
turn
over
more
quickly
than
the
api,
so
it
will
likely
go
to
2.0
and
still
target
the
api,
1.0
or
1.x.
D
C
Okay,
cool
thanks
yeah
in
that
sense,
in
my
opinion
like
like
it
would
make
sense
to
get
everything
else,
1.0
actually
and
then
release
the
instrumentation
api
1.0,
but,
but
that's
only
because
of
the
you
know
of
the
reason
that
it
actually
makes
sense,
like
you
know
like
to
avoid
confusion
other
than
that
like.
Oh,
we
could
basically
release
1.0
for
instrumentation
api
today.
D
K
I
D
D
D
We
could
move
that
function
into
the
you
know
what
whatever
entry
point
package
we
right
now
we
have
a
couple
of
packages
that
are,
you
know,
possible
entry
points.
You
can
depend
just
on
the
node
package
or
the
web
package,
but
you
could
also
depend
on
the
node
sdk
package.
We
could
put
it
in
one
of
those
that
also,
I
guess,
is
a
good
point.
D
D
Okay,
so
for
now
I
guess
I
will
assume
that
the
instrumentation
api
will
not
be
a
part
of
the
tracing
sdk
release
unless
we
have
some
good
reason
that
it
should
be.
That
comes
up
later,
I'm
happy
waiting
for
it.
A
Yeah
we
we
discussed
this
last
week
a
little
bit
longer,
so
it's
again
around
the
examples,
I'm
not
sure
if
you
still
have
time
for
that,
so
it's
semi-related
to
to
the
other
things
we
just
discussed.
I
think
this
was
the
their
d
around
having
yeah
the
packages.
The
examples
move
closer
to
the
packages
and
I
think
then
the
discussion
went.
Let's
say
in
in
lots
of
directions
what
to
do
with
the
examples.
Where
should
they
live?
A
And
things
like
that,
so
I
just
wanted
to
to
bring
back
the
attention,
but
they
said-
maybe
maybe
it's
maybe
it's
better
to
to
move
this
discussion,
or
at
least
only
collect
a
few
few
ideas
and
thoughts
on
it.
D
Yeah,
I
obviously
missed
last
week.
I
don't
have
a
strong
opinion
here.
I
know
that
bart
had
an
opinion,
but
I'm
sure
that
you
talked
to
him
last
week
about
that.
So
I
don't
know
what
I
can
really
contribute
without
having
been
here
last
week.
A
D
Okay
is
so
I'm
not
caught
up
on
this
ticket
is
all
of
the
the
discussion
from
last
week.
Sort
of
this
looks
like
a
really
long
comment.
Is
that
sort
of
included
in
here.
D
Looks
like
no
do
you
know
if
the
discussion
on
the
ticket
is
up
to
date
from
what
you
talked
about
last
week,.
A
Or
mostly,
as
far
as
I
remember
so,
I
think
nico
also
added
a
little
bit
at
the
very
bottom.
A
I
yeah
I'm
also,
I
think,
the
the
challenge
with
that
is
like,
as
we
discussed
before,
with
the
other
things.
I
think
we
should
have
good
examples
and
easily
reusable
examples,
but
at
the
same
time,
it's
difficult
to
to
make
sure
that
they
are
not
yeah,
overwhelming
everybody's
spending
so
much
time
on
on
building
examples
and
making
sure
that
they
work
so
having
a
good
balance
between
yeah
having
them
and
maintaining
them.
C
D
Okay,
so
I
guess
what
I
would
suggest,
then,
is
whoever
is
currently
responsible
for
examples
which
I
guess
is
where
or
rono
as
the
creator
of
this
ticket.
If
somebody
could,
I
guess,
come
up
with
a
proposal
for
a
way
to
move
forward,
and
then
we
can,
we
can
either
take
a
vote
on
it
or
if,
if
people
seem
generally
happy
with
it,
we
can
move
forward
because
if
talking
forever
doesn't
doesn't
get
it
done,
we
need
to
eventually
make
a
decision
and
move
on.
Like
you
said,.
D
It
okay,
so
I
guess
we
can
continue
the
discussion
in
the
ticket,
but
if
somebody
has
a
concrete
proposal
for
this
is
what
we
should
do
to
move
forward,
then
I
would
appreciate
that.
D
We
then
have
three
prs
here.
I
guess
that
are
in
need
of
reviews
this
one
here
ready
to
merge.
C
D
So
this
one
I
was
going
to
merge
it
actually,
but
I
wanted
to.
I
was
hoping
to
talk
to
valentine,
to
find
out
why
the
initial
port
of
4317
was
picked
or
whether
that
was
just
a
mistake
to
begin
with,
because
I
didn't
want
to
merge
that
change.
But
I
looked
in
the
blame
and
it
looked
like
valentine
was
the
one
that
put
that
in
and
he
doesn't
seem
to
have
a
problem
with
this.
So
I
think
we're
probably
good
to
merge
this.
D
L
L
L
D
H
D
Well,
I
think
that's
just
it's
either
a
bug
in
the
collector
or
a
bug
in
the
specification
I
will
reach
out
to
the
collector
group
and,
if
needed,
I'll,
just
revert
that
pr.
D
Okay
yeah
so,
like
I
said,
please
add
prs
this
list
and
if
you
see
prs
on
the
list,
please
review.
D
Them
all
right,
thank
you,
everybody
for
your
time,
and
I
will
talk
to
you
next
week.