►
From YouTube: 2021-06-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
C
All
right,
903,
let's
get
rolling
so
we'll,
go
through
the
weekly
stick
check-in
and
then
we'll
get
down
to
topics.
Do
we
have
anyone
from
the
specification
city
who
wants
to
give
an
update?
I
think
I
see
bogdan
on
the
call.
C
Fair
enough
latest
quickly,
it's
hard
to
see
when
you're
presenting
to
carlos,
yet
don't
think
so.
E
F
Yeah,
it
looks,
it
looks
like
1.4
is
ready
and
carlos
can
decide
if
he
wants
to
take
one
non-blocking
pr
or
not,
but
it's
ready
to
be
released.
C
Okay,
cool
any
updates
on
the
metric
specification
and
metrics
focus
work
streams.
F
C
That's
great
thanks,
riley
any
updates
on
logs.
E
For
logs
we
decided
to
declare
the
otlp
logs
and
and
data
model
beta,
the
pr's
are
open.
I
will
merge
them
after
1.4
specification,
reduce.
B
Just
fyi
I
haven't
been
able
to
make
the
logs
meeting
because
it's
just
a
conflicting
time,
but
I've
been
getting
more
and
more
inbound
requests
around
log
appenders,
going
kind
of
both
directions,
stuff
that
attaches
trace
information
to
log
output
and
stuff
that
takes
existing
log
api
stuff
and
turns
it
into
trace.
Events.
B
E
There
there
were
a
couple
contributors
who
were
not
regular
of
hotel
contributors
who
expressed
interest
in
doing
something
for
java,
and
I
believe
also
python
seek
with
the
regular
maintainers
intended
to
do
something
about
blocks,
and
maybe
so
maybe
they
can
give
an
update
on
that
now
I
wouldn't
say
there
is
any
other
activity
happening.
So
perhaps
I'm
guessing
python
is
probably
the
most
advanced
at
this
point,
hopefully,
but
the
the
the
spec
of
how
we
want
it
to
happen.
B
E
F
F
E
C
Okay,
php,
I
think
it's
bob.
I
assume
you
added
this,
so
0.02
has
been
released
and
we
still
need
more
contributors.
C
C
C
Python
1.3
was
released
last
week,
included
various
bug,
fixes
and
features
they're
prototyping,
the
metrics
sdk
and
prototyping.
The
logging
sdk
excellent
uh.net.
No
major
updates
since
last
update
getting
contributions
for
more
instrumentation,
always
excellent,
also
relatively
quiet
in
the
main
repo
with
metrics
sdk
work
going
on.
I
guess,
given
the
state
of
pretty
advanced
data.net.
That
makes
a
lot
of
sense.
B
Could
I
ask
a
question
there
there's
net
and
there's
net
auto
instrumentation,
what's
the
status
on
the
relationship
between
those
two.
H
So
far
like
it's
working
as
like
independent,
I
don't
think
the
auto
instrumentation
is
yet
using
the
sdk
from
the
main
ripple,
but
I
was
told
that
they
are
working
on
a
prototype
to
incorporate
the
official
sdk
from
this
repo,
but
that
I
said
I
don't
have
any
more
knowledge
about
that.
Like
I
don't
see
anyone
from
the
auto
instrumentation
in
this
meeting
as
well.
H
Okay,
yeah-
I
was
wondering
like
if
there
is
any
specific
question
which
needs
answered
then
I
can
like
try
to
find
answers
and
report
back
in
the
next
week.
B
H
Okay,
got
it
yeah
yeah,
but
the
last
day
might
said
they
like,
due
to
time
constraints.
They
were
planning
to
use
whatever
existing
mechanism,
the
data
contributed.
Instrumentation
was
not
directly
taking
a
dependency
on
the
actual
sdk
being
shipped
from
the
main
repo,
but
somewhat
parallelly.
There
is
some
effort
going
on
to
try
prototype
switch
over
to
the
official
one.
That's
the
last
update,
I
heard
yeah
you
can
like
definitely
sing
with
follow
over.
H
Sometimes
people
from
the
auto
instrumentation
join
the
segmenting
for
the
dotnet
as
well.
So
we
can
definitely
ask
like
see
if
there
is
any
progress
on
that
effort,
so
that
eventually
we
can
be
like
like
using
the
same
sdk
as
supposed
to
be
like
two
distinct
efforts.
C
Perfect,
all
right
going
back
up,
go
working
towards
rc
release
candidates.
We
have
one
to
do
down
from
two
five
in
progress
and
300
done.
We'll
include
the
semantic
convention,
schemas
great
work,
c,
plus
plus
1.0
rc,
one
release,
hey
that's
a
big
milestone
and
we've
got
the
pull
request
linked
here.
G
Yeah
so
I
mean
just
just
summarize-
I
mean
this
was
done.
Last
friday,
it
was
discussed
in
the
last
community
meeting.
I
think
we
went
through
the
current
status
of
the
milestone
of
the
release
candidate
milestone
and
we
all
agreed
that
we
are
in
a
good
state,
after
going
through
the
sufficient
alpha,
like
release
cycles,
that
we
should
be
able
to
first
release
candidates.
So
yeah.
C
All
right
moving
on
to
swift,
we
have.
F
C
C
All
right,
I
specified
the
company
because,
of
course,
all
of
our
contributions
are
on
github.
Swift,
maintenance
release,
1.0.1
planning
to
do
monthly
maintenance
releases
revisiting
the
mobile
carrier.
Semantic
convention
pull
request;
okay,
any
updates
from
the
collector.
I
think
it's
tigran
you're
speaking
a
minute
ago.
E
Yeah
I've
been
actually
working
on
schemas
for
go,
didn't
work
on
collector
at
all.
I
don't
know
if
pogba
will
be
because
it
was
also
out
for
them.
Do
you
have
anything
any
updates
anything
here.
D
C
F
F
C
F
B
There
is
a
rust
sig
meeting
tomorrow
afternoon.
Pacific
time
doesn't
look
like
they
keep
their
meeting
notes
up
to
date.
I
don't
know.
A
G
So
we
are
yes
and
now
so
we
are
not
taking
by
default
dependency.
On
epsilon
I
mean
the
grpc
is
dependent
on
our
cell,
so
indirectly
we
are
definitely
depending
on
that,
but
our
api
and
sdk
are
not
directly
dependent
on
that.
We
do
have
compile
time
flag
to
use
epsil
stl
if
somebody
want
to
definitely
use
it,
but
not
as
a
default
dependency.
I.
D
E
F
F
B
In
java
right
john
well,
I
mean
I
think
it
will
really
work
a
lot
better
in
1.3
when
that
gets
released.
So
they
I
mean
the
general
question
is
using
auto
configuration
or
sorry
our
configuration,
auto
instrumentation
with
sdk
customizations
and
that's
fairly
non-trivial
in
java.
B
But
nikita
has
done
a
tremendous
amount
of
work
in
the
past
month
on
providing
a
new
extension
mechanism
where
users
can
drop
a
jar
in
to
a
specific
extension
directory
to
enable
sdk
custom
sdk
configuration,
but
it
definitely
was
not
something
that
was
simple,
previous,
so
previous
to
1.3,
which
hasn't
been
released.
Yet
essentially,
anyone
who
wanted
to
do
this
would
have
to
bundle
up
and
build
their
own
version
of
the
of
the
java
agent
to
make
it
work.
F
B
I
think
it's
like
two
separate
two
separate
things.
The
the
main
deal
with
auto
instrumentation
is:
it
needs
to
work
with
the
api
and
I
think,
in
the
case
of
net
there's
also
like
a
split
between
instrumentation
that
works
with
the
core.net
stuff
versus
instrumentation
that
works
with
the
auto
instrumentation
library.
B
That's
actually
totally
there
in
the
java
world
as
well.
Well,
in
the
sense
that
I
don't
think
people
are
using
like
in
the
java
world,
everyone's
basically
exclusively
using
the
agent
instrumentation
right-
that's
no!
I
would
not
say
that
is
true.
Okay,
that
is
definitely
not
true.
There's
a
whole
bunch
of
what
what
the
instrumentation
group
calls
library
instrumentation
that
is
available
for
you,
like
basically
plugging
kind
of
like
the
way
you
would
think
about
wiring
up
interceptors
and
things
like
that
in
a
in
a
non
bytecode,
instrumentation
environment.
B
Okay,
both
by
code
and
non-byte
code.
I
guess
that's
what
I'm
saying
and
the
instrumentation
group
is
really
is
trying
very
hard
to
make.
The
bytecode
instrumentation
use
the
non-byte
code,
library
instrumentation
as
much
as
possible.
Awesome.
There
are
cases
where
it's
not
possible,
but
as
much
as
they
can.
B
I
D
Now,
but
this
is
important
only
for
auto
instrumentation,
because
for
manual
instrumentation
or
when
you
use
the
instrumentation
libraries,
you
have
full
control
of
how
you
initialize
the
processors
and
stuff.
G
F
D
B
Yeah,
there's
not
really
like
byte
code
manipulation
stuff
going
on
there.
The
way
those
loading
mechanisms
work,
I
think,
are
a
lot
simpler.
So
it's
there's
less
of
a
there.
Isn't
so
much
like
an
auto
instrumentation
agent
thing
in
those
environments
that
needs
to
work
very
differently
than
the
core
sdk,
it's
more
like
hooking
into
the
import
paths
of
things
and
automatically
loading
libraries
for
people.
B
Doing
there,
but
the
go
community
thinks
that
cameras
steal
your
soul
and,
like
technology's
the
devil.
So
I
don't.
B
I
did
see
what
they
were
doing
it
looked.
It
looked
like
they
were
heavily.
You
had
to
use
like
a
custom,
run
time
and
there's
a
lot
of
c
extension.
B
B
J
Yeah
sure,
thank
you
so
much
this
is
not.
My
actual
issue
probably
is
familiar
with
this
one.
J
This
could
be
like
instrumentation,
instrumental
library,
specific
and,
and
then
it
turns
out
that,
even
though
this
is
not
something
that
probably
specification
needs
to
do,
this
is
something
that
has
been
done
in
a
few
libraries
for
python.net,
and
this
is
something
we
also
have
in
open
tracing.
So
I'm
wondering,
as
a
general
question,
what
about
providing
a
general?
You
know,
guidelines
or
common
patterns
suggested
for
for
instrumentation.
J
I
know
that
there
is
an
instrumentation,
see
or
kind
of
see,
so
maybe
they
are
the
ones
that
could
focus
on
that.
B
We're
gonna
try
to
get
people
together.
It's
it's.
It's
taken
some
time
to
get
commitments
from
groups
to
to
put
people
on
focusing
on
instrumentation
and
guidelines,
so
that's
been
slow
going,
but
that
will
hopefully
get
kicked
off,
maybe
as
soon
as
week
after
next
it
does
look
like.
I
don't
want
to
like
speak
for
other
groups,
but
but
I
have
been
getting
active
commitments.
It
just
hasn't
started.
B
Yet
if
there
are
people
from
splunk
and
other
core
contributors
who
are
interested
in
working
on
instrumentation
and
semantic
convention
guidelines,
definitely
ping
me.
Let
me
know.