►
From YouTube: 2020-12-15 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
A
B
C
D
B
B
B
Okay,
sorry,
for
being
late,
I
was
just
in
a
different
meeting
which
just
got
over
yeah.
It
looks
like
there
is
no
other
agenda
items
other
than
the
one
which
I
just
put:
okay,
yeah
yeah.
So
we
can
go
over
the
agenda
item.
So
one
important
update
about
the
releasing
strategies
we
do
have
overall
versioning
strategy
for
open,
telemetry
almost
merged.
B
B
But
let's
see
if
it
has
yeah,
it
looks
like
it
has
enough
approval,
so
it
should
get
merged.
Hopefully
today,
and
then
we
can
like
I
mean
it,
won't
be
a
spec
immediately,
it
will
be
like
merged
into
spec,
even
after,
like
the
otter
piece
table.
So
what
that
really
means
is.
We
should
have
a
green
light
to
go
1.0
in
the
next
couple
of
weeks,
whether
we
should
do
1.0
like
like
in
one
week
or
two.
B
So
that's
the
update,
but
irrespective
of
that,
irrespective
of
the
exact
date,
we
should
still
proceed
with
releasing
the
next
rc2
or
next
release
candidate,
because
we
had
like
several
pr's
which
were
merged
in
the
last
two
weeks,
so
people
are
waiting
to
get
a
hold
of
that
so
I'll
proceed
and
release
rc2.
B
But
there
was
like
few
open
questions
which
was
made
when
we
did
the
versioning
exercise
for
top
notch.
So
let
me
go
over
them
today
and
okay,
it's
a
request.
B
Yeah,
so
the
key
thing
which
we
we
are
proposing
to
change
is
extracting
the
metrics
out
into
a
separate
package,
and
what
do
we
do
with
the
logging
signal?
So
those
were
the
two
things
which
are
not
really
clear.
B
So
let's
spend
like
a
couple
of
minutes
just
to
see
if
there
are
any
concerns
or
questions
with
this
approach,
I
will
be
like
doing
another
exercise
to
see
what
does
it
mean
by
shipping
or
extracting
metrics
into
its
own
package,
because
it's
not
trivial,
I
mean
extracting,
is
trivial,
but
then
it's
a
separate
package
with
a
separate
package
version,
because
so
far
every
package
from
this
repo
is
released
as
a
exact
same
version.
B
So
now
we
need
to
change
our
infra
so
that
we
can
shift
something
separately
and
then
I
need
to
actually
try
out
this
little
bit
more
because
to
prove
that
this
does
not
create
any
other
unintended
issues.
B
But
I
just
want
to
hear
like
if
there
are
any
thoughts
on
continuing
the
current
approach,
as
opposed
to
using
this
approach,
but
from
a
parameter
standpoint,
it
looks
like
most
are:
okay
with
either
approach.
It's
just
that,
like
java
python
and
pretty
much
every
other
language
is
going
with
approach
to
where
anything
experimental
is
extracted
into
a
separate
package
does
not
mean
we
have
to,
but
if
there
is
a
strong
reason,
I
think
we
can
do
it.
B
So
if
there
are
any
questions
or
concerns,
we
can
discuss
it.
Otherwise,
I,
what
I
plan
to
do
is
like
list
down
the
exact
steps
or
listed
on
the
plan
of
action
of
how
do
we
extract
metrics
into
separate
apa
and
what
would
happen
when
we
like
bring
the
original
metrics
into
the
actual
original
package
itself?
B
I
mean
I
did
mention
that
in
here,
like
very
briefly,
they'll
simply
remove
the
experimental
package
and
update,
but
we
need
to
do
an
actual
exercise
to
see
how
that
work,
whether
we
have
any
conflicts
or
things
like
I
mean
one
thing
which
was
which
is
potentially
an
issue,
is
the
current
matrix
code
requires
sdk
dot
create
provider.
B
So
there
is
some
dependency
on,
even
if
we
extract
it
into
a
separate
package.
It
has
a
dependency
on
the
main
package
and
the
sdk
cut.
So
I
mean
sdks
and
there's
an
sdk
class
which
we
use
to
create
provider.
So
when
we
keep
releasing
more
and
more
metrics,
do
we
need
to
keep
them
in
sync,
with
a
newer
version
of
open
telemetry?
B
I
don't
know
yet
because,
like
I
think,
like
in
parallel
will
be
really
like
once
the
matrix
is
stable,
we'll
be
adding
them.
Should
we
be
adding
them
in
parallel
to
both
the
experimental
and
the
stable
or
we
just
keep
adding
it
only
to
this
package
and
only
in
the
final
release.
We
move
everything
into
stable,
so
some
logistic
challenges.
I
need
to
like
list
it
down
so
that
everyone
get
a
chance
of
like
commenting
at
this
stage.
It
looks
very
easy,
but
I'm
pretty
sure
like
once
I
write
it
down.
B
There
will
be
more
so
yeah
any
questions
on
this
part
I'll
come
to
logs
next,
but
that's
fine.
D
B
I
mean
we
have
to
first
do
the
homework
for
that,
because,
right
now
it's
going
to
have
the
same
package
for
all
the
packages
like
everything
shipped
from
the
repo
will
have
the
exact
same
package
number.
So
we
need
to
do
some
like
build
changes
so
that
individual
packages
can
override
the
version,
but
conceptually
what
you
said
is
what
we
intend
to
do.
If
we
go
with
approach
to,
of
course,
I
mean
we
need
to
fix
the
build
builds
so
that
we
have
the
ability
to
overrate.
A
Just
a
note
about
that,
I
I
haven't
played
around
with
it,
but
minver,
I
believe,
is
what
we're
using
diversion
packages
from
this
repository
and
in
it
I've
seen
in
the
documentation
that
it
has
some
ability
to
prefix
a
tag
with
something
and
you
can
have
different
packages,
have
different
tag,
prefixes
that
they
read
their
version.
Information
from.
B
Yeah
I
mean
this
is
purely
something
which
I
have
no
idea.
How,
meanwhile
works
I'll
reach
out
to
eddie
and
figure
out
how
to
do
that?
B
It's
currently
working
as
a
like
from
the
meanwhile
like,
which
is
basically
looking
at
the
git
tag
whenever
we
push
a
new
tag
and
count
the
number
of
commits
afterwards
and
like
the
package
name
would
be
whatever
is
the
latest
tag,
name
plus
a
number
which
would
match
the
number
of
commits
since
the
tag
like
something
like
that,
but
it
is
a
like
applicable
to
the
whole
project.
I
think
it's
inheriting
from
like
the
comments,
but
I
think
I
can
figure
out
like
with
the
help
of
eddie.
B
How
do
we
achieve
the
like,
separate
versioning?
We
can
definitely
reach
out
to
ellen,
like
hoover,
is
an
expert
in
this
video,
but
that
is
purely
like,
like
logistics,
how
do
we
release
it,
but
from
a
conceptual
perception
like?
Are
we
all
good
with
this
approach?
I
mean,
of
course
I
need
to
do
some
more
like
detailing
on
how
this
would
work,
but
any
other
concerns
or
any
any
alternate
like
any
approach.
Three.
D
One
other
thought
I
had
like
if,
if
we
wanted
to
like
that,
would
still
allow
releasing
metrics
without
releasing
open
telemetry
right.
If
there's
like
some
changes,
because
it's
evolving,
faster
or
whatnot
like
making
new
versions
of
just
one
of
the
package,
instead
of
entire
repository,
that
would
still
work
right.
B
Yeah,
it
should
work,
but
from
the
the
way
currently
the
build
system
works
is
it.
We
don't
need
to
do
any
manual
work
for
individual
packages.
We
just
push
a
tag
and
qa
build
and
we
get
all
the
new
get
packages
and
we
just
push
it.
So,
even
if
let's
say
that
we
go
with
approach
2
and
we
have
one
open
elementary
package
and
there
is
a
separate
open
elementary
matrix.
Let's
say
we
made
more
changes
here.
We
can
release
all
of
them
together.
It's
it's
still.
B
Fine,
I
mean,
let's
say
we
release
one
dot,
o
dot,
two
of
open
elementary.
It
can
contain
the
exact
same
code
as
the
previous
version.
B
The
like,
I
don't
think
the
question
I
mean
you.
The
point
you
raised
was
about
like
how
do
we
handle
different
velocity
of
release
for
individual
components?
Yes,
yeah.
I
think
it
should
be
possible
to
handle
that,
because,
like
around
eighty
percent
of
the
release
is
automated,
you
like
kick
off
a
tag,
I
mean
push
a
tag
and
then
it
creates
the
packages
and
then
the
last
step,
which
is
to
upload
the
package
in
your
nougat.
B
That
is
something
which
I
do
manually,
so
it
should
be
possible
for
us
to
mean
there
is
no
extra
amount
of
work
if
there
are
like
10
packages
of
20
packages,
because
it's
all
scripted.
B
I
see
yeah,
so
we
haven't
had
such
situation
because
we
generally
block
the
pr
from
being
merged.
If
you
are
near
a
release
deadline,
that's
what
we
were
doing
so
far,
but
it
looks
like
you
you're
right
lucky.
If
you
have
something
already
merged,
we
are
not
yet
ready
to
release,
but
we
have
a
pressing
need
to
release
something
from
metrics.
Then,
yes,
we
have
this
issue,
but
yeah.
B
B
It's
all
doable.
It's
just
that
and
like
I
feel
like.
If
there
is
any
approach
three
which
we
haven't
thought
about,
or
we
should
still
stick
with
approach,
one
which
is
using
the
absolute
marking,
so
our
main
package
would
still
contain
matrix,
as
is
with
all
the
rc,
all
the
absolute
tags,
and
then
even
there.
We
have
to
really
list
on
the
exact
steps
involved
when
we
actually
release
the
like
actual
metrics.
B
So
I'm
thinking
like
most
people
are
inclined
towards
approach
to
it's,
just
that
I
have
to
like
list
on
the
exact
steps
to
get
a
final
final
approval
from
like
multiple
folks
before
we
merge
it
and
proceed
with
this
change.
You
don't
want
to
rush
into
approach
to
like
today
and
then
later
realize
that,
oh
sorry,
we
didn't
think
about
it.
So
I'm
going
to
like
delete
little
bit
more,
which
means
when
we
do
our
c2,
we'll
still
be
like
status.
Q,
which
is
matrix,
will
still
be
part
of
rc2.
B
It
will
be
absolute
and
we
already
made
it
clear
that,
like
we
can
release
any
number
of
rc2s
with
no
guarantees
on
the
api.
So
we
should
have
enough
enough
iterations
to
figure
it
out
and
if
we
come
up
with
finally
conclude
that
approach
to
his
right,
we
should
still
be
able
to
do
it
even
after
rc2
or
c3.
A
That
I
I
haven't
put
this
on
the
pr
yet,
but
I
meant
to
the
so
at
some
point.
I
want
to
come
back
and
work
on
the
pr
that
I
still
have
out
there
as
a
draft
for
capturing
metrics
for
asp.net
core
and
that
right
now,
of
course,
is
implemented
as
part
of
just
the
instrumentation
that
we
maintain
in
the
root
repo.
B
Yes,
that
would
be
same.
It
would
be
same
for
even
the
exporter,
the
prometheus
exporter.
That
would
also
be
like,
like
separately
versioned,
matching
the
matrix
version.
So
if
you
have
a
asp.net
core
matrix
instrumentation,
then
it
has
to
be
like.
Currently
it
is
the
same
instrumentation
like
it's
doing
the
tracing
and
metrics
together,
assuming
islands
pr
is
merged,
but
if
it
is
going
to
depend
on
a
different
package,
then
you
want
to
split
it
because
the
tracing
part
is
stable.
It
should
not
be
allowed
to
take
it.
B
I
mean
I
think
nuget
will
prevent
us
from
taking
a
dependency
on
another
package,
so
that
would
force
us
to
split
the
asp.net
core
instrumentation
into
two
one
for
trace
and
matrix,
and
when
things
are
back
to
like
single
package,
we'll
have
to
merge
it
back
yeah,
it's
a
good
call
yeah.
These
are
the
things
which
I
want
to
like
yeah
write
it
down
like
step
by
step.
What
are
the
issues
yeah
I
mean
from
the
high
level
perspective.
B
I
think
every
language
is
doing
this
and
it
looks
very
neat
because
we
are
not
polluting
the
one
but
like
the
actual
logistic.
If
it
is
too
much,
then
we'll
have
to
like
think
of
an
alternate
but
yeah
whatever
we
do
here
like
it
would
be.
It
should
be
like
really
thought
through,
because
allen
just
brought
up
a
new
point,
which
I
haven't
really
thought
before.
How
do
we
deal
with
instrumentations.
B
Yeah,
so
what
I
can
do
is
I
I'll
like
create
like
leave
this
pr,
as
is
now
and
like
create
a
separate
issue
just
to
discuss
the
logistics
of
how
do
we
deal
because
right
now
we
have
already
approached
one
is
already
done
so
we'll
proceed
with
approach
1
for
rc2,
because
we
don't
want
to
delay
rc
2
any
further
and
then
open
a
separate
issue
just
to
focus
on
like
the
logistics
like.
B
How
would
I
mean
that
new
issue
will
just
list
down
the
exact
thing
which
would
happen
between
these
two
releases,
like
between
these
five
releases?
I
would
say
so,
then
we
can
like
play
with
all
the
same
areas.
What
do
we
do
with
instrumentation
and
how
do
we?
What
would
be
the
customer
experience
when,
when
we
finally
say
that
metrics
are
ga?
B
So
let's
discuss
that
in
a
separate
issue,
but
we
still
can
merge
this
ascend,
so
we
can
still
merge
this
once
we
add
like
more
details
and
we
can
say
that,
for
now
we
are
taking
with
approach.
One
approach
two
is
being
discussed
in
that
separate
issue,
because
this
also
contains
other
information
about
what
is
what
does
it
mean
by
our
packaging
strategy
like
how
do
we
deal
with
like
alpha
beta
etcetera?
B
B
Yeah,
so
I
think
like
few
folds
align-
and
I
forget,
like
who
else
like
some
other
folks,
raise
concerns
about
releasing
logs
as
a
stable
package.
I've
been
thinking
about
this
for
last
few
days,
and
so
my
main
concern
is,
I
think
we
poorly
voted
the
release.
We
are
not
releasing
a
loading
api
before
the
login
api
spec
is
stable.
So
what
we
are
I
mean
the
current
code
which
we
have
in.
B
Let
me
open
that
the
current
code
we
have
for
logging
is
not
a
new
api
for
doing
logs.
So
for
that
we
are
just
referring
to
using
logger.
So
there
is
no
connection
with
open
telemetry
at
all.
If
any
customer
asks
us,
how
should
I
log?
B
B
So
I
was
thinking
irrespective
of
what
open
elementary
logging
stick
would
come
up
with
in
the
next
few
months.
We
would
still
need
to
provide
a
way
for
people
to
con
get
their.
I
logger
logs
exported
into
open
telemetry,
I
mean.
Even
if
upper
telemetry
has
a
new
brand
new
logging
api,
we
would
still
be
writing
the
equivalent
of
instrumentations
for
I
logger.
B
So
this
is
what
which
we
have
to
do.
No
matter
what
the
logging
api
proposal
would
be
from
open
telemetry.
B
So
considering
that
I
am
still
thinking,
we
should
be
able
to
not
call
this
as
experimental,
because,
no
matter
what
the
spec
comes
up
with,
we
would
still
be
forced
to
support
the
I
logger
api
I
mean,
which
is
the
default
standard
for
all
the
network
applications.
B
And
if,
if
open
elementary
says
that
there
should
be
a
concept
of
like
sampler,
then
we
should
be
able
to
add
it
because
right
now
we
do
not
have
anything
called
example
or
we
have
is
a
processing
model
which
exactly
matches
span
or
activity
world,
but
my
thinking
is.
We
should
not
be
like
blocking
log
release
or
we
should
not
be
blocking,
or
we
should
not
be
marking
log
support
as
experimental,
because
the
actual
api
side
logger,
which
we
are
not
shipping
from
this
repo,
it
is
a
stable
api
from
dotnet
itself.
B
All
we
are
shipping
is
like
an
adapter
from
my
local
to
open,
telemetry
and
anything
which
specs
comes
up
with
in
the
next
few
months.
We
would
be
able
to
make
it
like
a
teaching
there.
B
I
mean
there
shouldn't
be
anything
which
we
would
be
able
to
remember
which
we
want
to
remove
based
on
spec,
but
this
is
just
my
thought.
I
want
to
hear,
like
others,
and
one
of
the
reason
why
I
want
to
do
this
rather
sooner
is.
There
is
no
need
of
like
waiting
for
any
customer
to
use
open
elementary,
because
we
anyway
delayed
metrics
by
at
least
eight
months.
B
I
mean,
probably
even
more
because
will
only
have
a
metrics
beta
by
mid
june
and
ga
by
number
and
as
such,
the
usability
of
a
project
is
much
higher
if
logs
are
also
supported
and
in
many
exporters
the
activity,
events
or
span
events
are
converted
into
their
log
sequence,
so
people
are
already
like
somewhat
using
laws
by
using
the
activity
event
or
spine
giving
model.
B
So
I
don't
think
there
is
any
strong
reason,
but
I'm
like
what
I
just
want
to
hear
like
what
others
think
about
this
approach
as
well.
I
will
definitely
be
asking
the
open
elementary
spec
like,
and
the
maintenance
about
this
approach
as
well.
I
just
want
to
hear
from
others
like
what
are
the
major
concerns
if
we
go
with
not
marking
logs
as
experimenter.
A
I
don't
personally
have
major
concerns,
I
would
just
say
I
think
I
think
the
concerns
probably
come
from
like
open
commentary,
governance
and
and
the
spec
side,
but
I
I
hear
you
like
yeah.
If
we,
I
I'm,
I
think
I'm
with
you
as
far
as
being
pretty
confident
that
any
changes
would
be
additive,
but
I
guess
it
just
depends
on
how
conservative
we
want
to
play
that.
B
B
As
well-
but
I
want
to
hear-
like
other
others
opinion
on
this
topic-
I
mean-
is
there
any
one
here
who
has
customers?
Who
wants
to
use?
I
logger
sooner
than
later,
or
anything
like
that,
because
then
we'll
have
a
good
convincing
case
that
this
is
in
the
like
in
the
best
interest
of
the
overall
project,
because
I
I
initially
got
the
impression
that
most
people
were
assuming
that
we
are
shipping,
a
open,
telemetry
logging
api,
even
before
the
specs
were
announced
for
that.
B
B
And
if
you
look
at
the
actual
open
elementary
proposal,
the
autopsy
about
versioning,
the
apa
and
sdk
versioning
and
support
is
very
different,
like
the
api
is
expected
to
be
supported
for
at
least
three
years,
but
the
sdk
is
like
only
for
one
year,
so
this
issue
was
brought
up,
not
not
in
the
context
of
login,
because
several
people
were
concerned
that
the
tracing
sdk
we
don't
want
to
support
for
three
years,
because
there
are
already
issues
which
people
are
being
discussing,
so
they
don't
want
to
commit
that
they
will
maintain
backward
compatibility
for
three
more
years.
B
So
I'm
thinking
that
we
can
apply
the
same
logic
worst
worst
case.
What's
going
to
happen
is
we
are
not
shipping
the
logging
apa
it's
done
by
the
dotnet
team?
They
will
ensure
backward
compatibility
for
our.
We
are
only
shipping
sdk,
which
is
very
unlikely
to
change.
I
mean
we
are
very,
very
unlikely
to
introduce
breaking
change.
It
will
be
all
like
additive
changes,
but
even
if,
in
that
unlikely
event
of
producing
a
breaking
change,
we
can
do
it
exactly
one
year
from
the
stable,
but
that
is
just
the
extreme
case.
B
I
don't
anticipate
us
doing
that,
should
we
create
an
issue
like
specifically
for
log
and
like
I
mean,
if
more
folks
want
to
comment
on
it
about,
because
it
looks
like
many
people
were
unaware
that,
like
like,
I
found
like
two
sets
of
people
one
set
of
folks.
They
did
not
even
knew
that
logging
was
already
available
in
dot
net
and
second,
is
some
people
indirectly
assume
that
logan
we
are
introducing
a
new
open,
telemetry
logging
api.
B
So
I
think
the
best
thing
I
can
do
is
create
an
issue
put
a
link
here
and
in
that
describe
what
is
a
thing
which
we
are
shipping.
We
make
it
very
clear
that
we
are
introducing
no
new
api.
B
We
are
just
referring
to
I
logger
and
we
are
only
providing
a
like
connector
or
adapter
for
I
logger
into
open
element,
which
would
be
something
which
would
be
required
to
do
respective
perspective.
So
I'll,
just
like
summarize
this
in
an
issue
and
let
it
be
there
for
like
at
least
one
or
two
weeks.
So
people
have
a
ample
time
because
it's
already
december
mid.
So
I
don't
know
whether
people
are
going
to
work
in
next
few
weeks
or
not.
D
Mean
like
so
people
are
confused
between
this
being,
like
an
open,
telemetry
logging
versus
really
just
gonna
dotnet
cores,
I
logger
so
like,
maybe
in
that
separate
ticket,
we
can
separate
issue
we
can
discuss
like.
Maybe
this
can
be
renamed
to
like,
instead
of
open
primary
logs,
this
can
be
like
open
telemetry,
I
logger
adapter
or
something,
and
then
nobody
will
be
confused
about
what
it's
trying
to
do
and
then
this
can
be
stable,
because
I
locker
is
stable
right.
B
B
Just
a
name
space
within
the
sdk
package,
so
it
will
be
called
open,
elementary
load
loads
and
we
are
pretty
sure,
like
whatever
open
elementary
comes
up
with.
We
still
want
to
retain
this
name
space,
because
it
is
in
alignment
with
other
two
signals
which
are
open
elementary
dot,
matrix
and
open
elementary
dot
traces.
So
we
don't
anticipate
any
change
there.
B
So
there
is
no
separate
package
and
from
what
we,
what
we
have
really
done
is
we
wrote
a
provider
for
I
logger,
which
is
something
which
we
would
be
forced
to
do.
No
matter
what
happens
and
second
is
we
don't
even
have
any
exporter,
so
we
just
put
a
document
saying
and
you
can
ride
your
own
exporter.
You
can
write
your
own
processor,
that's
it.
B
We
are
not
shipping
any
exporters
other
than
the
in
memory
and
console
4.
So
it's
not
like.
We
are
shipping
any
elastic
search
exporter
which
theoretically
we
can,
but
we
are
just
leaving
it
openly.
If
customers
want
it
or
they
can
use
it,
I
mean
they
can
write
their
own
or
contribute
and
use
it.
So
the
packaging
issue
is
not
yet
here,
because
we
are
not
having
any
package
called
open,
elementary.logs,
but
I'll
do
like
whatever.
B
It
is
necessary
to
convey
the
message
that
we
are
not
introducing
a
new
api
which
we
are
coding
stable.
We
are
just
providing
an
adapter
for
I
logger,
which
is
a
stable
package
from
top
net
yeah.
I
mean
you
can
comment
on
the
pr
or
in
the
issue,
because
I
had
to
like
write
it
down
in
the
right
way
so
that
I
don't
mislead
anyone.
B
Okay
yeah,
so
these
two
are
the
two
important
things
which
I
want
to
discuss
so
just
to
confirm
the
plan
of
action.
I
will
keep
this
pr
open,
create
two
separate
issues
for
matrix
for
metrics.
We
are
still
discussing
like
we
agree
that
it
is
going
to
be
not
called
ga
or
1.0.
So
only
question
is:
how
do
we
achieve
that?
The
mechanism
is
it
going
to
be
a
separate
package
or
or
it
will
be
absolute
marking
or
alternate
approach
to
do
that?
B
Let
me
list
on
the
exact
steps
and
then
see
whether
which
approach
makes
most
sense
and
for
logs
the
question
is:
is
it
a
stable
or
not
stable?
If
it
is
stable,
then
it's
fine.
If
it
is
not
stable,
then
whatever
we
do
for
do
four
metrics.
We
should
go
for
all
so
again,
I'll
create
an
issue
to
get
some
more
discussions
and,
of
course
we
will
not
go
1.0
with
logs
until
the
governance
committee
and
other
technical
committee
gives
a
green
light.
B
In
the
last
two
weeks,
I
probably
have
like
two
more
working
days
and
yeah-
probably
four
working
days
this
year,
so
we'll
see
how
much
of
that
is
going
to
happen,
but
is
there
anyone
like
or
any
customer
who
are
looking
to
get
1.0
like
sooner
because
we
already
announced
it
will
be
last
week
or
the
week
before,
but
then
we
delayed
it,
but
now
we
are
delaying
it
further
for
one
to
us.
B
B
C
The
way
I've
been
representing
things
to
current
customers
who
are
interested
is,
you
know,
there's
still
an
uncertainty
going
on
with
the
you
know,
if
the
dates
basically
there
from
the
community
and
how
that's
really
going
to
play
out
and
so
like,
I,
I
think
that,
like
you
know,
in
general,
customers
are
at
this
point.
You
know,
okay,
with
you
know
a
little
bit
of
a
delay
here
and
understand
that
that's
a
you
know.
That
was
a
possibility,
at
least
from
you
know,
from
my
interactions,
yeah
and.
B
For
any
customer
who
are
like
interested
in
instrumenting,
most
of
them
are
good
to
go
with
the
diagnostic
source
package,
because
it's
already
released
as
ga
unless
they
need
the
propagation
api,
they
don't
have
any
reason
to
use
the
anything
from
open
elementary
for
instrumentation,
like
if
you're
a
library
other
or
even
if
you
are
an
application,
you
want
to
start
emitting
spans
or
activity.
You
can
just
use
diagnostic
source
without
waiting
for
open
telemetry
to
ga.
So
that's
what
I've
been
telling
other
customers
as
well.
B
Please
start
instrumenting
right
away
same
with
logging.
Like
you
use,
I
logger
it
it's
most
likely
true
for
most
customers,
because
if
you're
net
core
it's
very
difficult
to
do
an
application
without
a
loader,
so
most
of
the
folks
are
already
doing
that
yeah.
So
I
think
I'll
put
some
notes
here
about
like
we
are
delaying
1.0
until
these
two
issues,
which
I'll
be
writing
here
as
well.
B
So
that
gives
us
more
time
to
like
do
the
activity
source
adapter
approach.
So
this
is
being
a
hot
topic
like
what
do
we
do
with
activity
source
adapter?
It's
marked
internal,
which
broke
some
instrumentations
in
the
contrary,
repo.
B
There
is
no
guarantee
that
it
will
be
public
in
one
dot.
I'm
not
yet
convinced
that
we
should
expose
activity
source
adapter
as
a
public
api,
because
once
we
release
it,
then
we
have
to
support
it
for
at
least
one
or
two
years
so,
and
it's
still
doing
a
lot
of
hacky
things
internally.
That's
why
I'm
not
very
confident
of
exposing
it
as
public,
but
thanks
to
eddie
we
have
a
pr
which
demonstrated:
how
can
one
write
an
instrumentation
without
accessing
any
internals
and
he
did.
D
B
Rewriting
sp
net
core
without
activity
source
adapter,
I
mean
it's
not
merged,
because
we
don't
intend
to
merge
it
as
is,
but
it
should
demonstrate
the
concept.
So
if
there
is
any,
anyone
is
interested
in
making
the
instrumentations
from
contrib
repo
work
in
the
one
dot
or
rc
release.
B
But
I
mean
I'll
also
mention
that
the
long
term
goal
is
not
to
have
any
diagnostic
source
or
any
activity
source
adapter.
The
actual
plan
is
to
modify
the
libraries
to
switch
to
activity
source
itself,
but
it's
unlikely
to
happen
overnight,
so
we
probably
have
to
live
with
this
for
at
least
in
the
short
time.
B
So,
if
anything
yeah
I
mean
someone
was
asking
me
like
what
is
upline
for
contrib,
which
is
the
next
topic,
but
immediately
we
should
be
able
to
update
the
contrib
repo
to
the
rc,
1
or
rc2.
When
we
release
it
of
the
main
sdk
and
the
only
broker
was
there
was
no
activity
source
adapter
which
should
be
solved
with
this
approach.
B
If
I
get
time,
we
will
try
to
modify
one
or
I'll
and
see
if,
like
eddy
or
someone
else
has
some
time
to
do
it.
So
that
brings
to
the
next
question
about
contributor.
B
So
the
short
answer
is:
it's
still
open.
There
are
like
proposals,
oh
they
said
yeah.
So
there
are
proposals
in
open
elementary
about
what
we'll
do
with
what?
What
should
what
should
go
into
contrary
control.
This
is
still
being
discussed.
B
The
issue
specific
issue
which
was
being
discussed
was
about
like
should
prometheus
exporter
being
the
main
repo
as
opposed
to
contribute,
but
that
actually
opens
a
bunch
of
questions
and
why
not
move
zipkin
and
eager
as
well.
So
it's
still
being
discussed,
so
I
will
just
actively
follow
it
and
come
back
when
there
is
an
official
answer
and
we'll
just
stick
with
it,
and
one
additional
thing
is
we'll
not
release
the
condor
crypto
into
new,
get
as
one
dot
or
we'll
just
delay
the
one
out
of
four
country
password.
B
It
should
be
like
already
obvious
because
we
are
not
releasing
the
main
package,
because
if
there
is
an
official
official,
a
policy
that
all
instrumentations
and
exporters
should
leave
in
the
country
report,
then
we
may
want
to
revisit.
Should
we
put
the
nugets?
Should
we
put
contrib
name
in
the
nucleus?
B
Because
of
that
we
will
not
be
able
to
release
1.0,
but
it
should
not
be
a
big
surprise,
given
that
the
sdk
itself
is
not
ready,
so
we'll
come
back
to
it.
Please,
if
you
have
any
thoughts,
please
comment
in
the
whatevs
linked
here,
which
is
being
discussed
in
the
community.
B
Yeah,
so
that
brings
an
end
to
the
topic.
So
if
there
is
any
other
topic,
we
can
go
over
it
now,
but
otherwise
we
can
end
early,
and
I
want
to
ask
if
there
is
any
interest
in
keeping
this
meeting
for
next
two
week
weeks
or
we
can
cancel
the
next
two
weeks
and
the
next
meeting
would
be
on
the
fifth
january.
I
think
most
six
hour
cancelling
including
the
spec
meeting
or
cancelling
at
least
last
week,
at
least
in
the
last
week,
don't
know
about
the
next
week.
B
Yeah
so
I
think,
since
there
are
no
strong
opinions,
we
will
just
cancel
next
two
occurrences
for
the
next
six.
I
think
yeah.
So
next
reading
will
be
on
giant
fight
but
like
I'm
like
partially
working.
So
if
there
are
questions,
use
data
or
github
issue,
I
should
be
reachable
there
all
right.
Any
other
questions.
B
Okay,
yeah,
okay,
then
see
you
all
next
year
next
year,
we'll
have
a
lot
of
focus
on
metrics,
like
microsoft
is
going
to
work
very
like
the
total
team.
Not
just
microsoft,
like
that
on
a
team
will
be
following
the
open,
telemetry
matrix
back
and
make
it
happen
in
the
dotnet
itself.
So
if
you
are
interested
in
like
how
dotnet
should
look
like,
please
let
me
active
in
the
early
next
year,
because
that's
where
we'll
be
having
some
official
discussions
about
metrics,
yeah,
okay,
so
happy
holidays.