►
From YouTube: 2021-06-09 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
B
A
C
D
C
You
can
see
my
screen
yep.
Okay,
thank
you,
yeah.
We
can
get
started.
Sorry
for
the
delay.
It
looks
like
we
don't
have
much
update
so
I'll.
Just
share
my
cube
update
about
the
1.1
release.
I
did
not
have
any
time
to
review
the
like
pending
pr's,
which
are
mandatory
for
1.1.
C
I
will
be
getting
to
them
this
week.
I
had
a
very
tough
on
cold
week
last
week,
so
there
was
nothing,
no
time
left
for
reviewing
these
peers.
C
But
having
said
that,
there
is
some
update,
which
utkar
shared
with
me
earlier,
that
there
is
a
breaking
change
which
we
initially
assumed
was
a
breaking
change
from
1.0.1,
however,
like
after
utkarsh
did
his
investigation,
it
was
found
that
the
breaking
change
was
not
from
the
stable
version
to
the
1.1.
It
was
like
between
two
beta
versions:
that's
one
of
the
reason
why
we
are
not
able
to
detect
it
using
the
tool.
C
There
is
a
new
tool
in
dotnet
which
can
be
used
to
detect
this
so,
but
just
to
summarize
things
we
will
be
releasing
most
likely
tomorrow
in
new
version
of
the
apa
sdk
and
the
instrumentations,
which
would
fix
the
or
which
would
mitigate
the
breaking
a
breaking
change
issue.
I
don't
think
that
we'll
have
time
to
incorporate
like
anything
else
into
it,
because
we
just
want
to
make
sure
just
that
is
released,
so
that
people
are
unplugged
and
after
that,
we'll
come
back
and
do
the
other.
C
Pr
which
is
mentioned
here
like
these
are,
must
have
appears
so
we'll
come
back
to
it
like
tomorrow.
After
we
do
a
release
to
unblock
others,
it
looks
like
I
got
another
pr
like
few
minutes
earlier.
I
didn't
check
that.
I
don't
know
whether
like
did
you
see
that,
like
fpr
for
adding
the
apa
compact.
E
No,
I
haven't
it's.
Okay,.
C
Yeah
I
mean
it
was
added
like
a
few
minutes.
Oh
yeah,
three
hours
early,
so
it
seems
like
someone
is
trying
to
use
the
api
compact,
but
this
is
a
package
which
you
said
like
there
is
an
alternate
tool
to
this
one
right
like
no.
E
Yeah,
so
this
one
like
the
dotnet
team,
is
going
to
publicly
release
something
to
new
get
with
the
during
the
dot
and
six
release.
E
Yeah,
so
this
one,
if
this,
would
they
won't
like
they
won't
publish
this
to
nougat
they're
gonna
do
do
it
with
the
new
package,
which
is
which
will
be
under
package
validation,
which
will
not
only
look
at
api
compatibility,
but
also
look
at
the
api
surface
compatibility
for
different
target
frameworks,
and
things
like
that
which
we
were
running,
the
issues
that
we
were
running.
C
Yeah
we
were
having
all
those
all
sort
of
issues
like
that:
yeah,
okay,
okay,
if
that's
the
case
like,
like
we
get
like
someone
from
officially
from
dotnet
to
confirm
that
this
is
not
the
package
to
use
in
the
long
term,
but
we
are
okay
to
like
use
it
temporarily,
just
to
see
how
it
works,
because
whatever
is
upcoming,
is
just
a
superset
of
what
this
provides.
D
C
Yeah
yeah,
but
like
let's,
like
unblock
the
broken
users
right
now
by
releasing
tomorrow,
and
then
we
can
figure
out
what's
the
best
way
to
incorporate
this
into
our
ci.
It's
totally
okay,
if
we
just
do
it
like
manually
for
1.1
and
figure
out
the
ca
automation
like
later.
C
C
Okay,
yeah,
that's
pretty
much.
What
I
wanted
to
share
quickly
before
we
go
to
rest
of
the
items
polo
is
here,
yeah
follow.
Do
you
want
to
like
share
this
update?
I
mean
just
for
background,
like
there
was
some
ask
in
the
maintenance
meeting
about
the
direction
in
which
both
auto
instrumentation
effort
and
this
six
are
going.
C
There
was
an
ask
whether
there
is
a
dependency
yet
between
these
two
or
they
are
like
completely
parallel,
so
like
follow,
can
share
then
update
on
auto
instrumentation
sick,
which
is
eventually
going
to
use
a
sdk
which
is
shipped
from
this
repo
follow,
go
ahead
and
give
your
update
and
see
if
there
is
any
follow-ups
today.
F
Yeah,
so
we've
been
some
time
trying
to
accommodate
the
old
tracer
that
existed
on
the
code
base
that
we
had,
but
we
decided
now
that
we
have
the
1.1
of
the
1.0,
I
mean
of
the
sdk.
We
decided
to
kind
of
give
a
try.
We
knew
that
there
will
be
some
problems
about
the
version
about
old
applications
using
a
system
diagnostic
diagnostic
source
that
didn't
match
the
sdk,
but
by
doing
some
experiments
we
think
that
we
have
a
solution.
F
That's
reasonable,
basically,
for
framework,
we
base
it
on
binding
redirects.
We
want
to
kind
of
facilitate
that,
but
we
depend
on
that
and
on.net
core.
Basically,
we
can
leverage
the
nuget
package
version
resolution
and
could
be
something
very
simple
as
just
asking
the
application
to
have
a
reference
to
the
version
that
the
sdk
depends.
F
So
then,
auto
instrumentation
can
really
start
to
use
the
sdk,
the
exporters
and
everything
we.
F
That
is
not
a
hundred
percent
decided
yet,
but
I'm
not
seeing
any
problem,
so
that
should
be
really
happening
very
soon.
Unless
some
new
thing
come
up,
we
still
have
a
few
tests
to
do,
but
it's
very
likely
that
soon
we
are
gonna,
perhaps
or
be
submitting
prs
or
asking
help
to
get
some
stuff
from
the
sdk,
for
instance,
for
auto
instrumentation
configuration
via
environment
variables
is
very
important
because
the
user
typically
don't
write
the
bootstrap
of
the
sdk.
F
So
it's
very
likely
that,
as
I
said
either
we
start
to
open
prs
for
that
or
ask
for
help
to
get
some
of
that
stuff.
Sorry
on
the
sdk,
but
this
was
something
that
we've
been
struggling
quite
some
time
with
and
I
think
we
kind
of
anticipated
that
the
problems
were
not
going
to
be.
F
There
will
be
no
satisfactory
work
around,
but
we
decided
to
do
the
poc
and
now
I
think
that
actually
the
workarounds
are
good
enough.
You
know
one
thing:
the
limitations
will
be
things
like.
If
you
have
an
application,
that's
completely,
you
are
getting
just
the
il.
You
don't
have
the
you
are
not
building
the
project.
Perhaps
in
a
scenario
like
devops
or
something
like
that,
and
you
can
change
the
build.
F
Then
it's
going
to
be
a
bit
harder
to
use
out
instrumentation,
but
we
think
that
is
a
reasonable
compromise,
because
the
majority
of
people
have
access
to
the
build.
You
know,
and
so
we
are
very
happy
with
what
we've
seen
so
far
and
I
think
we
are
really
going
to
start
to
work
closer
together
with
the
sdk
very
soon.
C
E
C
Okay,
the
actual
sdk
will
be
like
part
of
the
auto
instrumentation
like
binaries,
like
you
will
be
like,
like
taking
a
dependency
somehow
and
like
packing.
The
sdk,
along
with
the
auto
instrumentation
bits,
is
that
how
it's
going
to
work.
F
Yes,
yes,
basically,
I
think
the
profiler
ships
with
the
set
of
binaries
and
it's
going
to
ship
with
the
dlls
of
the
sdk
of
the
exporters
and
at
runtime
we
are
going
to
inject
the
via
il
rewrite.
We
are
going
to
inject
the
sdk.
F
We
already
identified
some
scenarios
that
maybe
not
be
a
good
idea
for
the
auto
instrumentation
to
insert
the
sdk,
so
we
will
keep
also
as
an
option
for
the
the
application
to
the
application
itself,
bootstrap
the
sdk,
but
we
still
can
add
the
instrumentation
using
the
open,
telemetry
api.
In
this
case.
C
F
F
Client
is
a
good
example
that
we
played
and
we
have
something
for
auto
instrumentation
tool,
but
in
general
we
prefer
the
the
instrumentation
that
comes
from
from
the
sdk
because
is
easier
to
maintain
and
in
general
the
performance
seems
a
little
bit
better,
not
much,
but
a
little
bit
better
and
that
is
kind
of
less
intrusive
because
you
don't
need
to
do
ir
rewrite.
F
So
the
preference
in
general
is
for
that.
But
there
will
be
still
a
lot
of
scenarios
that
we
still
need
to
rewrite
the
il
for
something
that
doesn't
have
the
hooks
to
create
the
instrumentation.
C
Okay,
so
it
would
be
like
generally
safe
to
say
that
for
those
libraries
which
allow
which
already
publish
this
diagnostic
listening
diagnostic
listener
events
and
for
which
there
exist
instrumentation
in
the
sdk
repo,
you
would
quite
likely
pick
that
approach
and
for
those
things
which
do
not
provide
it.
You
you'll
use
a
I'll
rewrite
or
some
approach
to
like
get
into
the
actual
library
and
start
emitting.
These
events
themselves.
F
C
Exactly
okay,
that's
that's
correct!
Okay
yeah,
so
it
looks
like
like
like
sometime
in
the
near
future,
like
we
would
be
having
like
much
more
closer
collaboration
because
it
felt
like
I
mean
at
least
it
felt
for
many
in
the
maintenance
meeting
that
these
two
are
like
too
seemingly
independent
effort,
because
there
was
no
direct
dependency
yeah
but
good
to
know
that,
like
you
have
a
poc
already
where
you
will
be
taking
the
sdk
from
this
repo
and
other
instrumentations
yeah
yeah,
okay,
yeah.
C
One
question,
I
think
maybe
like
some
of
my
teammates
are
also
facing
like.
Would
you
support
the
scenario
where,
like
the
user,
application
is,
let's
say
instrumented
already
with
opentelemetry.net
sdk
like
they
are
bringing
their
own
version
of
the
sdk
and
exporter
and
would
auto
instrumentation
just
like
like
replace
that
with
the
one
it
brings
or
use
the
one
which
user
brings?
How?
How
does
that
scenario
go
or
is
it
not
supported.
F
That's
the
the
scenario
that
you
are
planning
for.
That
case
is
to
have
a
configuration
to
tell
us
that
download,
because
the
application
is
going
to
build
the
sd
bring
the
sdk.
F
What
is
not
clear,
a
hundred
percent,
but
I
think,
should
not
be
a
problem,
because
if
they
are
building
they
bring
in
the
sdk,
they
are
bringing
the
api
to
yes.
So
so
then,
even
the
auto
instrumentation
can
work
with
that.
Even
because
then
we
are
not
going
to
load
anything
and
we
are
going
to
rely
on
the
version
that
comes
with
the
application.
F
So
that
should
be
a
supported
scenario
without
problem.
C
Okay,
okay,
got
it
yeah.
I
think
there
were
like
couple
of
questions
which
we
are
asked
in
the
maintenance
meeting
about
one
specific
scenario:
what's
not
normally
just
like
bringing
the
sdk
like
what
if
the
user
has
written
some
span,
processors
or
activity,
processors,
which
is
a
sdk
interface,
and
they
enable
the
auto
instrumentation.
C
So
would
we
like
respect
those
processors
or
like
we
just
like
ignore
all
those
things?
There
were
like
some
questions,
which
I
I
did
not
have
any
answer
on.
How
dotnet
is
he's
like
trying
to
approach
that
it
looks
like
like
java
has
sold
it
like
somewhat
trust
me
mentioned
that
like
it
would
be
like
working
better
in
1.3.
Like
I
don't
know
like
specifics,
but
yeah,
it
looks
like
you
already
have
like
for
about
these
problems
so
yeah.
C
It
would
be
better
if
you
have
like,
as
we
start
integrating
this
better,
and
you
can
maybe
like
think
about
like
this
problem,
a
little
bit
more
because
there
might
be
some
folks
from
microsoft
who
are
interested
interested
in
this
aspect
as
well.
C
Don't
see
anyone
working
on
that
today
in
this
courier,
maybe
I
can
ask
them
like
if
I
did
hear
that
they
have
some
interest.
So
maybe
they
plan
to
join
the
instrumentation
sometime
this
week
or
next
week
and
or
reach
out
to
you
directly
or
it's
like.
C
Yeah
this
is
yesterday
yeah
the
monday
morning.
One
yeah
I
mean
it's
not
like
I
mean
it's
just
that
like.
I
was
not
really
aware
of
what
was
going
on
in
your
instrumentation,
and
there
was
no
one
to
ask
at
that
time.
So
it's
totally
fine
to
like
share
an
offline
update
here
or
like
we
can
put
it
in
the
next
week's
update
yeah.
It's
just
like.
C
I
think
ted
was
asking
out
of
curiosity
like
how
we
say
how
is
these
two
related
sigs
moving
forward,
because
for
java
it
was
like
almost
like,
like
in
sync,
with
each
other,
like
one
is
using
other,
but
at
least
we
probably
showed
an
update
like
few
months
back
that
the
auto
instrumentation
was
not
used
in
the
sdk
and
people
were
curious,
like
is
that
still
the
case
or
not
so
yeah?
C
I
can't
share
that
update
if
asked
again
in
the
next
maintenance
meeting,
all
right,
yeah,
so
we'll
try
to
like
by
default,
like
we're
trying
to
say
mentioned
earlier,
we're
trying
to
like
release.
1.1
like
there
are
like
some
critical
pr's,
which
we
need
in
along
with
metric
for
so
by
default.
We
don't
have
anything
like
this
in
our
top
priority,
but
if
it
helps
the
instrumentation,
please
bring
it
up,
so
we
can
reprioritize
them
or
if
you
want
to
submit
pr
that
also
works
all
right.
Thank
you.
C
Victor
has
an
ask
to
review.
I'm
sorry
victor!
I
did
not
get
time
last
week
so
this
week
I
should
have
plenty
of
time
to
go
over
this
vr
and
share
my
feedback
victor.
Do
you
have
like
anything
to
discuss
right
now,
like
we
have
like
many
folks
here?
So
if
you
want,
I
can
open
the
pr
and
maybe
discuss
anything
if
you
want.
G
E
G
E
G
Choice,
a
or
choice
b
that
kind
of
thing
please
chime
in
as
well,
okay,
so
this
data
point
is
the
thing.
G
If
you,
if
you're
clicking
to
it,
you
can
see
that
in
the
metric
aggregator
there's
some
interfaces
down
there
so
like
take
that
like
take
the
gauge
metric
or
something
okay,
let
me
try
to
open
one
off
right
there.
C
And
we
also
have
a
console
exporter
which
just
jumps
into
the
guns:
okay
yeah-
I
will
go
over
it,
but
if
there
like
any
feedback
or
comments
which
we
want
to
discuss
right
now,
I'm
happy
to
take
it.
Otherwise
we
just
use
the
pr.
Maybe
alan
once
has
some
comments.
C
A
A
I
was
just
kind
of
basically
asking
about
this
collection
interval
thing
and
the
way
that
you
currently
have
it
structured
and
poking
at
the
idea
of
you
know,
is
the
collection
interval
really
tied
to
the
exporter,
or
is
it
external
and
and
you're
making
a
case
for
it
being?
You
know,
outside
of
the
exporter,
which
I
think
makes
sense
to
me.
But
again
I
I'm
still
kind
of
like
trying
to
get
my
head
around
where
the
collection
interval
rests
within
the
pipeline.
A
G
What
they
export
is
otlp
protocol
and
that's
the
metric
definition
that
we're
trying
to
define
here
and
the
metric
definition
for
any
of
this
data
set
involves
having
a
time
range
of
here's,
a
sum
from
t1
to
t2.
But
if
you
have
exporters
with
different
frequency,
then
they
cannot
easily
share
that
same
data
set.
So
if
you
took
the
data
from
let's
say
the
exporter,
that's
outputting
every
minute
that
will
just
output
one
minute
two
minute
three
minute.
G
So
that's
the
crux
of
the
problem,
so
the
choice
that
we're
making
or
that
I'm
making
at
the
moment
is
to
say:
if
I
tied
the
exporter
period
or
the
exporter
frequency
to
the
same
collection,
frequency
right,
then
then
then
I
wouldn't
have
that
problem.
And
to
do
that,
I
have
to
create
an
instance
of
the
aggregator
for
the
one
minute
interval
and
an
instance
of
the
aggregator
for
the
60-minute
interval.
G
C
I
mean
I
don't
have
enough
knowledge
to
say
whether
it's
a
bad
idea
or
not
it,
but
it
sounds
like
you
are
in
the
right
path,
but
okay.
So
what
exactly
is
the
term
collection
really
means?
Is
it
taking
a
snapshot
of
the
aggregator.
G
So
at
the
moment
when,
when
we
have
a
collection
interval,
the
collection
will
will
call
all
the
observable
cap.
All.
G
Okay
and
then
let
that
let
all
of
those
value
be
aggregated
and
then
do
an
export
from
those
aggregated
values.
C
Collection,
that's
correct,
okay
and
like
at
least
as
per
this
pr,
that
collection
interval
would
match
the
export
interval.
So
if
the
collection
interval
is
let's
say
one
minute,
you
call
the
exporter.export
every
one
minute,
that's
correct
whether
exporter
instantly
disposes
it
to
its
back
end
or
keeps
it
for
further
aggregation.
That's
up
to
the
exporter.
C
Yeah,
you
can
see
like
it's
fairly
complex,
so
I
I
might
take
more
time
to
review
it,
but
still
like
we
should
be
able
to
progress
much
more
faster
than
the
main
repo,
because
it's
still
in
the
private
branch
as
a
matrix
branch.
So
we
have
like
more
opportunity
to
like
revisiting.
C
A
Is
the
is
the
term
collection
interval?
The
term
that's
been
settled
on
with
the
sdk.
G
Yeah,
so
so
I
think
the
the
terms
that
yes
naming
is
hard,
so
we
could
change
the
name
into
whatever.
I
think
that
the,
if
you
were
just
through
this
out
on
the
wall,
I
think
collection
interval
is
one.
I
think.
Export
interval
is
another
word
that
people
have
chosen
to
use,
and
so
I
think
from
from
looking
at
it,
I,
the
previous
sdk,
did
not
have
the
notion
of
export
interval,
because
the
previous
sdk
had
those
two
tied
as
well
so
and
all
we
had
was
a
collection
interval.
C
A
C
And
may
also
ask
like:
why
do
we
need
to
have
this
collection
being
separate
from
observation
like
I
was
assuming
that
whenever
we
are
collecting,
we
do
the
we
call
all
the
observable
instruments,
dot
observe
as
well.
So
is
there
a
use
case
for
having
it
separately,
it
looks
like
you
have
to
like,
like
parallel
threads
running
one
for
doing
production,
one
for
coding,
the
observation.
So
can
you
explain?
C
I
mean
I
don't
know
whether
anyone
else
find
this
interesting,
but
these
are
things
which
I
could
do
some
help
understanding
like
what
victory
is
like
trying
to
achieve.
So
it
will
help
with
the
review
as
well.
G
Yeah,
so
in
this
case
it
was
just
a
cos
toss
of
the
coin,
so
we
we
could
combine
the
two
if
we
want
okay,
okay,.
C
I
think,
like
it's
probably
mentioned
in
the
spec,
that
the
observation
will
be
like:
if
there
is
an
observable
instrument,
it
will
be
called
once
in
the
collection
interval
so
which
kind
of
indicates
they
are
the
same
thing.
There
is
no
way
you
can
like
have
a
different
observation
period
for
a
instrument.
C
Okay,
yeah.
That
gives
me
like
some
good
overview.
I
I
just
started
looking
at
it
like
a
few
minutes
before
so
I'll.
Continue
with
this
and
share
more
feedback.
C
We
we
still
have
the
here
from
michael,
that's,
probably
the
most
critical
one,
because
we
need
to
ship
that
before
1.1.
So
I
like
encourage
if
anyone
else
has
time.
Please
share
your
thoughts.
I
would
be
looking
at
this
as
well.
So
basically,
we
are
trying
to
move
the
thing
which,
which
we
use
for
building
the
hosting
package
from
sdk
to
apa,
so
that
the
instrumentations
need
not
take
a
sdk
dependency
just
to
support
the
configuration
part
of
it.
C
That's
the
like
gist
of
this
thing,
but
everything
else
is
like
a
smart
way
of
like
implementing
michael,
like
is
there
anything
you
want
to
like,
like
today,
feedback
from
more
folks
or
can
wait
for
actual
review.
H
H
C
Okay,
so,
even
if
just
to
summarize,
even
if
we
decide
to
take
a
dependency
on,
I
service
collection,
the
package
from
microsoft,
it
could
only
be
a
conditional
dependence
like
it
will
only
be
for
like
an
extended
2o
and
higher.
We.
H
Could
do
that
for
sure,
but
then
it
would
kind
of
exasperate
the
issue
we
have
with
any
time.
We
do
that
conditional
targeting
we're
introducing
downstream
problems
where
people
are
compiling
against
one
api
service
and
then
at
run
time
they
get
a
different
one.
So
it's
it's
just
going
to
be
more
of
that
issue.
If
we
go
that
route.
C
H
About
I
see,
there's
some
work
being
done
right
now
on
service
collection
by
david
fowler.
I
was
gonna,
just
throw
a
mention
out
there
and
say:
hey.
Is
there
any
way
you
could
drop
in
the
452
target
for
us,
but
I
doubt
they're
going
to
want
to
do
that
because
it's
not
really
supported,
but
on
the
same
side
of
that,
why
are
we
being
more
supportive
than
the
net
runtime?
C
Yeah,
I
think
this
was
discussed
like
sometime
back.
The
conclusion
at
that
time
was
like
this
is
probably
like
way
before.
I
joined
the
sig,
but
I
remember
reading
the
notes
that
I
mean
as
long
as
microsoft
supports
dotnet
452.
We
should
support
it,
but
what
you
said
is
true,
like
even
microsoft's
internal
things
or
like
dot
nets.
Things
like
I
logger
doesn't
support
net.
Four
five
do
so
we
shouldn't
be
really
supporting.
That
was
the
counter
argument,
but
I
still
think
like
net
452
fox
won
the
argument
or
debate.
C
At
that
time
we
decided.
Okay,
we'll
have
all
the
support
for
microsoft,
supported
versionsoft.net,
but
yeah
I
mean,
I
don't
think
everyone
thought
about
the
problems
which
we
faced
today
when
we
made
that
decision
when
whoever
made
that
decision
at
that
day.
So
let's
do
this
thing
like.
Let's
give
like
everyone
like
like
another
opportunity
to
review
this
pr.
Like
michael
already
mentioned
the
like
tradeoffs
we
are
making,
we
are
pretty
much
re-implementing
something
to
our
taking
a
dependency.
C
So,
even
if
we
take
a
dependency,
it
will
still
be
like
not
free
to
have
like
some
other
issues
as
well
about
the
like,
multiple,
like.
If
a
shared
library
uses
different
target
framework
than
the
final
application,
then
like
we
could
get
into
like
method,
missing
exceptions,
kind
of
thing.
So,
let's
give
like
everyone
like
another
week
to
think
about
this,
and
maybe
like
next
week
we
can
see
if
it's
a
community,
we
want
to
make
the
decision.
C
Okay,
let's
either
drop
support,
fortnite452
or
we
do
take
it
or
we
make
the
decision
to
take
a
dependency,
on
extension,
start
di
dot
abstractions,
but
do
that
conditionally
and
then
reach
out
to
guidance
from
dotnet
team?
Okay,
we
have
this
program
where
we
cannot
really
offer
the
same
api
for
multiple
targets
and
at
this
point
like
that,
they
are
working
on
tools
which
will
help
us
identify
these
issues
and
we
can
reach
out
to
them
hey.
C
This
is
the
current
situation
we
are,
and
there
is
no
way
we
can
have
the
same
api
in
the
both
targets,
because
that
package
simply
don't
exist
and
see
if
they
have
any
better
guidance
than
what
we
are
trying
to
do
here,
maybe
like.
C
If
they
would
follow
a
resurrect
person,
we
can
try
to
poke
him
and
see
if
they
can
do
some
help
here,
because
they
really
spend
like
108
on
ta,
and
they
might
have
some
like
some
suggestions,
or
at
least
we
even
if
you,
even
if
the
suggestion
is
not
perfect.
At
least
we
know
that
it
is
like
blessed
by
the
dotnet
team,
so
we
are
not
really
making
any
one-off
decisions
for
open,
telemetry,
whatever
we
do
will
be
in
line
with
what
dotnet
is
recommending.
C
So
let's
come
back
to
it,
but
so
I
just
want
to
ask
everyone
like
to
take
a
look
at
this
pr,
because
it
solves
an
important
problem
we
have.
At
the
same
time,
we
want
to
decide
what
is
a
whether
this
is
the
right
approach,
or
should
we
take
alternate
approaches
and
pay
them
against
the
pros
and
cons?
We
can
do
use
next
week
as
a
like
opportunity
for
everyone
to
together
and
make
a
decision
like.
C
Are
we
taking
a
dependency
or
not,
or
are
we
cutting
support
of
one
of
the
tournament
frameworks
just
to
keep
things
simpler?
Okay,
I'll
put
this
into
like
top
of
the
agenda
next
week,
so
we'll
take
it
as
the
first
thing.
E
C
The
update
about
the
next
release,
like
we
not
wait
for
this
pr
to
be
merged
before
the
next
one,
because
we
just
want
to
do
a
quick
release
to
unblock
instrumentations
which
were
broken
by
the
beta2
to
beta3
change.
C
So
I
will
try
to
do
the
release
along
with
the
just
to
get
like
another
people
from
another
person
like
really
familiar
with
the
release
process
of
the
main
sdk.
So
that
would
make
a
second.
I
think
I
don't
think
like
alain.
You
have
never
done
the
release
from
this
report.
Maybe
like
next
time
I
work
with
you
and
see.
If
you
can
follow
the
instruction
I
have
because
I
want
to
make
sure
like
I'm,
not
the
only
one
who
knows
or
who
can
do
the
actual
release.
C
So
I
have
the
process
documented
here.
C
Sorry,
it
should
be
built
releasing
so
for
today's
or
tomorrow's
release,
I'll
ask
utkarsh
to
work
with
me
to
follow
the
process
and
see
if
it
makes
sense
like
maybe
like
after
that,
we
can
use
someone
to
like
really
scriptify
this,
so
that
it
can
be
done
from
github
actions
directly,
and
that
should
like
remove
the
dependency
on
me
due
to
all
the
releases.
C
But
there
is
constant
ask
people
begging
to
release
things
from
the
main
ripper
as
well
and
the
contour
paper,
and
given
that
there
is
still
like
some
manual
steps
involved.
It's
always
like
a
pinpoint.
So
if
you
get
to
that
stage
where
everything
is
automated,
that
would
ease
some
of
the
being.
This
way.
A
C
So
I
think
we
we
can
like
use
you
for
the
next
beta
release,
not
the
one
which
we
plan
tomorrow.
I
want
to
give
like
utkarsh
a
chance
to
taste
what
it
is
to
do
an
actual
release
like,
but
we
will
definitely
have
one
more
beta
before
we
call
one
dot
one
stable.
So
at
that
time
we
can
work
together
and
do
the
release.
C
So
maybe
that
that
means
like
at
least
three
people
have
gone
through
the
actual
process,
so
we
should
be
like
relatively
safe
in
case
I'm
like
going
for
a
longer
vacation
or
something
I
don't
plan
to,
but
just
in
case
so
alan
you
had
some
comment
about
this
one.
Can
you
summaries?
A
We
can
discuss
yeah
for
sure
yeah.
I
put
this
out
here
a
while
ago
and
actually
presented
at
one
of
the
sig
meetings
a
couple
months
back.
It's
not
a
massive
priority.
In
my
mind,
though,
it
has
gotten
some
kind
of
excitement
on
it
recently.
Some
comments
kind
of
wondering
when
it
when
it
could
go
out-
and
you
know
one
of
the
big
questions
was:
how
can
we
release
this
right
now,
given
that
logs
in
open
telemetry
have
not
yet.
E
A
Deemed
stable,
you
know
we
can't
necessarily
ship
it
as
part
of
our
open,
telemetry
protocol
exporter
package,
at
least
today,
or
at
least
I
believe,
that's
still
true,
but
having
seen
michael's
solid
work
with
that
contrib
preview
package,
it
made
me
question
whether
maybe
that's
a
decent
home
for
it
in
the
near
term.
C
So
we
basically
have
a
new,
I
mean
same
package
that
preview
package,
but
it
contains
a
otlp
log
exporter,
along
with
the
extension
methods
required
to
enable
it
and
once
we
once
we
or
the
spec
marks
the
logging
specs
table,
then
we
can
promote
that
from
the
preview
to
the
main
package,
of
course,
with
some
namespace
changes.
C
But
that
would
be
it
like
that.
That's
what
you
were
like
asking
right.
C
A
You
know
on
the
pr
I
had
originally
posed
some
questions
of.
Like
you
know,
maybe
we
just
have
a
a
second
package
in
the
main
repo
for
now.
That's
just
you
know
open
telemetry
protocol
exporter.logs
or
something
so
that's,
I
suppose,
still
another
route
we
could
go.
But
if,
if
we
think
we're
gonna
leverage
the
preview
package
more,
then
I
I
think
maybe
going
with
that
convention
might
be
nice.
I
mean
I
like
the
idea
of
this
preview
package.
C
Okay,
it's
nice
idea!
I
don't
see
any
I
mean
unless
anyone
objects
like,
I
think,
that's
a
good
route
for
us
to
try
like
several
people
were
asking
like.
I
was
actually
like
about
to
ask
like
ellen,
like
you
said
something
like
a
priority
for
you
last
week,
then
some
folks
ask
me
it's
like
channel
hey.
Are
you
planning
to
release
this
one
soon?
We
really
want
to
use
it,
but
because
people
who
are
asking
okay,
this
otlp
was
marked
like
from
alpha
to
beta.
C
So
that's
a
like
big
jump
for
log,
so
it
would
be
like
relatively
safe
to
now
start
working
on
it.
It's
it's
not
really
a
waste
of
time,
because
it's
like
marked
as
beta,
so
it
should
be
like
much
more
stable.
Now.
A
Yeah,
I
think
it's
I
mean,
I
think
it's
in
a
pretty
good.
It's
in
a
usable
state.
I
mean
I've
tested
it
out.
I
haven't
had
any
tests
yet,
but
I
can
the
other
thing
is
you
know,
michael
having
reviewed
your
work.
I
actually
think
that
this
could
benefit
from
the
the
the
scope
and
the
state
formatting
functions
that
you
have
currently
in
the
preview
repository.
A
C
It's
I'm
pretty
sure
like
as
soon
as
we
ship
it
like
people
who
are
using
eye
logo
they'll,
definitely
come
and
ask
okay.
How
do
I,
how
do
you
or
why
are
you
not
exporting
my
scopes,
because
people
who
use
I
logger
have
like
gotten
used
to
adding
scopes?
That's
the
way
to
interesting,
so
they
will
definitely
ask
even
in
internal
microsoft.
C
People
are
like
already
asking
okay.
Why
don't
you
support
logs?
I
mean
you
only
support
a
logger,
but
why
don't
you
support
scope
so
yeah?
It
would
be
cool
if
you
can
get
that
into
the
preview,
along
with
support
for
the
scope
system.
I
think.
E
C
Did
the
console
exporter
recently
just
modified
as
a
proof
of
concept
like
console
exporter
right
now
supports
scope,
c
file
number
correctly
and
don't
record
exporter
state
values,
formatted
message:
yeah,
we
do
deal
with
the
scope
we
just
printed
to
them
so
yeah.
So
there
is
like
reference
in
case
you
want
or
you
can
use
the
yeah.
I
mean
if
you
are
using
the
preview
package.
It
already
has
like
similar
examples
on
how
do
we
translate
that
scope
into
actual
attributes?
C
Okay?
So
if
there
are
no
objection,
I
like
take
it
that
we
want
to
like
ship
the
otlp
log
exporter
as
part
of
the
contract
preview
package.
C
Okay,
yeah-
that's
pretty
much.
It
then
like
we'll
see
again
next
week,
so
please
do
try
to
review
this
vr
like
because
we'll
do
some
time
discussing
next
week
about
what
we
earlier
mentioned
about
the
default
tracer
provider
pr.