►
From YouTube: 2023-01-11 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
Let's
wait
for
another
minute
or
two
I
think
Blanche
told
that
he'll
be
joining
a
bit
late.
He
has
to.
He
has
some
microphone
issues
and
has
to
restart
get
Windows
updates
as
well.
So
foreign.
D
D
D
A
I'm
on
a
Mac
New
Relic
is
pretty
Max.
Centric
I
had
the
option
to
get
a
Windows
machine,
but
you
know
just
being
able
to
collaborate
on
things.
Beyond,
just.net,
stuff
and
Relic
Mac
makes
it
a
little
more
easy.
A
D
F
A
A
Much
better
like
it
had
no
problem
recognizing
that.
B
Cool
I
guess
we
can
start
now
so
yeah
1.4.or
C2
version
was
released
yesterday
and
I
think
we
are
on
track
to
release
the
stable
version
by
the
end
of
the
month,
and
we
just
added
this
as
like
I
mean
I,
think
this
was
already
discussed,
but
I
don't
think
anyone
would
have
issues
with
by
removing
the
opposite
apis.
So
we
don't
expect
another
RC
release
and
it
was
planned
that
before
the
stable,
stable
release,
we
would
remove
the
obsolete
apis.
B
Oh
sorry,
extension's
hosting
thanks
for
collecting
that
yeah
and
I
have
added
these
two
items
on
the
agenda.
If
anyone
else
has
anything
important
to
discuss,
I
think
we
can
discuss
that
first,
because
these
two
would
take
some
time.
A
Think
sorry,
I
do
have
oh
I
I
do
have
one
thing
that
I
want
to
talk
about
is
I,
don't
think
it
should
be
a
big
thing,
I'm.
Looking
for
a
link,
it's
the
the
package
naming
we
don't
have
to
talk
about
it
first
or
anything,
but
I.
B
B
So,
okay
I
think
that
probably
will
take
the
most
amount
of
time.
The
discussion,
let
me
go
through
the
pr
then
this
one
actually
is
by
first
time
contributor.
So
like
I,
like
don't
wanna
like
ask
him
to
change
stuff
too
much,
but
it
looks
like
we
might
have
to
so.
What
they're
trying
to
do
is
just
add
something
like
add:
enrich
functionality
to
The
Entity
framework
instrumentation.
B
And
so
for
Entity
framework,
core
I
I
had
originally
suggested
that
you
use
enrich
like
that.
They
use
enrich
like
the
old
kind
of
language
that
we
used
to
have
in
our
HTTP
client
and
asp.net
core
instrumentation,
where
we
just
passed
the
passes,
string
activity
and
the
string,
which
represents
where
exactly
it's
being
called
in
the
execution
and
then
a
payload
and
Peter
had
made
a
comment
about
using
enrich
with
and
like
with
the
exact
object,
instead
of
just
passing
a
general
object.
But
what
I
noticed
was
for
Entity
framework.
B
We
don't
have
any
dependency
on
like
any
of
the
like
data
or
whatever
packages
that
bring
the
command
and
connection
and
those
objects.
So
we
always
deal
with
just
objects
like
everything,
even
when
we
cast
them
when
we're
using
reflection,
it's
always
been
objects.
So
it's
kind
of
like
understand
like
what.
How
much
useful
would
it
be
like
idb
connection?
B
Sorry,
yeah
cool,
okay.
Let
me
start
over
again,
so
there's
this
PR,
where
someone
is
trying
to
add
and
Rich
functionality
to
The
Entity
framework
code,
instrumentation
and
I
had
originally
told
them
to
like
follow
the
old
enrich
style
which
we
used
to
have
in
our
main
repo
instrumentations,
where
we
would
have
an
activity
and
a
string
past,
which
would
show
which
basically,
the
notes
were
in
the
execution,
is
the
enrich
being
called
and
a
payload,
so
Peter
from
who's
the
approver
of
contract
report.
B
He
made
a
suggestion
about
enrich
using
enrichment
part
and,
as
that's
the
one
that
we've
moved
to,
but
what
I
didn't
know
was
like
with.
Whenever
we
used
enrich
within
our
main
repo,
we
have
the
actual
type
of
the
payload
right.
We
don't
pass
object
anymore,
like
it's
either
HTTP
request
message
or
response
message,
but
here
I
think
with
with
Entity
framework
core.
It
was
like,
whatever
we
did
inside
the
callback
on
this
old
custom
callback.
All
of
these
word
objects.
They
were
just
object
types.
B
F
F
B
Yeah,
so
every
case
will
have
its
own
language.
At
some
point
we
might
have
some
asks
saying
like
we
need
some
kind
of
language
for
exception,
then
something
for
executing
something
for
executed.
So
that's
going
to
lead
to
four
options
and
like.
A
B
Expect
more
cases
to
be
created.
In
that
case
we
will
have
more
enrich
options,
and
otherwise
we
can
just
have
this
one
simple
and
Rich,
which
uses
everything
and.
F
A
I
think
these
are
all
really
good
questions.
One
thing
that
we
talked
about
with
the
HTTP
stuff
and
I
know
why
we,
you
know
weren't
a
fan
of
this,
but
with
HTTP
we
discussed
instead
of
passing
in
the
actual,
like
framework
type
like
HTTP
web
request
or
whatnot,
that
we
use
our
own
abstraction
or
wrapper
around
the
thing.
A
Of
course,
you
know,
there's
downsides
there
allocation
whatever
additional
overhead,
but
in
this
use
case
right,
like
the
the
benefits
of
of
of
talking
of
entertaining
an
idea
like
that,
may
be
greater
one
of
the
things
that
I
see
happening
right
with
like
different
providers
and
and
so
on,
is
that
that
the
types
that
are
being
passed
to
enrich
are
going
to
be
different.
You
know,
depending
on
the
provider
and
maybe
the
and.
F
A
May
be
different,
for
you
know
each
each
one
of
these
different
events
or
callbacks.
C
A
B
So
like
at
least
for
this
one
I
think
like
we
want
to
pass
connection
object
when
it's
falling
into
this
case
want
to
pass
command
when
it's
falling
in
this
case,
and
then
exception
in
case
of
Entity
framework
Arrow
so
exception.
I
guess
will
be
its
own
thing,
but,
like
you're,
saying
somehow
use
an
object,
common
object
from
which
you
can
derive
both
these
types,
like
you
can
get
to
both
connection
and
command.
A
Yeah
I
guess
the
fortunate
thing
about
it.
These
is
that
yeah,
it's
probably
idb
connection
and
idb
command.
So
there
is
already
kind
of
a
common
interface.
Okay.
C
B
B
You
know
that
issue
is
mentioned.
We
are.
B
Yeah
and
also
yeah
I
think
this
is
by
our
first
time
contributor.
So
I
was
thinking.
We
should
like
not
asking
to
do
so.
Many
changes
at
once
I
mean
in
the
same
PR,
but
yeah.
B
Yeah
so
like
maybe
like
Alan,
maybe
like,
if
you
have
time
just
review
this
VR
and
see
if
this
makes
sense
to
you
the
changes
in
this
one.
A
B
A
Can
do
that
I
have
not
looked
at
this
one,
yet
sorry,
I
can't
say
anything
like
super
opinionated.
At
this
point.
C
B
Cool
I'm
gonna
go
to
the
next
thing,
so
we
have
Martin
on
the
call.
Hey
Martin
did
you?
How
are
you
doing
I'm.
E
Good
well
I'm,
actually
terrible
at
the
moment,
because
I've
got
a
cold
and
not
sleeping
but
other
than
that
I'm
good.
Just
to
note,
I
changed
the
2022
to
2023
because
it
was
bugging
me
on
that
document
and
it
does
say
2022
on
the
one
that
I'm
assuming
you
did
last
week.
E
E
I
got
barraged
over
Christmas
with
five
different
people,
lamenting
about
the
versioning
problems
where
they
got
themselves
in
a
load
of
hell
with
the
1.4
versions
of
pre-release
of
hosting
and
stuff
like
that.
So
I
would
like
us
to
get
out
a
1.4
as
soon
as
humanly
possible.
B
Yeah
I
mean
I
think
we
are
on
track
to
release
this
table
by
the
decided
Milestone
date,
which
is
the
end
of
the
month,
30th
Jan.
So.
E
We've
not
got
anything
that
I
can
help
with
that's,
not
stable
or
needs
some
more
looking
at
I've,
looked
at
all
the
apis
and
played
with
them,
and
things
seem
to
fit
together
when
you've
got
other
versions
matching
up
nice.
C
Right
before
the
holiday
break
was
we
didn't
want
to
release
when
everyone
was
looking
on
vacation,
we
wanted
to
kind
of
put
an
RC
level.
You're
gonna
give
it
some
sober
time.
Once
everyone
came
back
and
then
there's
been
kind
of
a
circle,
what
I
was
subtle
one.
You
know
if
there's
others
that's
why
we
put
another
overseas.
We
just
kind
of
want
to
see
a
week,
maybe
some
days
where
there's
just
no
longer
reports
to
give
us
kind
of
like
a
sanity,
we're
good
to
do
stable.
So
we
discriminate
ourselves.
E
C
E
E
D
Just
give
me
a
thumbs
up
Mike.
If
this
makes
sense,
you
said
that
they
decided.
Basically,
they
didn't
want
to
do
the
release
during
break,
as
people
might
not
necessarily
see
it,
so
they
wanted
to
give
themselves
January
in
order
to
get
the
RC
out
there
get
some
soak
time,
as
he
called
it.
Basically
just
allow
for
a
period
of
time,
which
there
were
hopefully
no
bug
reports,
in
which
case
they
would
be
ready
to
to
actually
do
the
the
normal
release.
D
F
A
Martin,
did
you
I
know
that
there
was
an
issue
I
think
it
came
from
a
Twitter
thread
from
Aaron
and
did
was.
E
E
E
I
managed
to
get
it
working,
but
not
repeatably,
as
in
I
managed
to
replicate
it,
but
not
repeatedly
so
intermittently,
yes,
I
managed
to
have
those
problems
and
I've
had
loads
of
it.
Over
Christmas
of
people
going.
E
Here's
my
CS
project
file
and
pulling
in
a
1.4
pre-release
of
Hosting
was
the
most
common
issue,
because
if
you
do
the
pre-release
version
of
Hosting
that
it
will
get
the
most
recent
which
is
1.4,
so
a
lot
of
people
were
having
that
as
a
problem
and
getting
all
these
obsoletes
and
the
docs
weren't
matching
up,
because
it's
the
pre-release
version
and
the
docs
say
get
the
pre-release
version
of
Hosting
because
that's
the
only
version
of
it
but
the
docs
don't
say
that
we've
deprecated
the
methods
because
we
haven't
released
those
yet
so
people
are
ending
up
with
warnings
in
the
code
all
over
the
place
and
stuff
like
that.
E
But
I
got
a
barrage
of
them
over
Christmas.
My
response
was
1.4
is
coming
for
now.
Here
you
go
here's
the
special
incantation
of
versions
just
use
those
which
is
basically
just
use
9.4
for
everything,
and
that
seems
to
get
most
people
passed.
E
A
Is
yeah,
though,
in
addition,
I
mean
I,
understand
the
the
confusion
and
documentation
not
not
aligning
and
and
so
on,
but
I
I
thought
that
there
was
also
like
a
breaking
issue
or
some
some
something
that
seemed
like.
Somebody
was
running
into
a
situation
where
maybe
there
was
a
crash
or
incompatibility.
E
Yeah,
that's
that's
the
thing
that
we
were
getting.
That
was
an
actual
crash,
between.net,
seven
and
Dot
net,
six,
which
I
think
was
to
do
with
compiling
on
Windows
for
Net
7
and
it
bringing
in
the
seven
the
six
diagnostic
source.
E
E
So
it's
more
to
do
with
people's
machines
set
up
with
multiple.net
versions
and
deploying
differently
by
looks
of
it.
But
it
seemed
to
be
assuming
that
if
you
compile
on.net7,
it
doesn't
need
to
bundle
since
system.diagnostic7.
E
E
A
Yeah
I
guess
that's
the
part
that
I'm
I'm
also
confused
by
anyways
like
I.
Guess,
if
the
thing
the
the
more
General
thing,
that's
on
my
mind
is
just
you
know,
right
now,
there's
confusion.
Obviously
some
people
are
actually
having,
like
you
know,
problems
like
this,
if
there's
anything
that
we
can
do
or
consider
in
the
future,
because
you
know
we
may
in
the
future,
have
a
similar
situation
where
we
have
a
release
that
people
are
waiting
on
for
a
few
months.
E
So
the
problem
this
time
was
to
do
with
the
multiple
Pres.
That's
the
problem.
So
it's
the
fact
that
we
had
a
pre-release
for
that
was
1.0
RC
9.9
and
the
pre-release
that
was
1.4
and
the
pre-release
of
the
open,
open,
Telemetry
extensions
hosting,
was
depending
on
1.4
and
didn't
match
the
documentation.
So
the
documentation
was
allowing
saying,
install
the
pre-release,
but
then
use
these
methods
that
are
now
deprecated,
because
the
pre-release
that
they
were
installing
wasn't
the
same
one
I,
don't
think
we
will
get
that
problem
in
the
future.
E
Okay,
okay,
there
is
a
message
I
put
in
the
net
Channel
and
I.
Don't
know
how
viable
this
is
about
the
semantic
conventions,
because,
obviously,
the
reason
why
our
instrumentation
libraries
are
pre-release
and
not
release
is
because
of
semantic
conventions
and
nobody
pulling
their
finger
out
to
do
it,
which
I
have
a
lot
of
people
who
are
trying
to
get
that
through.
E
But
it
ain't
going
to
happen
anytime
soon,
so
my
thought
was:
could
we
release
based
on
a
version
of
the
semantic
conventions
that
is
currently
versioned
in
the
libraries,
so
in
the
docs?
At
the
moment?
There
is
a
a
load
of
tables
that
build
that
up
and
I
think
somebody
built
a
package
didn't
they
for
the
semantic
conventions
that
builds
a
strongly
typed
version
of
them.
E
Is
that
a
potential
for
us
to
explore
so
that
we
can
get
the
instrumentation
libraries
to
say
well,
yeah
they're
released
they'll
use
whatever
semantic
convention
versions,
you
pass
it
so
upgrade
your
semantic
conventions,
version
Library
and
it'll.
Take
it
from
there.
Maybe
it's
an
interface
Library,
so
that
we
can
depend
on
a
released
interface
library
that
will
provide
us
with
an
implementation
that
is
pre-release.
A
E
So
we
can
pull
in
the
semantic
conventions,
but
they
have
to
say
right:
yeah
I'm,
going
to
pull
in
the
the
beta
version
of
semantic
conventions,
and
that
will
be
the
implementation
inside
of
the
conventions
Library.
If
you
like
the
conventions
interfaces,
it
could
be
a
nice
Innovative
way
to
get
around
the
pre-release.
E
Because
if
we
can
get
all
of
our
libraries
released
as
actual
versions,
all
this
dependency
hell
stops
and
we
can
have
versions
that
are
pre-release
and
all
of
that
kind
of
stuff,
and
it
will
all
I'm
confident
just
work.
But
the
problem
is
once
we've
got
a
pre-release,
so
say
we
had
a
version
two
of
open
telemetry
and
the
instrumentation
libraries
now
need
to
be
the
version
two
RCS.
So
we've
got
the
version.
E
E
A
Kind
of
there
might
be
there
might
be
a
technical
solution
here.
I
obviously
need
to
think
about
it
more
deeply,
but
I
mean
I
think
that
I
think
you'd
probably
fall
into
some
gotchas.
Like
specifically
for
like
say
like
one
one
case,
you
know,
as
the
semantic
conventions
evolve,
certain
attributes,
maybe
renamed
dropped
or
even
added,
and
if
the
instrumentation
has
been
released
as
stable
right,
you
might
be.
A
You
might
configure
hey
use
these
new,
updated
semantic
inventions,
but
that
instrumentation
may
not
at
all
be
capable
of
emitting
certain
attributes
based
off
of
the
changes.
I
think
that
the
best
place
for
this,
like
conversation
to
probably
be
had
in
the
community
at.
A
Is
probably
the
semantic
conventions
working
group,
because,
to
my
knowledge
like
this,
is
not
necessarily
just
a.net
problem
like
no?
No
language
ecosystem
has
released
stable
instrumentation
as
of
yet
and.
E
So
I
believe
go
they
don't
Mark
him
as
pre-release.
There
are
ones
that,
yes,
they
haven't
released
a
stable
one,
but
their
versioning
isn't
pre.
So
it's
not
a
beta.
It's
not
an
alpha
on
the
conventions.
So,
even
though
they
haven't
I
can't
remember
which
one
there
was
two
that
somebody
sent
me
because
I
used
that
exact
thing
of
no
libraries
can
do
it
and
they
went
well.
This
one
does
I'm
like.
F
A
Those
are
worth
studying
you
know
to
validate
for
sure
whether,
like
you
know,
we
we
have
one
example
right.
The.Net
instrument,
runtime
instrumentation,
has
been
really
stable,
but
you
know
there's
a
reason
behind
that
in
that
you
know
it's
this
community,
that
that
defines
those
conventions
and
we
have
full
purview
over
them.
So
I'd
be
curious
to
see,
understand,
maybe
ask
the
go
community
their
logic
behind
the
instrumentation
packages.
You're
talking
about.
E
E
E
How
you
would
get
around
those
gotchas
that
you're
talking
about
and
I,
can
see
some
of
them
coming
up.
It
would
require
a
little
bit
of
thought
and
to
see
whether
that
is
possible,
but
yeah
being
able
to
say
oh
yeah
I'm,
using
the
1.7
version
of
the
semantic
conventions
or
the
1.8
version,
which
may,
like
you
say,
drop
or
move
some
attributes
around
and
be
able
to
do
that
without
affecting
the
rest
of
the
libraries
could
be
quite
an
interesting
thing
to
think
about.
A
E
Possibly
but
I'm
traveling
for
about
three
weeks
so
in
between
travels,
maybe
I
think
my
my
biggest
one
at
the
moment,
I'm
working
on
is
a
doing
all
their
performance.
Stuff
I
talked
about
before
Christmas
trying
to
validate
that
for
the
people
who
say
adding
instrumentation
slows
down
my
app
providing
some
constantive
numbers
around
it
in
a
real
app
as
well.
E
That's
where
my
focus
is
at
the
moment,
because
I
don't
have
confidence
that
we
would
be
able
to
get
something
like
that:
semantic
conversions
off
conventions
off
the
ground
anytime,
soon
so
focus
on
the
things
that
we
the
objections
that
we
can
sort
out
now,
let's
focus
on
those.
E
Anyway,
I've
talked
quite
a
lot
like
I
say
for
me:
if
we're
going
to
get
that
release
out
on
the
30th,
then
I
don't
see
a
reason
for
us
to
investigate
too
much
any
of
the
other
bits.
I
did
some
investigation,
but
I
didn't
get
anything
conclusive
as
to
why
it
wasn't
bundling
the
system.diagnostics.
E
If
we
push
again
and
it
pushes
into
February,
then
I
think
there's
a
lot
that
we
need
to
do
to
try
and
quell
this,
because
it
seems
to
be
becoming
a
little
bit
of
a
snowball
I'm
getting
more
and
more
each
time.
I
have
three
customers
last
week
that
ended
up
in
this
whole.
E
E
B
I
think
like
this
one,
we
can
move
this
down
because,
like
maybe,
we
should
look
forward
to
discuss
that
case,
even
okay,
because
there
will
be
a
PR
out
soon
for
this
I
think
that
there's
already
one
out
yeah.
A
The
general
conversation
here
is
an
issue
that
I
opened
a
while
back,
not
on
the
contribute
but
the
the
main
repo,
and
it
was
one
to
just
kind
of
consider
how
we're
naming
packages
a
lot
of
our
packages
still
are
pre-release
specifically
in
the
contributory
poll.
So
you
know
we
still
have
an
opportunity
to
maybe
become
a
little
bit
more
opinionated
with
our
with
our
naming,
make
it
more
descriptive.
A
I
had
it
on
my
mind,
a
while
back
and
I
think
it's,
it's
probably
still
a
good
thing
to
do
actually
to
open
up
individual
issues
for
each
of
the
existing
packages.
That
may
be
a
rename
should
be
considered.
A
Basically,
the
idea
is
that
this
package
originally
named
open,
telemetry.extensions,
Dot,
Docker
I,
think
yeah
talker
foreign
to
instead
of
overuse
the
term
extensions,
which
you
know.
Does
that
mean
that
it
has
extension
methods
in
it?
Does
that
mean
you
know
kind
of
in
the
microsoft.extension
sense,
or
does
it
mean
that
it
has
like
extensions
to
the
SDK
in
it,
which
is
like
kind
of
a
totally
different
thing?
Or
is
it
just?
You
know
a
convenient
word
to
say,
like
I.
A
Else
to
better
call
this
the
at
least
this
package-
you
know
it's,
it's
I,
think
probably
never
going
to
have
anything
other
than
resource
detectors
within
it.
I
not
saying
that.
E
A
Strongly
because
I
haven't
spent
a
ton
of
time
thinking
about
this
package,
but
if
that's
the
case,
then
I
was
curious.
What
other
folks
thought
about
specifically
this
type
of
thing,
like
it's
an
SDK
extension,
you
know
much
like
with
exporters
which
are
also
an
extension
to
the
SDK.
We
have
exporter
in
the
name
of
the
package.
Does
it
make
sense
to
folks
to.
F
A
F
B
Definitely
think
it's
better
to
have
more
specific
Words,
which
have
a
much
more
specific
intention
in
their
description.
So
I
like
for
this
one
I
think
it
is
simple,
because
we
know
that
this
package
is
all
about
resource
detectors.
B
B
I
do
feel
that
if,
if
it's
easy
to
tell
that
a
particular
package
name
would
be
much
more
meaningful
and
intuitive
to
users,
we
should
choose
that
over
using
some
general
term,
like
extensions
which
could
cover
a
lot
of
things,
as
you
said,
and
for
the
singular
and
plural
like
I,
wanted
to
ask
that,
like
I,
think
you
said
that
for
this
one
probably,
we
should
use
we're
not
going
to
have
two
things
right.
Are
we
going
to
do
that
as
well?
Like,
let's
say,
there's
a
package
which
has
multiple
resource
detectors.
B
A
A
Bad
I
think
I
voted
for
singular
here,
namely
because
of
our
prior.
You
know
we
already
have
exporter
packages,
which
you
know
it's
not
open.
Telemetry.Exporters.
A
Though
I
did
reflect
on
this
opinion
of
mine
here
or
this
vote
a
little
bit
more,
you
know
I
think
that
if
we
were
the
package
names,
you
know,
you
might
say,
are
kind
of
similar
to
the
naming
of
namespaces
and
I.
Think
that,
like
the
dot
net
guidance,
around
naming
namespaces
would
actually
it
could
pull
this
up,
but
I
think
that
there's
some
guidance
around
using
plural.
A
So
there
might
be
an
argument.
You
know
to
open
telemetry.resource
detectors,
plural
here
and
I
I,
don't
know
that
I
feel
strongly
one
way
or
another,
but
whatever
we
decide
here,
I
think
going
forward.
We
should
have.
We
should
stay
consistent
so
like
if
we
had
a
a
package
like
an
SDK
extension
package
that
had
processors
in
it
like
a
span
processor
or
something
like
that,
it
should
be
open.
Telemetry.Processors
Dot,
you
know
whatever.
That
is.
F
A
Plural,
based
off
of
you,
know
some
more
General
like
dot
net
naming
guidance,
specifically
regarding
name
spaces
which
might
have
some
similarity
to
this.
Like
this
package
naming
do
you
have
a
strong
feeling
of
plural
versus
singular.
E
So
from
a
person
who
uses
the
libraries
a
lot,
the
amount
of
times
I
get
mixed
up
between
exporter
versus
exporter
and
extension
versus
extensions
with
trying
to
add
the
packages
because
I
use
the
command
line
extensively
so
I
add
the
packages
using
the
command
line.
I
get
mixed
up
between
those
two
quite
a
lot.
E
E
If
you
add
the
resource
detector
on,
it
sits
under
open,
Telemetry
dot
extensions,
so
that
no
matter
how
many
extensions
you
add,
they
all
sit
under
that
namespace
I.
Think
that's
a
good
convention
because
that's
known
for
users,
but
that
would
be
my
two
pennies
from
a
person
who
implements
it
and
uses
it.
A
E
I
think
that
would
follow
the
same.
The
same
convention
that
Microsoft
used
for
say
the
Triad
Singleton
for
dependency
injection
where
they
add
the
package
I
think
it's
the
package
in
the
namespace
are
not
always
the
same.
E
E
It's
very
verbose,
but
it
is
always.
It
is
slightly
more
modular
as
well,
though,.
E
Do
people
care
about
how
many
packages
they
install
in
their
CS
project
these
days
I
mean
we
don't
want
to
compete
with
no
modules.
Let's
you
know
make
that
a
little
Line
in
the
Sand,
but.
A
I
think
one
thing
that
would
help
me
in
this
conversation
is
a
more
holistic
conversation
about
not
just
this
package,
but
the
other
packages
just
to
see.
If
we,
if
we
can
see
more
of
a
pattern
in
our
thinking
across
more
than
just
this
one
isolated
example.
A
But
that
said
you
know,
I,
don't
I,
don't
think
this
conversation
should
necessarily
hold
up.
I
mean
the
the
pr
against
this
package,
which
introduces
additional
functionality.
A
So
my
question
to
maybe
the
folks
that
are
more
familiar
with
that
package
and
are
itching
to
get
that
may
be
released,
would
be
I
understand.
It's
recently
introduced
functionality
that
has
not
just
Docker
specific,
but
what
if
we
were
to
do
another
release
just
with
the
old
existing
name
as
it
is
and
if
that's
desired?
If
that's
what
people
want,
then,
let's
Circle
back
to
this
after
we've
done
a
little
bit
more
thinking
about
package
naming
again
more
holistically
than
just
this
isolated
case.
B
A
B
Yeah,
like
with
the
people
who
approved
and
like
and
reviewed
the
pr
and
the
author,
actually
because.
A
B
E
B
Not
we
still
want
to
take
some
time
before
deciding
before
finalizing
how
we
are
naming
this
right
in
that
case
like,
if
they
want
to
be
able
to
use
the
functionality
they
can
because
we'll
just
release
it
with
the
same
existing
name.
If
they
are
okay
with
it,
we
can
then
decide
on
the
appropriate
name.
I.
A
Considered
things
a
little
more
deeply
across
other
packages,
that's
my
thought.
B
A
Actually,
like
one
question
again:
I'm
not
I,
haven't
reviewed
that
other
PR
that
introduces
the
new
functionality
much,
but
why
was
it
added
to
this
package
in
the
first
place
versus
a
a
different
package?
Is
it?
Is
there
somehow
like
overlap
that
made
it
make
sense
for
it
to
be
part
of
this
package?.
F
A
F
A
E
A
Okay,
so
I
guess
I'll
take
a
couple
of
action
items.
One
I'll
comment
on
this
on
the
on
the
pr
that
adds
that
new
functionality.
A
That
we
ship
it
with
the
existing
name,
at
least
for
now,
I'll
comment
on
Peter's
PR,
stating
that
we're
like
to
hold
off
on
renaming
the
package
until
we
have
a
a
bigger
conversation
around
package
naming.
F
A
Then
I
will
update
my
issue
with
Martin
suggested,
like
kind
of
a
table
format
that
basically
at
least
I'll
take
an
initial
stab
at
names
that
make
sense
to
me,
but
I
think
that
will
help
others
chime
in
with
opinions
of
Their
Own
can.
B
Okay,
Dan
posted
this
on
the
chat
looks
like
this
is
the
this:
is
the
project
so
open
Telemetry
resource
detector,
container.
A
Yeah,
wherever
I
suggested,
with
the
naming
yeah
and
what
Peters
has
PR.
A
So
that's
one
data
point
you
know
I'd
be
interested
in
looking
at
maybe
Java
and
maybe
go
as
well.
I
think
that
they
have
these
components.
F
E
B
E
C
E
That's
the
thing
I
was
talking
about
at
the
moment,
yeah
I
mean
I
was
just
pretty
much
exactly
the
same
as
that
isn't
it.
But
when
we
go
through
that
big
list
and.
F
E
This
is
how
it
works.
You
know,
that's
the
that's
the
thing
that
we've
got
to
make.
That
decision
on
which
one
do
we
mean
consistent
with
Microsoft
conventions,
General
C,
sharp
in
the
wild
and
Dot
net
in
the
wild,
or
something
more
more
polyglot
for
people
who
are
dealing
with
open
Telemetry
across
multiple
languages,
more
SRE
type
people.
F
A
That
I
I
still
like
open,
telemetry.resourcetectors
dot
dot
container
I
mean
we
there.
There
are
other.net
examples
of
that
like
I.
Think
Siri
log
is
a
great
one.
You
know
serial
log
splits
up
its
its
types
of
extensions
effectively
into
different
package
name
spaces.
So
like
there's
a
number
of
packages
that
start
with
serialog.syncs
serialogue
DOT
enrichers,
serialog.formatters
Etc.
F
F
F
B
F
B
Yeah
I
think
there
are
no
nothing
else
to
discuss.
I
think
we
can.