►
From YouTube: 2020-12-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).
C
C
A
C
Very
short
agendas
this
time
as
well,
so
I'll
go
over
it
one
by
one.
So
the
first
one
is
about
releasing
1.0.0.
So
there
is
a
ask
from
the
open
telemetry
specific
that
every
language
review.
This
attempt,
which
is
defining
the
overall
versioning
strategy
for
or
open
telemetry
clients
across
all
the
languages.
Scientific
and
the
ask,
is
every
language
should
produce
a
version
of
or
a
document
which
shares.
How
do
we
implement?
How
do
we
intend
to
implement
this
overall
vision?
C
And
we
do
have
an
example
from
java
they're
just
like
documenting
how
they
intend
to
release
all
these
packages?
How
do
they
mark
things
as
experimental,
etc?
So
I
will
be
working
on
creating
something
similar
for
dotnet
as
well,
and
I
mean
it's
an
issue
which
we'll
create
in
our
own
repo
and
have
it
linked
to
the
whatever
so
that
maintenance
or
spec
owners
can
be
look
at
that
just
to
make
sure
like
we
are
in
alignment
with
the
overall
direction.
C
So
that's
the
main
topic
so
ask
is:
please
go
and
review
the
or
tabs
and
even
look
at
the
java
example.
I'll
have
the
dotnet
one
out
by
tomorrow,
your
eod,
that's
the
ask
from
the
specs
as
well
to
have
it
ready
by
wednesday
afternoon,
and
the
plan
is
or
feedbacks
will
be
addressed,
and
this
would
be
hopefully
formalized
by
this
friday
so
that
it
will
unblock
us
from
releasing
1.0.
C
C
So
that's
update
about
one
dot,
auto
release
so
yeah
still
we
haven't
released
the
next
rc,
it's
still
rc1.
I
am
not
in
a
hurry
to
release
rc2.
So
one
of
the
goal
which
I
am
trying
to
achieve
is
after
rc2
we
should
probably
announce
that
there
won't
be
any
breaking
change.
C
There
will
be
only
stabilization
fixes
if
any
so
that
people
feel
more
confident
on
taking
a
dependency
on
rc2,
because
right
now
we
haven't
committed
that
there
will
be
no
breaking
change,
even
though
we
are
trying
no
to
break
there
might
be
something
so
so
because
of
that,
I'm
just
delaying
like
rc2
until
we
take
some
more
time
to
like
make
sure
things
are
still
in
good
shape.
C
That's
the
update
on
1.0
release
I'll
I'll
just
come
back
to
it
in
a
moment.
Once
we
go
over,
you
know
the
remaining
topics.
Oh,
I
see
that
the
gay
has
also
joined
hello,
sergey.
C
Yeah,
that's,
okay.
We
have
a
very
small
agenda
and
a
very
small
group.
This
week
it
was
pretty
much
the
same
last
week
as
well
yeah,
so
we
were
just
discussing
the
one
dot
ordered
release
plans.
I
don't
know
whether
you
are
up
to
speed
on
the
way
things
are
progressing
in
the
spec,
slash.
C
What
tips
about?
How
do
we
do
the
versioning
for
the
entire
open
telemetry
project?
So
there
is
a
what
up,
which
is
about
last
day,
so
we
are
still
reviewing
it
and
one
of
the
ask
from
this
order
piece.
Every
language
should
produce
a
language
specific
version
of
this
document,
which
should
be
in
alignment
with
the
overall
strategy,
and
there
is
an
example,
like
java
has
already
created
a
draft
version,
so
I
will
be
working
on
the
dot
net.
One
later
today,.
A
C
A
C
Yeah
yeah,
I
have
one
question
since
you're
already
here.
Let
me
ask
that
before
jumping
to
the
next
one,
so
I'm
using
java's
example,
because
java
example
seems
very
reasonable
to
discuss
this
whole
topic.
So
this
is
what
java
is.
I
mean
this
is
just
illustration.
They
may
not
be
having
the
exact
one,
but
conceptually
they
are
going
to
release
1.0,
which
consists
of
an
apa
1.0,
which
purely
I
mean
it.
It
is
something
which
do
not
have
matrix
so
anything
which
is
part
of
1.0
api
is
stable.
C
There
is
no
breaking
change
expected
until
they
go
major
version
bump
and
for
metrics
they
extract
matrix
into
a
separate
package
and
named
it
experimental,
it's
still
1.0,
but
it
is
still
experimental
and
when
metrics
are
finally
ready
to
be
like
gi
quality,
they
will
release
like
some
version
of
1.0,
which
would
contain
this
time.
The
api
would
contain
everything
as
before,
along
with
matrix,
so
this
slightly
differs
from
what
dotnet
was
at
least
planning
to
do.
C
I'm
not
sure
whether
the
current
approach
is
correct,
so
what
we
have
done
is
we
have
one
dot,
o
dot
o,
which
contains
tracing
baggage,
propagators
and
matrix.
However,
all
the
matrix
api
are
marked
as
obsolete
and
the
goal
is
once
we
are
ready
with
actual
matrix.
We
will
not
have
to
bump
to
2.0,
because
metrics
were
already
marked,
duplicated
or
absolute,
even
before
our
one
dot
or
release.
C
So
when
we
release
1.15
or
1.2
or
whatever,
we
should
still
be
able
to
just
remove
the
absolute
tag
from
the
matrix
and
put
the
actual
matrix
code
there.
So
this
is
what
I
was
thinking
for.
Dotnet,
it's
slightly
different
from
java,
I'm
yet
to
understand
whether
it
is
in
in
sync
with
the
overall
proposal.
C
Sega,
do
you
have
any
thoughts
or
alan
or
michael
anyone
else,
have
any
thoughts
on
this
approach
or
the
alternatives.
We
should
just
follow
exactly
what
java
is
doing
like,
which
is
to
remove
all
the
matrix
code
from
the
1.0
release
and
release
it
separately
as
a
completely
different
nougat
package.
D
I
don't
have
a
strong
opinion
if
we
were.
D
D
C
D
C
C
Okay,
any
other
thoughts
on
this.
It
might
I
mean
if
we
were
to
split
metrics
into
separate
package
that
may
force
us
to
do.
Like
a
I
mean
we
may
not
have
to
release
a
common
thing,
because
we
can
probably
use
like
file
sharing
approach
within
the
repo,
but
we
probably
need
to
do
some
more
thinking
about
how
do
we
deal
with
common
stuff,
because
some
metrics
api
requires
access
to
baggage
so
which
is
part
of
this?
So
we
may
want
to
do
like
summary
architecture,
but
that's
pure
implementation,
detail.
A
A
Yeah
for
matrix
there
will
be
some
public
public
service
for
in
open
telemetry
for
sure
it's
just
very
limited.
So
for
some
customers
it
will
be
quite
a
significant
switch
from
like
if
they
start
using
metrics
in
this
package,
and
then
they
need
to
switch
to
net
version.
But
I
mean
I
don't
think
it's
a
big
deal
and
apis
are
already
clearly
marked
as
absolutely
so.
It
should
be
fine.
C
So
my
one
of
my
main
concern
is:
let
me
just
it's
not
a
concern,
it's
just
a
question,
so
we
released
rc1
with
matrix
as
obsolete
and
then
we
release
one
dot
o
still,
the
same
matrix
are
still
obsolete.
C
A
A
C
A
C
I
see
oh
okay,
interesting.
I
I
didn't
realize
that
so
this
this
was
something
which
was
bothering
me
for
quite
some
time,
because
the
way
I
was
thinking
was
when
we
released
the
very
first
version
of
1.0.0.
C
C
Okay,
okay,
yeah,
I
mean
this
was
good
information.
I
think
that
may
be
a
valid
reason
for
us
to
like,
like
remove
the
metrics
from
the
main
package
and
ship
it
out
separately
or
just
remove
it
completely
and
bring
it
back
into
like
one
dot
or
dot
or
data
like
bring
back
matrix.
A
And
we
can
ship
them
simultaneously
right,
so
we
can
ship
one
dot
or
dot
without
metrics
and
one
that
ordered
beta
at
the
same
time,
but
with
matrix.
C
Yeah,
it
is
definitely
possible
yeah,
because
this
way
like,
if
you
do
like
beta,
we
never
release
like
1.0
ga,
which
means
we
are
like
whenever
we
do
like
actual
one
dot
one
dot.
Oh,
we
should
be
able
to
remove
this
matrix
because
it
was
never
released
in
stable
package
right,
but.
C
I
don't
know
whether
there
are
enough
common
stuff,
maybe
we'll
be
able
to
get
around
that.
But
my
initial
point
was:
if
you
release
this
one
like
1.0,
with
some
matrix
code,
which
are
marked
absolute.
What
I
learned
today
is
that
we
cannot
like
remove
it
in
one
1.2.
This
is
not
valid.
C
I
mean
this
will
be
not
valid.
As
per
some
word
combination,
we
have
to
bump
it
to
2.0,
which
is
why
the
alternate
proposal,
which
is
when
we
release
1.0
no
matrix
code.
Basically
we
remove
everything
and,
at
the
same
time,
we
release
1.1
with
a
beta
tag
which
contains
a
matrix,
and
whenever
we
are
ready
to
release
like
1.1.0,
we
can
easily
remove
matrix
because
bittrex
was
never
part
of
any
ga
version,
so
we
can
release
it.
I
mean
we
can
remove
it
in
the
next
year
version.
B
I
was,
I
was
just
thinking
like
when
you
make
the
1.1.0
beta.
Isn't
there
a
risk
that
you
might
need
to
break
the
like
the
public
kpi
of
1.0
to
make
it
to
make
it
work?
And
then
it
has
to
be
like
you
can't
just
bump
the
middle
version
you
have
to
you
have
to
do
a
major
version
bump
if,
if
to
separate,
to
bring
back
metrics
requires
us
to
refactor
the
thing
that
has
been
declared
1.0
and
break
the
api.
I
don't
know
how
likely
that
is
to
happen.
C
Yeah,
can
you
clarify
like
what?
What
is
the
reason
you
say
that
to
do
like
1.1.1
beta
with
matrix,
we
have
to
break
something
in
1.0,
because
we
are
just
doing
like
additive
changes
like
we
are
just
adding
metrics,
so
we
shouldn't
be
touching
any
traces
or
baggage.
B
Okay,
yeah,
I'm
I'm
just
kind
of
wondering
like
what
what
if
it
would
require
us
to
refactor
something
where
things
move
to
a
separate,
different
name
space
or
there's
no
new
common
introduced.
Then
that
would
change
the
want
to
talk
to
public
api.
But
if,
if
you're
saying
that's
probably
unlikely,
then
yeah
forget
what
I
said.
C
Yeah
I
mean
you
should
be
able
to
like
move
the
remote
the
metrics
without
affecting
the
tracing,
because
the
only
thing
which
I
believe
matrix
would
require
on
is
the
context
or
baggage
which
would
be
part
of
the
1.0.
So
it
could
be,
it
should
be
fine
like
I,
I
really
have
to
like
write
it
down
and
see
if
we.
D
Keep
if
we
keep
metrics
in
the
same
package
as
tracing
and
do
this
beta
release
at
the
same
time,
do
you
do
any
of
you
think
that
there
will
be
any
friction
for
those
individuals
who
want
to
start
using
the
metrics
functionality
but
and
are
also
depending
on
the
tracing
functionality
but
they're
hesitant?
Now,
because
the
package
is
deemed
beta.
C
C
It's
a
completely
different
package
which
has
a
experimental
qualifier
before
matrix,
but
that
has
its
own
like
downside
as
well,
but
it's
much
more
cleaner
because
we
don't
have
to
worry
about
like
any
customers
accidentally
using
beta,
assuming
it
is
not
beta
or
because
it's
a
completely
separate
package
trace
and
context.
Users
will
not
be
bothered
with
metrics
at
all.
D
C
Yeah,
I'm
not
sure
whether
we
will
need
to
keep
it
that
way,
because
at
least
from
what
I
see
in
java
like
when
they
do
like
1.0,
they
separate
matrix
into
a
separate
package
like
this,
but
when
they
are
doing
115,
they
are
just
adding
new
features
to
one
auto
which
in
which
is
adding
along
with
whatever
was
existing.
They
are
just
adding
metrics.
C
In
our
case,
it
will
be
slightly
different
because
for
dotnet
the
matrix
api
is
expected
to
come
from
dotnet
runtime.
So
we'll
only
have
this
problem
for
the
sdk,
so
we'll
have
like
we
we
can
just
have.
We
can
just
have
a
single
package
called
sdk
which
would
contain
trace
and
matrix
yeah,
but
I
mean
I
don't
have
any
strong
opinion
here.
I
I'm
just
curious,
like
what
others
think
about
this
approach
again
like
this
is
just
a
like
proposal.
I
don't
think
this
is
even
agreed,
but
it's
quite
likely.
C
D
Yeah
I
was
talking
with
tyler
maintainer
on
the
go
sig
and
he
he
said
that
all
the
packages
already
were
separate.
You
know
traces
and
metrics
and
logs
ultimately
will
all
be
separate
packages
or
they
have
them
even
from
the
very
get-go.
C
Like
api,
it
has
like
metrics
everything
in
the
sync
same
jar
file,
even
for
python
and
even
in
the
java
proposal.
It's
only
the
metrics
which
they
are
bringing
it
out
like
tracing
baggage
and
propagators.
They
are
all
in
the
same
api
package.
C
C
Or
like
one
another
alternate
was
like
completely
forget
about
matrix,
just
like
delete
it
in
1.0
and
don't
ship
any
experimental
or
any
separate
metric
package
and
then
like
whenever
we
think
metric
specs
are
ready
and
dotnet
team
is
ready
with
a
preview
bits
of
the
next.net
version
ship,
our
like
1.5
beta,
which
contains
the
matrix
and
when
dotnet
says
they
are
ready
with
ga
we'll
go
ga
like
in
1.5
or
1.6.
C
So
it's
just
a
d
change.
There
is
no
question
of
experimental
metrics,
but
then
it
prevents
people
from
ever
trying
it
out
and
giving
us
valuable
feedback
right,
but
that's
still
a
like
wide
adoption,
because
the
current
api
is
like
really
old
but
like
since
people
were
like
already
like
actively
using
it
a
lot
of
folks
and
giving
feedback.
C
We
want
to
continue
to
get
them.
So
I
mean
it's
possible
that
we
can
ask
them
to
use
like
the
old
version
like
the
pre
1.0
version,
which
is
1.1
1.0
rc,
to
continue
to
use
metrics,
but
they
won't
be
able
to
do
it
from
the
same
application
because
we
would
force
them
to
use
one
dot
of
wordpress.
A
A
D
A
C
A
C
Have
okay
yeah,
so
the
key
thing
is:
we
are
trying
to
still
provide
some
mechanism
for
users
to
play
with
matrix,
even
if
they
are
experimental,
it's
just
a
like
it's
just.
The
discussion
is
just
about
like
how
do
we
deliver
that
experimental
bit?
Should
we
pack
it
into
the
same
package
or
should
we
put
it
into
a
experimental,
separate
package
or
third
option
is
remove
it
from
1.1.2,
but
immediately
ship
like
1.1
beta
with
matrix?
D
Yeah
one
other
aspect
of
this
that
I'm
I'm
curious
about
michael
actually
brought
it
up
in
the
google
doc
and
pasted
the
link
in
the
chat
yeah.
It
should
be
here
like.
C
It's
like
my
machine
is
a
little
bit
slow,
but
I
can
get
it
from
here.
Yeah.
D
Yeah
he's
got
an
interesting
flow
here,
like
the
top
one
consider
a
timeline
like
you
know:
hotel,
100
and
then
he's
kind
of
walking
through
kind
of
of
a
sember
like
thing
where
1.1
adds
some
new
functionality,
will
the
hotel
spec
also
have
the
potential
of
having
a
1.1,
and
how
do
we
do?
We
need
to
align
with
that
or
ultimately,
if
we
need
to,
then
I
think
I
think
we
need
to
break
semver
one
way
or
another.
If
we
have
to
adhere
to
something
like
that,
I.
C
Think
this
is
what
mentioned
I
mean
I
do
remember
like
reading
something
like
that
here.
D
Yeah,
maybe
I
need
to
study
that
sometimes
I
haven't
spent
much
time
with
it
yet
so.
D
C
Yeah,
which
means
going
back
to
this
like
when,
like
all
this
point,
we
say
that
we
are
implementing
the
spec
1.0
when
spec
becomes
1.1,
we
say
that
we
are
going
to
1.3
and
1.3
of
dot
net
implements
1.1
of
the
spec.
C
Possible
but
yeah
I
mean
it's
a
good
point.
Maybe
it
makes
sense
to
have
like
all
in
line
like
if
someone
says
I'm
using
1.0
version
of
any
language,
it
automatically
assumes
that
it
is
the
1.0
version
of
the
spec.
That
would
be
like
easy
to
explain,
but
given
the
way
different
languages
are
progressing
at
different
velocity
may
not
be
peaceable.
C
C
C
C
Okay,
yeah
one
another
topic
which
I
want
to
ask
like
with
or
more
folks
is
about
logging.
It
looks
like
we
have
the
same
problem
with
logs
like
guessing.
We
have
I
mean
for
api.
We
don't
have
anything
related
to
logging,
because
for
logging
the
api
is
logger,
but
for
sdk
we
we
have
like
there's
a
single
package
called
open
telemetry,
which
contains
the
sdk
bits
for
tracers
logs
and
metrics.
C
So
I'm
wondering
like
whether
we
should
like
stop
calling
it
as
ga,
but
I'm
not
yet
sure,
because,
given
that
the
spec
simply
says
we
are
not
going
to
define
a
new
api,
the
open
elementary
suggestion
is
to
integrate
with
the
well-known
existing
api
for
that
language
and
in
case
of.net
it
is
our
logger
and
it
says
we
should
allow
correlation
and
the
log
model
is
defined
in
the
spec
and
we
also
defined
a
log
model
which
is
following
the
spec,
but
it
is
like
containing
like
not
all
the
fields.
C
Let
me
just
take
that
and
try
to
explain
so
it
may
be
easier.
So
this
is
our
sd
case,
login
piece.
So
the
only
thing
which
is
like
really
a
public
api
is
the
logo
code,
which
loosely
follows
the
spec,
because
spec
has
time
stamp
trace
id
span,
id
tri-state,
probably
not
category
name,
but
log
level
thing
exception.
This
is
slightly
different
like
so
I
was
thinking
since
this
class
is
like
sealed.
C
We
should
be
able
to
still
call
it
like
1.0
ga,
and
we
can
eventually
add
more
things
into
this
one
without
breaking
without
requiring
us
to
release
a
2.0.
A
C
Many
experts
do
we
have
for
logs,
not
like
we
have
like
in
memory
and
console
that's
it.
We
should
demonstrate.
How
do
you
write
a
actual
exporter
to
a
real
backend?
It
should
demonstrate
the
concept,
but
we
do
not
have
even
a
single
one
which
exports
to
any
real
backend
like
elasticsearch
or
anything
else.
A
A
And
expert
and
processor
right.
C
Yeah,
we
do
have
it
so
these
are
like
template
class.
Oh
sorry,
base
exporter
of
t
and
t
can
be
both
activity
or
log
record.
So
that's
how
we
demonstrated
the
usage
in
by
virtue
of
a
console
console
exporter
which
can
export
locks
as
well.
C
I
don't
think
like
spec
has
reached
that
state
yet,
but
it
really
defines
like
what
it
what
exactly
the
low
model
would
contain.
You
are
like
mostly
aligned
with
like
this
thing,
except
that
we
don't
have
like
few
like
resources
and
attributes,
but
I
was
thinking
like
these
are
adt
changes.
We
should
be
able
to
just
add
it
anytime
afterwards
without
procuring
us
to
bomb
any
question.
C
D
It
would
probably
be
least
controversial
to
do
the
same
thing
here
as
we
are
talking
about
with
metrics
some
individuals
that
I've
spoken
with
are
not
convinced
that
the
the
model
here
is
going
to
stay.
The
same
I
mean
I
hear
you
on
like
adding
things,
but
you
know
other
things
that
could
happen,
or
things
may
be
renamed
or
restructured.
D
C
C
So
that
was
one
of
my
reasons
why
I'm
still
considering
like
should
be.
I
think.
C
C
That
was
my
reasoning
behind
like
this
is
what
alan
was
mentioning
to
me
like
last
week.
Also
right
since
we
cannot
write
a
otp
exporter,
we
may
not
want
to
call
it
as
a
maturity
level
above
what
is
defined
in
the
overall
specification.
C
Okay.
So
let
me
put
that
also
into
my
release.
Proposal
like
we
mean
something
like
an
open
door
spring.
Should
we
treat
log
record
as
same
as
matrix
and
consider
removing
it
or
consider
adding
it
as
a
experimental,
separate
package.
C
Yeah,
so
that
that
was
my
only
question
like
left
about
like
the
versioning
and
rusty's,
I
mean
just
just
need
some
time
to
go
over
the
actual
proposal
so
that
we
can
figure
out
whether
there
is
something
which
is
not
in
alignment
with
what
dotnet
is
doing.
C
B
Hey
I
missed
the
last
one.
When
was
the
dates
that
the
the
plans
are
to
do
the
ga
still
like
in
december
sometime.
C
It
would
assume
I
mean
we
have
to
assume
a
lot
of
things
to
make
that
in
december,
because
for
this
the
number
one
thing
is
like
this
autopsy
has
to
merge
and
officially
become
like
approved,
so
that
there
is
a
well-defined
definition
of
what
exactly
is
1.0
and
what
exactly
is
meant
by
open
elementary
ga.
Only
after
that
language
can
release
actual
one
daughter.
C
So
there
is
an
ask
from
the
community
to
do
it
by
tomorrow
and
by
friday.
Ted
would
move
it
into
official
spec,
but
since
it
is
like
just
an
ask,
I
don't
I
don't
know
how
do
we
enforce
it
or
how
do
we
guarantee
that
everyone
will
respond
in
the
next
two
days
and
all
comments
will
be
addressed
in
the
following
two
days.
So
if
this
is
not
going
to
happen
this
week
or
next
week,
then
I
don't
think
it's
going
to
happen
in
december.
C
So
basically,
I'm
saying
that
what
I'm
saying
is
we
are,
depending
on
the
overall
open
elementary
community
to
say
what
the
definition
of
ga
before
that
we
will
not
release
actual
one
daughter.
We
may
release
like
rc2
and
rc3,
but
we
won't
do
like
one
dot.
Oh
actually,
so
it
could
be
next
year
it.
It
is
possible
that
it
can
be
released
like
in
december
itself,
but
I
I
wouldn't
commit
to
that.
C
C
Okay
yeah,
so
next
topic
is.
I
want
to
briefly
discuss
about
the
quandary
prepost
states
because
again
like
while
looking
at
the
questioning
and
stability
dog,
there
is
a
lot
of
mention
about
the
country
repo,
because
once
again,
very
recently,
like
I
think,
python
moved
anything
which
is
not
part
of
the
like
actual
sdk
into
the
contract,
repo,
including
all
the
instrumentations,
and,
I
think,
even
the
exporters.
So
only
the
actual
api
and
the
sdk,
and
probably
the
baggage
and
context
are
in
the
main
repo.
Everything
else
was
moved
into
the
country
report.
C
So
I
am
wondering
like
should
we
like
follow
a
similar
approach,
where
the
main
ripper
would
only
contain
the
absolute
necessary
things
which
is
required
as
sdk
and
api
everything
else,
including
the
official
jaeger
zikin
otlp
exporter,
to
be
moved
into
the
contract
report,
and
that
would
also
bring
the
question
like
what
else
can
be?
In
the
contrary,
repo
I'm
just
curious
like
if
anyone
had
any
thoughts
on
it.
C
Even
without
this
topic,
we
still
have
to
fold
the
ownership
model
for
contract
repo.
I
was
considering
to
do
something
like
per
directory
approvers,
as
opposed
to
a
approver
for
the
entire
repo,
which
is
how
it
is
currently
set
up.
So
if
you
have
like
five
five
different
instrumentations,
then
we
can
have
like
approval
for
each
of
these
folders.
C
That
would
help
like
I
mean
we
don't
want
to
just
add
like
approvers
randomly
so
by
having
a
per
directory
approver,
then
we
should
be
able
to
add
more
approvers
but
they'll
be
restricted
to
an
individual
further
any
any
thoughts.
On
that
my
biggest
goal
is,
I
mean
I
say
individual.
I
do
not
know
enough
about
mass
transit
to
go
and
approve
like
prs
on
this,
but
there
are
people
who
are
really
expert
in
this.
C
We
both
confirmed
the
same
report,
so
I
just
clapped
it
together,
but
they
are
like
really
separate
questions.
The
main,
like
first
question,
which
we
had
for
like
last
few
months,
was
put
on
the
packages
or
on
the
code
in
this
contract.
So
we
have
to
solve
this
problem
first
and
second
is:
should
we
consider
moving
the
packages
from
main
repo
into
this
one?
Last
one.
D
A
C
So
you
are
like
mostly
in
favor,
of
keeping
the
current
structure
except
maybe
move
out.
I
I
was
thinking
like
there
is
no
need
of
keeping
readys
or
maybe
even
grpc,
into
the
main
report.
I
mean
it's,
it's
very
common,
but
it's
not
as
common
as
sequel
or
http
client.
This
is
just.
A
C
C
C
I'm
not
like
opposed
to
that,
like
my
first
step,
would
be
to
like
move
release
because
reduce
is
not
really
me,
at
least
for
sp
and
http
client
and
perhaps
sql.
They
are
like
shipped
along
with
dotnet,
like
whenever.net
releases,
a
new
version,
a
new
version
of
sql,
client,
http,
client
and
spin.
It
is
released
so
that's
my
like,
since
they
all
move
in
sync,
we
should
be
able
to
keep
them
in
the
main
ripple
and
also
considering
that
they
are
the
defective
standard
for
creating
the
applications
in
dot
net.
C
So
that
was
my
only
argument
of
like
keeping
these
three
but
moving
readys
and
possibly
I
put
a
question
mark
on
grpc
because,
like
grpc
is
like
not
like
really
independent,
it's
somewhat
on
top
of
asp.net
core.
So
it's
not
really
a
separate
thing
because
of
the
peculiar
way
in
which
it's
implemented,
so
it's
probably
okay
to
keep
grpc,
even
if
it's
like
not
really
maintained
by
the
network.
C
So
let
me
do
like
create
an
issue
here
and
start
with
redis,
because
that
is
seems
least
controversial
to
move
from
the
main
ripoff
to
the
country
purple.
But
before
that
I
would
like
to
hear
like,
can
we
just
create
like
colonies
for
individual
folder
and
separate
out
like
there
is
an
overall
approach?
We
can
just
like
duplicate,
that
user
group
called
dotnet,
approvers
and
just
have
like
yeah.
We
don't
need
like
dotnet
approvals.
We
just
need
like
dotnet
maintainers
for
the
overall
bookkeeping
and.
D
I
I
like
things
in
the
main
repository,
but
I
guess
that's
not
a
strong
opinion,
though
one
thing
that
does
concern
me
is
that
if
we
do
move
things
out,
you
know
we
were
talking
a
few
weeks
back
about
how
things
get
released
from
the
country
repo,
and
I
don't
think
we
necessarily
finished
that
discussion
or
settled.
C
So
what
I
recollect
is
this,
like
there
was
a
proposal
to
not
ship
anything
from
the
country
report.
It
will
just
be
as
a
it
will
just
serve
as
a
like
place
for
like
some
companies
to
build
and
package
it
themselves,
so
that
there
is
no
requirement
of
maintaining
any
sla
or
anything.
That
was
one
of
the
proposal
right.
D
C
If
we
were
to
like
move
it
into
like
this
repo
and
if
we
consider
per
directory
approval
approvers,
then
we
should
be
able
to
release
this
along
with
the
main
repo
all
the
time,
because
I'm
assuming
that,
like
whoever
contributed
this,
will
be
available.
If
not
I'll,
be
just
bum.
The
version
keep
the
same
code,
so
we
have
elasticsearch
right
now.
When
we
bump
to
2.0,
we
will
release
elastic
same
code
in
do
2.0
or
every
release
will
just
keep
releasing
it.
So
that
will
have
every
package
having
the
exact
same
version.
C
Yeah,
if
you,
if
you
want
to
move
like
it,
it
will
have
to
name,
but
it's
not
like
I'm
like
really
interested
in
moving
that
it's
just
that,
like
we
want
to
like
define
like
what
qualifies
for
the
main
repo
versus
what
does
not
and
out
of
all
the
things
which
are
part
which
are
currently
part
of
the
repo.
Only
thing
which
does
not
like
really
fit
into
it
is
the
reduced
client.
C
Everything
else
is
like
somewhat
like
part
of
the
dotnet,
perhaps
extension
cloth
hosting
as
well,
but
everything
else
is
either
required
by
the
spec
or
required
by
like
the
sdk
implementation
like
these
are
api,
then
sdk,
then
these
are
all
exporters
as
circuited
by
the
spec.
So
we
cannot
really
move
it
out.
The
only
possible
things
which
we
can
move
are
the
instrumentations
and
of
that
everything
seems
to
be
tied
into
dot
net.
C
So
we
can
argue
that
anything
which
is
try
to.net
will
keep
it
anything
which
is
not
maintained
by
the
dot
net
organization,
which
is
like
mostly
microsoft
and
for
grpc.
I
think
it's
just
separate
github
like
github
slash
grpc,
but
since
it's
somewhat
tied
into
sp
net
core
and
http,
we
may
be
forced
to
keep
it
here,
given
they
share
like
a
lot
of
stuff,
but
that
would
leave
only
stack
exchange,
readys
and
possibly
the
extensions
to
be
moved
out.
C
But
if
we
move
yes,
we
will
have
to
have
a
breaking
naming
change
to
include
the
country
name
in
the
package
itself,
or
we
can
decide
to
keep
things
assessed.
Anything
new
would
go
into
this
report
that
is
equally
feasible
and
we
can
ask
like
aws
and
a
show
to
move
these
specific
things
into
their
own
reports.
It
could
leave
here
like
temporarily,
but
eventually
they
will
go
away,
but
even
stackdriver.
These
three
are
like
cloud
vendor
specific,
but
for
entity,
framework,
elasticsearch
or
those
kind
of
things.
C
We
can
keep
this
with
separate
signal
approver
and
we
can
release
it
along
with
whenever
we
release
the
main
repo.
That
way,
we
have
like
somewhat
balanced
approach
where
the
maintainers
are
not
burdened
with
reviewing
all
the
prs
in
each
of
the
signals,
and
yet
we'll
have
a
way
for
like
community
to
contribute
and
benefit
from
others.
B
Yeah
that
part
about
like
having
also
individual
repositories
like
say
the
azure
goes
away
into
some
azure
repo.
I
believe,
there's
there's
an
azure
repo
for
the
app
insights
exporter
already
separate
one
right,
so
I
think
that's
a
bit
confusing
where
some
of
it
is
in
contrib.
Some
of
it
is
in
like
say
in
this
example:
microsoft
repository
it's
hard
to
find
things
like.
I
saw
people
multiple
times.
B
C
A
problem
which
we
can
still
solve
because
the
general
way
there
is
a
general
recommendation
on
verdu
where
to
look
for
things
which
is.
There
is
a
registry
in
open
data.
C
You
mean
once
these
things
are
like
officially
released.
We
can
put
that
into
here.
So
when
you
search
for
net
you'll,
see
like
honeycomb
neural
like
every
vendor
specific,
you
just
need
to
submit
your
request
so
that
they
can
be
listed
here.
So
the
place
to
search
for
things
are
so
that
shouldn't
be
an
issue
and
like
my
goal,
is
to
remove
all
the
vendors
like
these
are
like
really
specific
to
like
microsoft
or
amazon
or
google.
C
So
this
would
like
eventually
move
away
and
like
the
only
thing
which
is
going
to
be
part
of
controversy,
like
things
which
are
like
fully
open
source
which
is
not
tied
to
any
particular
vendor,
so
elasticsearch
mass
transit,
like
any
other
like
any
other
library
instrumentations
which
are
not
tied
to
like
ashore
like
if
azure,
is
an
azure
sdk.
It
won't
come
here
because
it
will
be
on
by
sure,
but
for
anything
which
is
not
tied
to
any
vendor.
We
should
be
able
to
revise
this.
D
C
Yeah
I
mean
one
reason
why
we
put
the
name
originally
was
just
to
give
a
indication
that
it
is
not
maintained
by
the
same
open
elementary
ripple,
so
it
may
have
like
lower
bar
or
lower
quality,
because
we
we
do
not
know
like
who
is
approving
it.
C
I
mean
also
like
there
is
no
guarantee
that
will
release
like
bhaktis
in
the
same
rigor
as
the
main
report,
because
let's
say
that
someone
contributed
an
elastic
search
and
that
person
became
the
approver,
but
he
just
disappeared,
and
then
there
is
a
bug
so
who
is
going
to
fix?
That
would
be
a
question
like
for
the
main
repo,
at
least
we
can
have
the
maintainers
work
on
that,
but
since
this
this
could
grow
indefinitely
like
potentially
tends,
maybe
like
even
more
so
at
that
time.
C
We
just
want
to
let
who
is
consuming
this,
be
aware
that
this
is
a
community
contribution.
This
may
or
may
not
have
all
the
bug
fixes
taken
care,
as
with
the
main
report,
so
I
think
putting
the
name
contrib
would
give
some
indication.
Okay.
This
is
coming
from
a
different
repo
and
I
think
we
can
put
that
disclaimer
here.
A
Okay
yeah,
so
originally
we
divided
three
posters
by
supportability
like
we
will
support
one
assemblies
more
than
other
and
now
the
proposal
it
seems
like
to
split
by.
I
don't
know
whether
it's
in
dotnet
or
not
in.net,
right.
C
I
mean
that,
would
that
would
work
if
he
can
remove
the
stack
exchange
and
possibly
grpc
as
well,
but
I
mean
I
don't
think
there
is
anything
wrong
in
keeping
the
original
one
asses
like
based
on
support
ability,
like
anything
supported
by
the
main
community
or
main
maintainers
slash
approvers,
will
be
in
the
main,
repo
and
everything
else
in
the
other
repo.
A
You
can
always
have
country
and
community
so
like
dotnet
dash
community,
maybe
another
one.
C
But
then
it
may
be,
like
another
point
of
confusion
right
if
you
have
three
reports-
and
I
assume
that
there
will
be
three
for
the
open,
elementary.net
instrumentation
folks
as
well,
they
will
also
come
up
with
like
similar
things
in
the
future.
So
there
will
be
like
too
many
reports
it.
It
may
just
confuse
people
yeah.
C
So
I'm
okay
with
this
approach,
which
you
just
said
like
anything
which
is
supported
by
the
I
mean
it's
basically,
the
supportability
guarantee
is
what
splits
one
ripple
from
another.
C
So
if
you
just
say
that
this
ripper
has
less
supportability
guarantee,
we
should
be
able
to
easily
approve
more
and
more
like
more
instrumentations
for,
like
other
libraries,
because
right
now,
if
someone
submits
a
library
instrumentation
for
something
which
the
current
maintainers
are
not
familiar
with
it,
it
is
usually
delayed
input
request,
because
there
is
not
enough
experts
to
review
it
and
approve
it
and
maintain
it.
So,
but
if
we
move
with
per
signal
or
per
directory
approval
at
least
we
can
delegate
that
to
whoever
is
an
expert
in
elasticsearch
can
just
own
it.
C
C
So
there
are
no
objections.
I
think
I'll
go
ahead.
The
first
thing
I
mean
I
won't
move
any
packages
from
main
report
to
here.
Instead
I'll
try
to
move
the
ownership
by
splitting
the
I
have
to
learn
how
to
do
that.
Maybe
I'll
reach
out
to
sergey
I'll
create
like
separate
approvals
list,
or
I
think
we
can
just
do
like
quote-unquote.
C
C
Yeah,
okay,
yeah
and
after
like
initial
problem,
is
solved
I'll,
come
back
and
ask
the
question
about
like:
should
we
move
even
like
everything
which
is
not
required
for
the
actual
ripple
into
this
one
like
similar
to
what
python
is,
I
think
python
is
just
considering,
or
I
don't
know
whether
they
already
know
but
we'll
come
back
to
it
like
in
a
later
stage.
C
C
So
instrumentation
yeah,
so
they
moved
all
the
instrumentations
elasticsearch
django,
like
all
the
even
the
popular
ones
like
class.
They
all
moved
into
country.
I
think
they
just
merged
it
like
two
days
back.
So
this
is
what
I
was
wanting
that
should
be
for
all
this
approach.
So
there
is
nothing
in
the
main
ripple
for
instrumentation.
C
They
just
have
a
base
class
for
instrumenting
and
every
instrumentation
is
just
supposed
to
follow
and
I
think
same
for
okay,
the
spec
required
exporters
are
part
of
here,
but
everything
else
got
moved
maybe
like
this
is
something
which
we
can
explore,
but
the
only
thing
is:
if
we
do
that,
then
we'll
have
to
do
a
renaming,
so
we
have
to
do
it
before
1.0,
but
this
is
just
what
python
is
doing.
C
Don't
I
don't
know
yet
whether
all
other
languages
are
doing
it
or
whether
the
spec
is
asking
like
every
language
to
do
that
either.
So
this
is
something
which
I'll
try
to
follow
up
in
the
next
maintenance
meeting
and
see
if
there
is
any
recommendation
from
the
overall
community
to
move
all
the
instrumentations
out
of
the
main
ripple,
and
if
there
is
a
consensus
that
every
language
is
moving,
then,
yes,
we
can
consider
the
same
so
that
we'll
only
have
like
just
the
basic
api
sdk
and
the
spec
required
exporters.
C
B
Right
now,
one
thing
related
to
that,
and
we
don't
really
have
time
to
discuss,
but
maybe
discuss
offline
and
probably
will
be
related
to
the
stabilizing
of
the
public
api
as
well,
is
that
there
is
an
issue
going
on
in
the
contrib
report
where
people
are
complaining,
rightfully
that
it's
become
quite
hard
to
do.
Instrumentations.
C
Like
is
there
any,
you
just
want
to
ask
about
it.
I.
B
Was
just
going
to
say
like?
Is
it
still
like
how
to
say
like
will
we
ever
do
it
in
the
main
report
like
make
certain
things
public
before
ga.
C
To
connect
yeah,
so
my
my
thinking
is
this
like
this
is
what
one
of
the
issue
and
there
is
a
issue
about
activity
source
adapter.
So
there
are
two
things
which
broke
the
control
paper
like
number
one
thing
is
we
had
exposed
kelper
methods
to
subscribe
to
diagnostic
source?
C
It's
all
marked
internal,
but
like
one
of
the
thing
which
I
was
trying
to
say
in
the
beginning,
was
I'm
going
to
just
like
run
it
like
literally
copy
paste,
the
same
helper
methods
into
the
contrary,
prepo
and
make
it
work
so
that
they
no
longer
be
broken.
C
But
there
is
one
special
case
which
is
a
activity
source
adapter.
This
is
a
little
bit
hard
problem
to
solve,
because
I
mean
just
to
share
background.
The
reason
why
we
had
to
introduce
this
thing
called
activity
source
adapter
is:
there
are
a
bunch
of
instrumentations
which
were
creating
activity
using
the
constructor
effective
without
using
activity
source
those
activities
they
do
not
go
through
the
same
pipeline.
They
do
not
go
through
samplers,
for
instance,
so
we
have
to
find
some
special
way
to
feed
it
through
the
same
sampler.
C
C
Let
me
just
take
that
so
trace
extending
the
sdk
building
your
own
instrumentation
library,
so
I
put
like
there's
a
special
case
for
libraries,
which
already
produce
activity
so
the
easiest
way
to
handle
that
is
like
subscribe
to
those
using
diagnostic
source,
which
is
easy.
It
does
not
require
any
special
access,
but
then
ignore
the
activity
which
was
already
created
by
that
library
and
create
a
duplicate
one,
but
this
time
using
the
actual
activity
source.
C
So
this
should
work.
This
is
how
we
started
all
the
instrumentations
in
this
repo,
but
there
is
a
perk
penalty
because
you
are
just
allocating
a
new
activity,
even
though
there
is
an
existing
activity.
C
The
only
way
out
of
this
problem
in
my
initial
assessment
is,
if
we
modify
the
actual
library
to
reinstrument
the
way
they
create.
Actually,
in
fact,
it's
not
entirely
instrumentation
the
library
just
have
to
change
how
they
are
creating
activity
instead
of
doing
new
activity.
Dot
start
they
have
to
just
replace
it
with
activity,
source,
dot,
start
activity
and
while
doing
that,
they
have
to
set
up
some
dummy
listener
to
avoid
breaking
backward
compatibility.
So
this
is
something
which
I
am
actively
working
on.
In
fact,
there
is
a
there.
C
Is
a
report
called
sp
elementary
correlation.
This
is
one
such
library
where
it's
already
creating
diagnostic
source
and
it
is
creating
activity
itself.
So
I'm
trying
to
like
modify
this
library
so
that
it
it
can
produce
activity
using
activity
source,
yet
keeping
backward
compatibility.
C
If
this
approach
is
like
found
to
be
successful,
then
we
should
be
able
to
ask
all
the
other
instrumentations
in
the
control
paper,
which
I
believe
are
like
two
of
them,
like
elasticsearch
mass,
translate
to
follow
the
same
approach
and
so
that
they
don't
require
activity
source
adapter,
so
we'll
keep
activity
source
adapter
as
an
internal,
only
thing
just
to
specially
handle
the
http
client
like
current
versions
in
the
future
versions.
They
also
will
not
require
activity
source
adapter.
C
So
it's
still
depending
exactly
how
do
we
solve
it
for
activity
source
adapter,
but
for
everything
else?
It's
just
a
matter
of
like
like
literally
copy
pasting,
the
code
so
and
that
code
is
right
here,
like
these
three
classes.
It's
it's
just
a
helper
to
subscribe
to
diagnostics,
so
you
don't
really
have
to
use
this
class.
You
can
directly
use
because
dotnet
allows
this
way
to
subscribe
to
the
actual
event.
So
there
is
no
need
of
using
this.
C
B
Okay,
yeah
sorry,
I
was
just
curious.
I
was
just
wondering
if
it's
an
option
to
oh
just
make
it
public
again,
but
clearly
a
lot
more
complicated
than
I
expected.
Okay,
yeah.
C
So
I
am
not
in
favor
of
like
exposing
these
things
as
public,
because
I
mean
there
is
no
open
elementary
specific
thing
here.
It's
just
a
dotnet,
a
way
of
subscribing
to
diagnostics.
So
if
we
expose
it
as
public,
then
we'll
be
forced
to
keep
it
forever
because,
like
once,
we
release
1.0,
we
cannot
change
it
and
it's
it's
not
that
I
expect.
I
mean
one
of
the
main
reasons.
We
don't
expect
diagnostics
force
to
be
a
key
mechanism.
C
People
use
to
instrument,
we
expect
everyone
to
use
activity
source,
so
this
should
be
like
a
legacy
thing.
This
is
earlier
required
for
old
instrumentations,
which
are
already
instrumented
using
diagnostic
source,
so
there
is
not
much
value
in
making
it
public
and
maintaining
it.
Given
that
the
recommendation
is
to
move
away
from
this-
and
there
are
like-
I
think
I
mentioned
it
in
the
issue
like
if
you
make
it
public,
then
we
have
to
really
document
it
and
also
capture
some
pitfalls
like
by.
C
By
doing
this
approach
like
there
are
some
pitfalls
about
context
propagation,
then
we
have
to
like
solve
it
here
so
right
now
we
sold
it
internally,
because
these
are
internal
classes.
We
just
work
around
it.
So
if
you
make
it
public,
then
we
have
to
design
something
else,
so
it
will
become
like
much
more
than
just
changing
from
internal
to
public
public.
C
Yeah,
so
we
are
on
time
so
we'll
see
you
all
next
week
so
next
week
I
I'll
just
ask
everyone:
if
there
are
any
agenda,
if
there
are
no
agenda,
we
may
oh
actually
next
week
is
50..
No
just
cancel
that
I'll
still
be
working
so
the
week
after
that,
we'll
do
like
skip
it.
C
If
there
is
no
agenda
posted
ahead
of
me
all
right
thanks,
everyone
see
you
next
week
and
please
take
your
time
to
look
at
the
questioning
proposal
in
open
telemetry
and
in
the
dotnet
specific
one
which
I'm
about
to
write
in
the
next
day.