►
From YouTube: 2023-01-03 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
B
Oh
good
question:
I,
don't
know
yeah
I,
think
I,
think
I.
Think
the
I
don't
remember
the
details,
but
I
think
that
they
couldn't
disclose
the
holidays.
They
had.
B
C
D
B
People
I
guess
we
can
start
at.
The
first
point
is
just
like
for
your
information.
Basically,
we
will
be
doing
the
motor
release
and
I
will
prepare
a
PR.
Please
review
that,
especially
if
you
were
not
around
during
part
of
December,
because
we
were
merging
a
few
PRS,
so
probably
not
not
too
many,
but
a
few.
So
please
review
that.
So
you
don't
you
don't
get
surprised
about
that
one!
B
B
A
Sure
thing
so,
as
you
all
know,
I'm
trying
to
get
us
a
little
more
organized
in
the
new
year.
As
far
as
the
larger
specification
projects,
we
have
a
number
of
spec
working
groups
that
we
want
to
get
through
a
number
that
are
already
in
flight
and
we've
got
a
fairly
big
backlog
of
oteps
and
we've
gotten
some
feedback
about
how
we
could
maybe
work
on
this
better.
A
So
if
I
just
share
my
screen,
real
quick,
so
I
put
together
a
very
brief
document
that
just
kind
of
goes
over
at
a
high
level.
A
What
I
would
like
to
see
us
start
focusing
on
this
year
as
far
as
process
goes
and
I
would
love
feedback
on
it
just
to
go
over
it
with
you
all,
since
we've
got
plenty
of
time.
It
looks
like
in
this
meeting.
A
Let's
start
with
the
feedback
that
we've
received
the
number
one
issue
that
I've
noticed
from
working
with
a
lot
of
these
working
groups
and
talking
to
people
in
the
spec
Community
is
we're
slow
right,
there's,
often
a
feeling
that
it's
very
slow
to
get
things
through
the
spec
process.
Now
a
lot
of
us
for
good
reason,
which
is
we
want
a
lot
of
input
from
people,
and
we
want
to
give
people
time
to
be
able
to
provide
that
input.
A
But
it's
also
happening
because
we
tend
to
be
spread
very
thin.
We
have
lots
and
lots
of
open
issues.
We've
got
a
number
of
working
groups
and
it's
not
clear
at
any
given
moment
which
of
these
issues
or
projects
we're
we're
trying
to
focus
on
as
a
group,
and
since
you
need
a
lot
of
approvers
to
get
something
over
the
Finish
Line.
To
prevent
conversations
from
like
that.
Just
sort
of
running
a
ground
of
that
kind
of
contact.
A
A
We
need
to
find
a
way
to
just
be
a
little
more
focused
in
our
efforts
and
I
believe
by
doing
that,
the
feeling
of
speed
will
increase
so
by
decreasing
the
amount
of
contact.
Switching
we're
doing.
We
can
also
decrease
the
latency
when
it
comes
to
addressing
these
issues
and
kind
of
related
note
when
issues
become
difficult
to
resolve,
issues
tend
to
stall
out.
A
So
this
usually
comes
in
two
forms.
One
is
we're
trying
to
integrate
this
into
open
Telemetry,
but
it's
not
clear
how
to
do
it
and
it
might
be
something
that
goes
against
the
grain
of
some
rule
that
we've
already
made
for
me,
like
a
classic
example
of
this,
would
be
adding
ephemeral
resources.
So
when
we
started
the
client
working
group
turned
out,
we
had
some
really
important
things
like
session
ID
and
time
zone
that
are
metadata.
A
We
want
associated
with
all
the
data
AKA
resources,
but
resources
are
immutable,
and
these
are
values
that
actually
change
over
the
lifespan
of
these
long-lived
processes,
so
that
turned
out
to
just
be
a
tricky
Wicket
of
how
do
we
actually
deal
with
that?
We
said
resources
are
mutable.
We
have
these
things
that
are
basically
resources,
but
they're
not
immutable.
What
do
we
want
to
do
there
and.
A
A
The
other
reason
things
stall
out
is
sometimes
we
don't
have
the
appropriate
expertise
on
the
spec
side.
I
think
this
is
becoming
more
and
more
true,
as
we
move
forward
and
the
domain
of
the
issues
we're
trying
to
resolve
are
moving
farther
and
farther
away
from
distributed
tracing
like
core
distributed
Tracer
stuff,
which
is
kind
of
like
the
core
of
the
spec
Community.
A
So
we
saw
a
bit
of
this
around
metrics,
we
kind
of
had
to
expand
to
get
more
metrics
expertise
in
same
thing
with
logs
same
thing,
it's
really
going
to
happen
with
profiling,
and
we
also
noticed
this
with
trying
to
stabilize
the
semantic
conventions,
because
that
requires
expertise
in
these
various
tools
and
projects
that
aren't
open,
Telemetry
like
cockroachdb,
or
something
like
that.
So
because
we
don't
always
feel
like.
We
have
the
appropriate
expertise
to
to
review
some
of
these
proposals.
A
A
Moving
on
to
to
the
working
group,
specifically
not
just
the
oteps
in
the
background
working
groups,
can
get
very
deep
into
their
work
and
if
they
aren't
working
groups
that
were
founded
or
being
run
by
like
PC
members,
then
it
becomes
difficult
once
that
group
has
actually
developed
a
lot
of
State
in
their
head
and
developed
a
set
of
oteps
to
resolve
whatever
issue
that
working
group
was
formed
to
resolve
when
they
then
go
to
The
Wider
community.
A
It's
a
bit
of
a
rough
road,
because
nobody,
if
there
weren't
enough
people
who
were
part
of
this
core
respect
community
in
that
working
group,
then
it
feels
sort
of
like
that.
Working
group
then
has
to
totally
rehash
everything
all
over
again
when
they
go
to
the
wider
group,
and
that
can
be
a
little
like
socially
difficult
if
the
working
group
isn't
really
like
personally
tied
in
to
like
the
core
respect
Community.
A
So
that's
more
just
like
a
human's
having
conversations
thing
in
the
way
like
humans
transmit
information,
and
it
tends
to
make
the
the
spec
process
go
slower
because
it,
the
groups
tend
to
have
to
kind
of
like
do
the
whole
working
group
and
then
sort
of
do
the
whole
working
group
again
in
public.
Obviously,
there
is,
when
you
get
public
feedback,
there's
going
to
be
a
need
to
reiterate
thing
and
provide
more
context
and
justification
than
maybe
did.
But
it's
still
a
thing.
A
And
last
but
not
least,
we
don't
have
a
road
map
for
what
work
we're
trying
to
focus
on
next
and
where
I've
noticed
that
this
makes
things
a
little
difficult
is
when
we
want
to
get
outside,
subject
matter,
expertise
to
come
in
and
participate
for
most
organizations,
they
have
orderly
planning
Cycles,
and
so
they
need
to
know
fairly
well
in
advance
that
we
are
going
to
be
working
on
something
like
the
Cassandra
semantic
conventions
or
something
like
that.
A
If
they
know
far
enough
in
advance
that
that's
on
our
roadmap,
then,
through
their
regular
planning
cycle,
they
can
allocate
some
time
to
work
on
it.
But
most
organizations
can't
really
turn
on
a
dime,
so
without
having
that
clear
road
map,
it
becomes
a
little
bit
difficult
for
us
as
a
project
to
integrate,
with
these
planning
cycles
that
our
member
organizations
have,
which
makes
it
a
little
bit
more
difficult
to
get
participation
in
an
organized
manner
that
allows
people
to
use
a
work
time
to
participate
on
this
stuff.
A
So
those
are
kind
of
like
the
high
level
issues
that
I've
identified
in
2022
I.
Don't
think,
we've
been
doing
a
terrible
job
to
be
super
clear.
These
are
just
things
that
I
think
we
could
improve
going
forwards
and
maybe
I
can
just
stop
there.
Real
quick,
because
I've
been
talking
a
lot
and
gather
some
feedback
from
people
on
the
call.
What
do
you.
C
A
Feel
as
far
as
that
being
like
spec
backlog
issues,
does
that
feel
right
to
you?
Is
there
stuff
missing
from
this
list.
A
Any
part
of
the
process,
anyone
on
this
call
would
personally
feel
like
they
like
to
see
improved
from
a
project
management
standpoint.
A
Cool
well,
if
you
do
have
feedback
on
this
subject,
feel
free
to
to
add
it
as
a
comment
in
the
doc
okay.
So
how
can
we
actually
resolve
these
issues
in
a
way
that
doesn't
involve
just
like
more
meetings
and
more
time
and
More
Everything?
How
can
we
just
organize
ourselves
a
little
more
efficiently
and
I've
come
up
with
three
pieces
that
I
think
would
be
the
pieces
that
we
need
to
just
kind
of
smooth
out
the
way,
we're
processing
these
larger
oteps
and
issues.
A
One
is
having
a
strategic
roadmap
that
we're
actually
Gathering
from
the
community
to
make
sure
that
what
we're
focusing
on
in
our
spec
work
lines
up
with
what
the
community
is
saying,
is
important
to
this
Morgan
McLean
has
been
doing
a
good
job
of
holding
this
down
taking
polls
at
various
Community
meetups
And,
discussing
with
the
maintainers
he's
put
together
a
roadmap
proposal
which
you
can
find
here
so
I
would
encourage
everyone
to
have
a
look
at
this
document,
see
if
it
lines
up
with
what
you
think
the
priorities
should
be
and
make
a
comment.
A
A
We
have
a
rudimentary
project
management
idea
that
we've
added
to
the
spec
around
using
GitHub
issue
boards
to
track
these
projects
at
a
high
level.
We
haven't
really
flexed
this
very
much
yet.
We've
had
a
couple
of
projects
create
a
project
issue,
but
if
you
have
a
look
at
this
document,
it
kind
of
goes
over
the
life
cycle
and
the
needed
information
that
we
need
to
gather
from
a
project
to
understand
kind
of
what
state
it's
in
and
what
we
should
be
doing
with
it.
A
A
So
you
fill
this
out
and
this
is
for
dealing
with
oteps
or
projects
that
need
an
actual
working
group
of
people
to
hash
out
Beyond,
just
hashing
out
in
the
the
Otep
PR
or
the
spec
PR.
A
So
you
can
create
one
of
these
here
and
then
in
our
project
level,
project
boards.
We
have
a
board
here.
We've
got
a
couple
of
projects
thrown
on
it.
We
haven't
really
started
using
it,
but
basically
we
would
like
to
get
all
the
work.
We're
currently
doing,
try
to
get
it
listed
out
here
in
whatever
state
it's
in
and
then
start
to
use.
Something
like
this
to
organize
which
of
these
projects
as
a
community
we're
trying
to
pay
attention
to-
and
this
is
been
made
with,
like
larger.
E
A
Group
projects
in
mind,
but
I
think
there
needs
to
be
a
way
to
for
projects
that
are
essentially
a
one-off
Otep,
like
the
Apache
Aero
polymer
coding
stuff.
E
A
Of
that
work
to
focus
on
potentially
with
putting
things
like
milestones
and
deadlines
for
public
commentary,
and
things
like
that,
just
so
as
a
community
we're
just
a
little
more
focused
on
which
particular
projects
we're
working
on
at
any
given
moment.
A
A
Well,
we,
this
is
our
current
backlog
of
stuff,
we'll
try
to
get
to
your
project
once
we're
done
with
with
these
projects
and
I
think
that
Clarity,
even
if
for
some
projects,
it
doesn't
mean
they
get
immediate
feedback
by
having
just
the
clarity
of
like
oh
okay,
you're
working
on
different
stuff,
we'll
kind
of
help
people
understand
what's
going
on,
so
it
won't
feel
as
slow.
A
Last
but
not
least,
working
group
participation
to
address
this
kind
of
human
information
transfer
issue,
I
think
going
forwards.
We
shouldn't
have
working
groups,
get
kicked
off
without
having
at
least
two
TC
members
or
spec
approvers
or
other
core
people
from
the
community
participating
in
those
working
groups,
so
that
when
those
working
groups
move
to
making
their
proposals
in
public
outside
of
the
working
group
to
get
them
actually
added
to
the
spec.
Those
approvals
have
already
gotten
attention
or
sorry.
A
Those
projects
have
already
gotten
attention
from
TC
members
or
other
members
of
the
community.
I
think
that
will
make
it
easier
for
those
working
groups
to
to
integrate
with
our
process,
because
they'll
have
some
champions
and
it'll
also
help
ensure
that
whatever
the
proposals
are
there's
something
that
actually
works
well
with
open
telemetry's
existing
architecture,
in
other
words,
these
spec
members,
who
are
part
of
these
working
groups,
don't
necessarily
need
to
be
the
subject
matter,
Experts
of
that
working
group.
A
They
need
to
become
familiar
with
with
the
subject,
but
they
don't
need
to
to
be
the
expert
in
the
room,
who's
driving
the
design.
What
they
need
to
be
is
the
expert
in
the
room
on
open,
Telemetry
and
open
Telemetry
architecture.
So
if
we
have
people
coming
in
from
the
outside
say
around
like
around
client
stuff
or
other
things,
there's
there's
other
people
who
are
participating.
Who
are
experts
in
open
telemetries
architecture
and
that's
how
we
can
like,
hopefully
pave
over
the
the
bumpy
Parts
like
session
IDs
and
stuff,
like
that.
A
A
Idea,
I
think
if
we
can
get
that
going
starting
a
form
of
issue,
prioritization
explicit
prioritization
of
our
backlog,
based
on
and
doing
that,
prioritization
based
on
our
strategic
roadmap.
A
Well,
getting
the
core
Community
more
directly
involved
in
our
existing
working
groups,
we'll
be
able
to
to
kind
of
clear
our
plate
a
little
bit
faster
of
the
stuff,
that's
currently
on
it,
and
that
will
help
make
room
for
us
starting
more
projects.
In
particular,
we
know
we
want
to
start
a
number
of
working
groups
around
processing
these
semantic
conventions-
that's
actually
the
the
motivator
for
me
to
to
get
us
more
organized
because,
based
on
how
the
work
has
gone
with
semantic
conventions,
so
far,
it's
just
been
like
really
slow
and
I.
A
Don't
think
it
needs
to
be
that
slow,
I
think
we
could.
We
could
process
these
commit
conventions
at
a
much
faster
Pace
if
we're
a
little
more
organized
at
it,
and
we
have
there
are
so
many
conventions
if
we
don't
process
them
at
a
faster
Pace,
it'll
just
be
like
forever
before
everything
gets
stabilized.
A
So
that's
my
motivation,
I'm
curious
again.
If
people
have
any
feedback
on
this,
this
is
more
project
management
than
I've,
seen
in
other
open
source
projects,
but
I
think
we
have
such
a
large
kind
of
industry
standard
of
a
project
that
this
level
of
organization
would
would
really
help
us,
but
I'm
curious
what
other
people
think.
A
Yeah
I
I
think
we
should
we'll
have
to
work
out
what
the
right
granularity
is,
but
I
think
having
Milestones
if
it's
a
larger
project,
just
identifying
what
the
deliverables
are
and
having
a
milestone
for
when
that
working
group
is
going
to
deliver
their
spec
proposals
for
each
Milestone
and
then
having
maybe
a
month-long
public
commentary
period,
it
could
be
not
that
we
automatically
hit
the
merge
button
at
the
end
of
the
month,
but
some
way
of
being
able
to
say
announce
on
Twitter
and
social
media
and
other
places.
Hey.
You
know.
A
If
you
care
about
this
particular
thing,
will
be
doing
public
feedback
at
this
time.
So
those
those
are
like
the
two
dates
that
I
see
as
being
kind
of
important
for
people.
It's
just
like
the
Milestones
when
we're
going
to
deliver
spec
work
for
the
wider
Community
to
review,
so
that
also
so
that
we,
as
a
community,
don't
get
blindsided
I
didn't
mention
that,
maybe
that's
actually
something
I
should
add.
As
the
feedback
we've
received
from
our
side.
A
If
we
don't
know
that
a
working
group
is
about
to
like
come
back
with
a
set
of
oteps
that
require
a
lot
of
attention,
then
how
can
we
organize
our
own
time
and
so
to
prevent
us
from
being
kind
of
blindsided
by
suddenly
a
group
showing
up
and
being
like
hey.
A
That's
coming,
then,
you
know
we
can
manage
our
own
expectations
about
what
we
should
be
looking
at
so
I
think
that's
the
most
important
deadline
or
date
that
we
want
to
set
with
these
things.
H
Well,
as
an
example,
I
just
went
the
issue
for
the
function
as
a
service
working
group
that
we're
looking
to
kick
off
by
the
way
we
could
use
an
additional
TC,
approver
or
sponsor.
H
If
anybody
wants
to
join
on
that,
but
here
we've
proposed
that
there
will
be
a
six
week
period
once
we
get
this
started
for
us
to
identify
what
spec
improvements
we
want
to
make
and
then,
at
the
end
of
those
six
weeks
we
come
with
a
proposal
and
then
from
there
we,
whatever
the
process,
is
for
creating
the
proposals,
but
the
idea
would
be
that
when
we
start
we
know
this
is
the
the
end
date
that
we're
working
towards
and
obviously
that
won't
be
the
end
date
of
all
efforts
for
functions
as
a
service
work
right,
but
that's
the
for
the
initial
effort
of
okay.
H
A
Awesome
Yes,
perfect,
Carter
Socha
is
a
product
manager
from
lightstep
who
I
believe
has
been
helping
with
that
working
group
yeah
and
he's
offered
his
time
to
kind
of
help.
Us
do
some.
Some
like
TPM
work
on
our
issue,
backlog
in
general,
but
I,
think
that's
a
perfect
example.
By
having
a
working
group
commit
to
saying
like
Okay
in
six
weeks,
we
are
going
to
present
our
proposals
for
a
round
of
public
feedback,
and
that
doesn't
mean
it's
the
end
of
it.
A
But
at
least
we
know
that
six
weeks
from
now
we're
gonna
have
to
be
thinking
about
functions
as
a
service
for
a
bit.
If
that
working
group
is
going
to
get
feedback
from
us
in
a
timely
manner,
and
not
just
just
kind
of
like
stall
out.
A
We
kind
of
we
have
to
take
everything
we're
currently
doing
and
organizing
into
this
process.
So
it'll
take
a
bit
of
extra
time
at
first
kind
of
set
it
up.
A
A
The
other
proposal
that
I've
heard
is
we
use
the
maintainers
meeting
for
this
time,
because
that
already
kind
of
has
a
lot
of
the
stakeholders
who
should
be
there
in
it
and
that
meeting
doesn't
use
up
its
whole
time
most
of
the
time
it
usually
ends
early.
So
just
looking
for
a
way
to
do
this,
without
actually
putting
another
meeting
on
the
open,
Telemetry
calendar.
F
Hey
Ted,
yeah
I
would
support
use
of
the
maintainers
meeting
for
that
type
of
I.
Guess:
sort
of
administrative
planning
exercises
we
in
the
TC
last
whatever
before
the
break,
had
a
meeting
to
discuss
the
other
problem
which
you've
touched
on
about
oteps
and
the
need
for
a
focused
technical
review.
F
Basically,
the
idea
we
had
proposed
there
was
to
carve
out
10
to
15
minutes-
maybe
not
every
week,
but
in
this
meeting
time
for
a
technical
presentation
by
a
stakeholder
with
you
know,
sort
of
shepherded
by
a
TC
or
somebody
from
the
main
sort
of
coordination
exercises
so
yeah.
We
we're
already
planning
to
impact
this
meeting.
So
maybe
you
should
be
on
the
media
right.
A
A
A
Well,
well,
that's
all
I
am
I'll,
be
working
with
the
TC
and
the
GC
to
push
this
forward.
If
people
have
any
advice
on
how
to
do
this
kind
of
project
management
from
a
practical
standpoint
or
interested
in
in
helping
out
with
that
definitely
reach
out
to
me,
you
can
reach
out
to
me
on
slack
or
leave
comments
in
that
roadmap
proposal.
That
I
linked
to
in
the
meeting
notes.
B
Sweet.
Thank
you.
If
there's
nothing
else,
to
comment
on
that
front.
I
will
just
talk
briefly
about
net
issued
of
well,
it's
actually
the
opt
instrumentation
for.net.
B
Basically,
they
want
to
add
a
pattern
for
enabling-
or
you
know,
disabling
instrumentation,
like
Library
by
Library.
This
is
something
that
gel
ring
path.
At
this
moment
and
I
know
we
don't
want
to
add
more
environment,
variables
and
I
know.
There's
work
in
the
configuration
group,
but
there
was
the
the
issue
regarding
like
what.
If
we,
we
can
only
do
this
via
environment
variables,
and
the
question
is
whether
we
can
provide
a
battery
for
these.
You
know
that
would
signify
things
yeah.
I
I
A
So
there
is
a
config
management
working
group.
That's
that's!
Booted
off!
Would
that
be
like
the
appropriate
place
to
to
try
to
tackle
this
kind
of
stuff
holistically.
B
I
could
say
it's
we
need
both
I
would
like,
and
actually
we
know
like
they
have
their
meeting
every
Monday.
So
yesterday
there
was
no
meeting
but
yeah
I
think
that's
also
some
feedback.
We
want
from
them,
and
the
other
thing
is
that
I
said,
as
I
said
before,
sadly,
or
for
whatever
reason,
we
don't
want
to
add
more
environment
variables,
but
if
we
had
to
like,
would
it
work
or
not,
I
mean,
besides
to
support,
we
can
offer
from
the
configuration
group
side.
A
Our
concern
was
just
that
we,
you
know
it's
a
death
of
a
thousand
paper
cuts
right.
We
just
keep
packing
on
config
options,
and
when
you
do
that,
you
start
ending
up
with
options
that
interact
with
each
other
and
conflict.
It
becomes
a
little
bit
harder
and
harder
to
see.
What's
what's
going
on
and
I
think
we
were
starting
to
get
concerned
about
that.
A
But
we
do
have
a
working
group
now
I
see
Alex
is
on
the
call
Alex
I,
don't
know
if
you're
available
to
talk
about
that
working
group
briefly,
maybe
make
a
pitch
for
it.
D
I,
don't
know
if
I'm
in
any
state
to
give
a
pitch
for
anything,
but
I
will
say
that
there
is
a
working
group
and
I've
already
I've
put
the
link
to
one
of
the
issues
that
the
working
group
is
tracking
around
identifying
the
commonalities
of
cross
languages
for
instrumentation
configuration,
and
you
know
what
should
be
language
specific,
so
folks
are
interested
I
know.
Carlos
has
already
attended
the
meeting.
It's
every
other,
Monday
and
I
think
the
next
one
is
next
Monday.
E
C
E
Thing
I've
been
thinking
about
so
I'm
involved
in
that
config
working
group
as
well-
and
you
know
a
question-
that's
been
going
through
my
head
is
you
know,
do
we
want
to
focus
on
providing
a
config
schema
for
the
options
that
already
exist
and
you
know
draw
the
line
there
or
do
we
also
want
to
extend
the
scope
to
add
new
functionality
configuration
for
functionality
that
doesn't
necessarily
exist
yet
and
I'm
inclined
to
provide
options
for
things
that
already
exist?
E
First,
you
know,
let's
not
boil
the
ocean,
let's
do
one
thing
at
a
time
and
but
you
know
one
thing
that
we've
been
talking
about
is
as
Alex
brings
up.
Is
that
there's
you
know,
there's
a
desire
to
provide
use.
This
configuration
schema
to
configure
the
SDK
and
instrumentation
as
well,
and
there's
no
common
instrumentation
configurations
right
now.
That's
cross
language.
So,
in
one
respect,
adding
this
type
of
option
as
an
environment
variable
would
be
a
useful
exercise
because
it
would
force
us
to
consider
instrumentation
configuration
at
First
Class.
E
You
know,
and
there
would
be
at
least
some
some
configurable
surface
area
in
the
config
file
in
the
whatever
we
come
up
with
initially
for
instrumentation,
so
I
think
it
could
be
good
to
add
this.
This
option
or
I
guess
standardize
this
option
across
languages
and
incorporate
it
into
the
config
file.
Schema.
A
Totally
I
would
totally
agree
with
that
approach,
sizing
all
of
the
config
environment
variables
we
have
into
like
a
config
file,
but
then
also
going
around
to
the
various
implementations
and
seeing
things
like
this
that
we
already
have
and
some
implementations
and
maybe
standardizing
them
next,
would
be
really
useful
to
make
sure
that,
like
going
forwards,
I
think
there's
there's
some
worry
that,
like
we
might
Define
some
configuration,
that's
at
Cross
purposes
to
what
an
SDK
is
already
implemented.
A
So
it
would
be
really
great
to
make
sure
all
of
those
are
like
written
down.
First
but
I'm
excited
to
see
instrumentation
configuration
because
that's
an
area
where
config
really
starts
to
sprawl,
there's
already
quite
a
bit
of
little
bits
of
instrumentation
configuration
in
the
languages
where
you're
manually,
installing
instrumentation,
which
is
kind
of
concerning
to
me,
because
it's
really
hard
for
end
users
to
kind
of
keep
track
of
and
understand.
B
Okay,
great
since
it
doesn't
sound
like
a
totally
bad
idea:
yeah,
let's
discuss
that
next
Monday,
so
I
guess
that
anybody
who's
interested
in
this
I
would
try
to
to
mention
this
to
the
net.
After
instrumentation
group
people
they,
it
may
still
be
on
holidays,
but
let's
see
otherwise
they
will
be
myself
there
to
East
Coast
next
Monday.
B
Thank
you
for
that.
Nothing
else
in
the
agenda
anything
else
to
be
scarves.