►
From YouTube: 2022-12-01 meeting
Description
Instrumentation: Messaging
A
C
A
B
A
B
We
are
on
the
very
verge
of
a
release.
There
are
three
issues
that
are
kind
of
outstanding
for
the
112
and
the
3-4
release.
I,
don't
know
if
that's
the
right
number
I
feel
like
that's
wrong,
but
but
anyways
the
semcom
packages.
I
know
Tyler
has
added
the
version
1.13
and
I
figure.
If
we
get
1.13
and
the
1.14
should
follow
pretty
soon
after
but
needs
eyeballs
needs
reviews.
If
you
have
time,
please
go
and
check
it
out.
B
A
B
B
A
B
A
A
If
you
look
at
what's
already
been
merged
for
this
release,
it's
all
really
just
bug
fixes.
So
I
think
this
would
be
released.
As
you
know,
One
Eleven,
one
if
we
didn't
include
the
semconf
stuff,
because
that's
really
like
the
additional
things
that
being
said
like
this,
has
been
open
since
September.
You
know
when
when
113
was
released,
yeah
I
think
115
might
even
be
out
right
now,
oh
boy,
that's
we've.
A
There's
another
one,
even
that
we
need
to
do
so,
I'm
fine,
with
pushing
this
out.
I
I
would
like
to
get
this
in.
So
one
of
the
main
things
that
was
really
a
problem
was
in
113,
there
was
a
big
refactor
to
the
network
in
HTTP
semantic
conventions
in
in
how
they're
defined
to
be
including
addresses
and
other
sort
of
attributes
associated
with
the
network
and
our
existing
functionality
around.
That
was,
it
was
it's
definitely
Legacy.
A
A
Based
on
you
know,
if
you
have
a
request
coming
from
a
server
request
coming
from
a
client
or
something
like
that,
so
I
I
try
to
do
that.
One
of
the
things
that
was
kind
of
pointed
out
is
that
like
well
maybe
I'll,
step
back
to
one
of
the
things
is
also
in
the
structuring.
So,
instead
of
putting
everything
in
this
semcom
package,
it
was
also
there's
these
sub
packages,
HTTP,
confident,
netconf,
somewhere,
yeah
and
so
like
it
was
structured
in
a
little
bit
different
way.
A
A
A
I
think
one
of
the
the
nice
things
about
our
package,
structuring
in
semconf
is
that,
like
each
new
version
is
its
own
package,
so
we
can
kind
of
change
it.
However,
we
need
to
backwards
compatibility,
isn't
I
mean
we
are
remaining
backwards
compatible.
You
know,
because
we're
not
changing
the
existing
package
API.
A
So
the
new
API
for
the
new
package
is
how
that's
defined,
which
is
kind
of
nice,
but
it
also
you
know,
is
needs
to
be
kind
of
put
into
consideration
for
people
that
are
using
it
like
if
they
just
want
to
do
an
update.
They'd,
rather
probably
not
have
to
do
a
bunch
of
function.
Changes
and
just
do
this
update
so
I
think
Trying
to
minimize
that
that
amount
of
churn
is
ideal.
A
That
being
said,
I
do
think
that
this
is
a
positive
step
in
that
direction,
and
so
I
think
that
this
is
a
worthy
version
of
it.
The
net
conf
was
pointed
out
that
it
really
only
has
one
function
in
it.
That's
exported,
and
that's
transport
I
had
done
that
somewhat
intentionally.
I
had
a
lot
of
other
ideas
around
what
it
could
contain,
and
Aaron
pointed
out
so
I've
been
ever
since
I
saw
this
comment
and
working
to
try
to
add
them.
A
That
accepts
like
an
address
and
I
think
I've
defined
it
as
like
an
address
and
a
connection
or
an
address
and
a
listener,
and
then
it
will
annotate
all
of
the
attributes
that
you
need
for
those
which
is
I,
think
it
could
be
useful
in
the
grpc
library.
I
think
that
that's
somewhere,
where
we
have
a
client
and
we
have
an
address,
and
so
it
could,
you
know,
conform
with
all
of
the
specifications.
A
So
I
was
going
to
add
them
I'm
in
the
middle
of
writing
a
bunch
of
tests
for
it
I
have
it
all
together.
So
it
was
going
to
be
added
in
question.
A
little
bit
but
yeah
I
mean
the
original
intent
was
just
to
like.
Have
you
know,
compatibility
with
form
or
function,
and
so
transport
was
somewhat
of
its
own,
but
it
was
also
in
this,
like
distinct
net
package,
not
HTTP,
that's
why
I
put
it
in
a
different
one,
but
yeah,
so
that's
outstanding.
A
So
there's
still
a
little
bit
of
work
to
do
here
and
I
think
this
is
kind
of
like
coming
back
to
that
high
level.
Discussion
of
like
you
know,
this
is
kind
of
blocking
that
V12
Milestone
or
v112
Milestone.
So
I'd
like
for
this
to
be
included,
given
how
late
we
are
to
the
game
on
this
one.
But
I
could
also
understand
if
people
wanted
to
spend
some
time
reviewing
this
and
think
through
this
one
to
pull
it
out
and
instead
of
doing
a
v112,
we
do
a
v11.1
or
something
like
that
release.
A
A
A
So
I'm,
okay
with
it
I,
also
think,
like
kind
of
what
I
said
is
like
if
we
find
out
that
this
was
just
like
a
horrible
idea,
we
can
always
in
the
next
semcon
package,
make
a
change.
You
know
if
it
really
is
motivated,
but
I
do
think
that
that's
I
don't
know.
I
I,
like
the
API,
a
little
better,
so
yeah,
okay,
well,
I!
Think
if
that's
the
case,
so
maybe
then
also
to
kind
of
frame.
A
But
I
don't
see
why
this
couldn't
get
merged
today,
if
I
can
get
a
suggestion
and
then
maybe
able
to
just
have
it
something
committed
and
then
I
think
once
this
gets
merged.
I
think
that
we
could
open
an
issue
to
try
to
to
get
the
release
out.
I
was
hoping
to
get
the
release
out
to
this
week,
but
it
was
been
a
busy
week,
so
it
didn't
happen,
but
yeah
I
would
like
to
at
least
get
it
out
early
next
week.
A
B
A
A
So
also
just
to
kind
of
point
it
out
like
if
we
do
include
the
semantic
convention
stuff,
the
release
will
be
harder
because
contrib's
gonna
need
to
get
updated
and
the
HTTP
HTTP
Trace
instrumentation,
as
well
as
grbc,
probably
as
well
need
to
be
updated
to
use
the
new
functionality
of
the
semantic
convention
packages.
So
that
would
I
would
imagine
take
a
day
or
so
in
itself.
B
C
A
A
The
thing
that
I've
heard
feedback
from
the
community
on
as
well
as
I'm
sure
other
people
is
the
Prometheus
exporter
stuff,
is
really
needed.
The
semantic
conventions-
v113
I,
don't
know
if
it's
as
needed,
I
feel
guilty,
because
it's
really
far
behind
but
I'm
kind
of
leaning
towards
just
saying
like
we
pulled
that
out
and
then
maybe
in
the
next
release
cycle,
try
to
work
on
that
I
think
more
as
a
priority.
E
A
A
A
This
PR
is
updating
the
code
orders
file
to
actually
do
that
assignment,
So
the
plan
just
for
everyone.
That's
on
the
call,
is
anything
that
doesn't
have
well
I
guess
right
now
we
just
need
an
owner.
These
also
be
assigned
a
main
painter,
but
I
think
that's
between
Aaron
Anthony,
myself
will
kind
of
think
dish
that
out.
If
it
doesn't
happen,
organically,
that's
happening
here.
A
So
the
idea
is
anything
that
doesn't
actually
have
an
owner
is
going
to
become
deprecated
and,
that's
not
to
say
it
can't
be
undeprecated
in
the
future.
If
somebody
does
want
to
take
on
the
ownership,
but
then
after
that,
module
is
deprecated,
we'll
remove
it
from
the
repository
with
the
purpose
that
it
needs
to
be
I,
think
maintained
and
if
it's
doesn't
have
an
owner,
it's
not
being
maintained.
So
we
wanted
to
to
remove
that.
I
think
that
this
follows
in
suit
with
the
collector
contrib
policy.
A
A
Obviously,
there's
going
to
be
some
I
think
Auto
tagging
that
needs
to
be
done
in
Auto,
I
think
everyone's
going
to
get
the
reviews
that
are
needed
appropriately,
but
like
there's
still
some
I,
think
policy
and
and
sort
of
functional
niceness
that
we
could
add
to
the
repository.
But
right
now
this
is
kind
of
the
starting
point,
and
once
we
have,
this
I
think
we're
gonna
just
move
on
next
steps
as
being
deprecated.
A
A
Sig
meeting
is
in
two
weeks,
I
guess
a
week
and
a
half
at
this
point
so
I
wanted
to
make
sure
that,
like
we
have
a
full
cycle
to
talk
about
here
and
then
go
back
and
talk
about
it
with
them
and
to
make
sure
that,
like
that's
understood
and
that
I
think
from
there
we'll
merge
that
and
start
your
deprecation
process,
so
yeah
any
feedback
on
that.
Others
want
to
contribute
to.
D
D
Just
just
on
the
probability
sampler
and
to
throw
out
a
name
I
know:
Josh
probably
had
some
interest
in
that
right,
but
the
other
thing
is
maybe
the
is
doesn't
have
to
be
just
a
single
person.
There
right,
you
can
also
I
presume,
say
something
like
open,
Telemetry,
sampling,
SQL
or
something
like
that.
If
there
are
people
who
or
do
you
want
it
to
be
an
individual
person
there
well.
B
A
B
There
should
be
people
whether
or
not
it's
like
an
additional
to
that.
There's
also
the
other
people.
Remember
that
this
this
I,
don't
believe,
gives
you
any
additional
right
capabilities.
This
is
just
who,
who
do
we
need
to
go
talk
to
when
there
is
a
PR
like
who
do,
users
get
should
go
to
when
there
is
a
PR
and
additionally,
who
gets
tagged
in
the
PRS
so
having
a
person
as
a
point
of
contact
or
multiple
people
like
that?
That
is
ideal.
B
C
I
think,
though,
for
something
like
the
Z
pages
extension,
which
is
you
know,
needed
by
The,
Collector,
that
it
would
be
reasonable
to
have
the
collector
maintainers
be
the
owners
of
that
as
a
whole.
There
will
always
be
Collective,
maintainers,
I,
think
and
I.
Don't
know
that
we
should
be
wanting
to
keep
up
to
date
with
changes
in
that
group
membership
and
rather
to
just
specify
the
group,
but
I
also
want
them
to
accept
that
responsibility.
B
A
A
E
C
A
Yeah,
that's
a
little
scary,
but
yeah
yeah,
okay,
okay,
yeah,
I,
I,
think
I
think
especially
Z
pages.
There
may
be
a
reason
to
just
say
you
know
a
strong
reason
to
just
say
that
the
maintainers
but
I
think
also
for
the
instrumentation
like
I,
would
be
a
little
hesitant.
If
somebody
came
along
and
said,
like
you
know,
company
XYZ
wants
to
own
this.
So
just
put
our
group
here
because
then
there's
really
nobody.
A
You
know
that
company
that
you
are
I
think
directly
in
line
with
you
know,
one
of
the
other
things
is
I
know
and
The
Collector
contribute
like
once.
Somebody
left
that,
like
the
ownership
like
they
took
their
name
off
as
a
way
to
signify
that
nobody's
there
anymore
and
I.
Think
that
that's
more
of
a
positive
signal
to
also
saying
like
hey.
This
is
in
Jeopardy
of
being
deprecated.
If
there's
going
to
be
no
owner
or
something
like
that,
so.
A
But
yeah
I
think
that
if
it's
an
internal
group
in
the
maybe
even
say
like
an
internal
maintainer
group
in
hotel
I
think
that
that's
that's
a
pretty
safe
bet
at
that
point,
to
add
them
as
an
owner
Anthony.
Is
there
a
policy
document
in
the
contrib
collector
contrib
that
we
could
copy,
or
should
we
just
start
generating
one.
A
A
Ownership
of
something
as
well
I
think
that's
also
true,
because
if
I
remember
correctly,
I'd
heard
that
like,
if
you
aren't
responsive
within
a
certain
amount
of
time,
then
you
also
are
yeah
yeah
Calhoun
can't
exactly
Okay
cool,
so
timeline
on.
That
is
we
need
we
can
have.
We
do
need
an
issue
I
think
or
maybe
that
initial
to
find
ownership
model
for
packages
that
live
in
this
repository
could
include
an
action
item
to
include
a
policy
PR
as
well.
I
think
that's!
That's
fair!
C
Bit
further
up
in,
there
is
also
a
section
not
adding
new
components
that
has
discussion
of
you
know
the
need
to
obtain
a
sponsor
someone
from
within
the
group
who
is
also
willing
to
become
a
code
owner
and
the
need
for
it.
You
know
if
it's
a
vendor
component,
someone
from
that
vendor
needs
to
be
one
of
the
sign
up
to
be
one
of
the
code
owners.
A
A
C
B
B
C
A
A
It's
worth
giving
it
to
read
I'm,
actually
pretty
excited
to
read
about
this
awesome.
Okay,
well,
I!
Think
with
that
we
could
probably
end
it
early,
get
a
half
hour
back
for
everyone,
so
yeah.
If
you
have
something
else,
you
want
to
talk
about
definitely
in
slack
or
via
issues.
Otherwise
we
should
show
we
should
still
be
meeting
next
week
right,
like
that's
yeah,
this
release,
okay,
so
yeah
I,
guess
we'll
see
you
all
next
week
at
the
same
place
same
time,
see.