►
From YouTube: 2021-02-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
A
B
B
B
Yeah,
I
think
we
can
start
if
you're
in
the
call.
Please
put
your
name
to
that
in
this
list.
Can
one
of
you
confirm
I'm
sharing
my
screen
correctly.
You
can
see
the
yeah
okay
yeah,
so
we
have
like
quite
a
few
topics
to
discuss.
Today.
There
is
someone
from
the
open,
telemetry
technical
committee
who
is
planning
to
join
book
then,
but
I
I
don't
see
him
yet,
so
maybe
we
can
go
backwards
because
the
first
one
is
fair.
We
need
some
input
from
them
as
well.
B
Since
he's
not
yet
here,
I
think
we
can
go
backwards
from
the
bottom
and
up
so
we'll
start
with
the
otlp
exporter,
just
a
refresher
in
case
you
are
not
aware.
B
So
when
we
released
rc3,
we
removed
the
support
for
https
in
the
otlp
exporter,
with
the
initial
plan,
to
not
have
it
supported
in
1.0
and
add
it
as
a
feature
in
1.1,
but
thanks
to
allen
who
worked
over
the
weekend
and
found
a
fix
which
does
not
require
an
apa
change
that
tier
has
been
merged
since
so,
basically,
if
you
try
the
latest
build
from
mygate,
you
should
get
the
same
behavior
as
before
I
mean
you
can
specify
https
and
it
will
respect
the
credentials
now.
B
So
in
when
we
release
like
the
next
rc
or
1.0,
it
should
have
the
same
functionality
as
in
rc2,
but
only
thing
which
we
removed
is
the
ability
to
customize
a
path
to
the
certificate.
So
this
should
be
like
a
better
shape
than
rc3,
which
did
not
even
allow
tls.
We
were
throwing
if
you
specify
https
path,
so
that's
just
an
update
on
otlp
exporter,
so
that
means
all
the
core
components
are
like
still.
B
In
the
same
shape
as
it
was
in
the
previous
release,
no
changes
except
to
the
otlp,
which
I
just
mentioned-
let's
go
to
the
country
purpose,
and
this
also
here
can
you
give
an
update
on
where
we
are
looks
like
we
made
a
lot
of
progress
in
last
one
week.
So
if
you
can
give
an
update
and
we
can
figure
out
what
is
next
yeah.
C
Yeah
so
as
part
of
the
last
sig
meeting
discussion
on
the
contract
repo,
we
kind
of
agreed
that
it
would
be
better
to
have
separate,
build
and
release
processes
for
separate
components.
So
one
of
the
changes
was
that
each
component
can
now
target
a
specific
version
of
open,
telemetry
sdk.
So
the
common
build
file
was
moved.
That
version
was
removed
from
the
common
build
and
put
into
each
project,
and
then
the
other
thing
was
that
for
release
of
each
project,
it's
now.
C
Actually
the
versioning
of
each
project
is
now
done
through
manual
prefix,
which
is
kind
of
yeah.
That
is
showing
that
exporter.stackdriver
hyphen,
whatever
that
tag
would
be,
is
taken
as
the
assembly
version,
and
then
creation
of
that
particular
tag
would
also
trigger
the
release
workflow
for
that
particular
project.
B
So
we
already
modified
cs
approach
to
how
that
okay,
prefix
here,
yeah
okay.
So
now
this
project
will
respond
to
a
tag
which
has
this
prefix.
Okay
got
it.
C
Yeah,
so
I
think
yeah
I'll
make
a
note
of
all
of
these
changes,
because
that
would
come
in
handy
to
anyone
who's
contributing
a
new
project
in
the
contra
repo.
They
would
need
to
have
the
min
world
prefix
the
github
workflow
in
place
to
actually
build
and
release
their
project.
B
So
can
you
describe
how
would
the
actual
release
look
like?
So,
let's
say
if
I
want
to
release
the
aws
x-ray
project,
so
all
I
need
to
do
is
push
a
tag
which
matches
this
pattern
appended
with
the
actual
version
and
push
it,
and
that
would
trigger
this
workflow,
which
will
build.
Does
it
okay?
It
just
builds
that.
C
It
just
spells
yeah
the
project
x-ray
project.
B
With
the
version
which
we
given
and
it
pushes
all
the
way
to
my
gate-
okay,
yeah
yeah
and
I
mean
even
in
the
main
repo
only
up
to
this
point-
is
workflow,
so
the
actual
release
to
nougat
is
still
manual.
Basically,
we
look
at
the
actual
workflow
download
the
new
gates
and
push
it
manually
to
nougat,
but
this
is
like
fairly
easy
to
automate.
We
have
it's
just
that
we
haven't
done
it
okay.
This
sounds
good
to
me.
Any
concerns
about
this
approach.
A
C
So
a
few
things
that
we
have
in
the
downstream
like
within
the
aws
hotel
repo,
is
that
continuous
running
like
integration
test,
so
like
a
sample
app,
which
instruments
with
open
telemetry
and
then
there's
a
test
framework
which
kind
of
loads
that
sample
up
and
tests
end-to-end.
So
if
that
we
can
make
it
to
upstream,
like
hotel,
repos
and
figure
out
a
way
to
because
it
kind
of
leverages
a
lot
of
aws
technology
stack
to
do
the
integration
test.
C
Mostly
it's
testing,
at
least
for
the
sdk
downstream
repos.
Then
there
is
like
collector,
which
is
a
separate
entity
in
itself.
A
Okay,
so
integration
testing
is
definitely
something
important,
so
I
I
can
share
some
some
observations.
I
had
like
well
back
in
the
open
census
days.
We
used
to
have
the
gcp,
the
google,
I
called
platform
integration
test,
but
everything
is
tightly
coupled.
So
I
remember
when
I
was
a
python
maintainer.
We
got
some
something
we
want
to
do
a
release,
but
I
could
not
do
the
release,
because
the
integration
test
was
blocked
and
it
turned
out.
A
I
spent
two
days
debugging
and
learned
how
to
use
google
cloud
use
my
personal
credit
card
and
it
turned
out
the
google
cloud
part
like
the
the
service
used
for
integration.
Testing
is
running
over
budget
like
nothing
is
wrong
in
the
code.
It's
just.
We
like,
we
spend
all
the
money
and
the
service
just
denied
our
request,
so
we
have
to
create
a
a
new
service
and
that
ask
will
go
to
google
and
they
have
to
figure
out.
A
So
it
actually
takes
a
couple
of
days
and
I
have
to
make
a
shortcut
by
stating
like
I
have
verified
everything
manually
and
I
I
make
sure
that
we're
doing
the
right
thing
so
we're
not
going
to
get
blocked
and
I
change
the
the
process
just
to
unblock
us.
So
we
want
to
move
em
down
integration
test
here.
A
So
if
we
want
to
have
integration
tests,
we've
got
to
figure
out
who's
going
to
pay.
For
that,
and
I
think
for
aws
specific
thing
they
might
not
use
the
the
standard.
Git
github
action
might
create
a
separate,
workflow
and
and
have
the
aws
team
paying.
For
that,
then
the
question
is
for
people
who
are
sending
all
requests
or
making
changes
that
are
not
affecting
aws.
Will
you
guys
be
interested
in
covering
that
additional
cost,
because
cost
will
eventually
become
like,
will
grow
and
and
will
eventually
become
sensitive?
A
The
third
thing
is
the
credential
management.
I
remember
at
that
time.
I
have
access
to
the
gcp
account
I
I
know
the
password,
but
I
I'm
not
the
admin.
So
I
know
the
password
to
the
service,
which
is
kind
of
a
little
bit
concerning
so
probably
need
to
sort
that
out,
but
I
want
to
get
feedback
from
everyone
here.
Do
you
see
a
need
that
we
want
to
run
additional
integration
tests
so
sometimes
that
might
not
be
interesting
to
everyone?
A
A
Or
even
think
about
this
like,
if
you
have
elastic,
we
have
elasticspotter,
there
are
multiple
versions
of
elastic
backhand
and
every
major
version
of
elastic
backhand
is
incompatible
with
the
other
versions.
So
we
got
to
run
that
either
we
decide.
Okay,
we're
going
to
take
some
external
dependency
or
we
always
host
everything
and
hosting
everything
seems
like
a
no-go
direction,
because
at
some
point
you
will
notice
it's
just
too
many
things
you
cannot
hold
them
all.
A
I
understand
that
for
like
for
reddish
test,
you
can
probably
have
a
reddish
or
you
know
you
know
darker
song
or
you
can
also
have
a
like
a
sql
server
backhand.
A
B
Even
for
elasticsearch
I
would
imagine
like
we
should
be
able
to
just
like
spin
it
up
in
the
docker
itself,
without
installing
anything
like
really
self-contained,
just
like
other
integration
tests.
But
I
don't
know
the
answer
like
whether
we
want
to
do
it
for
like,
like
aws
or
gcp,
or
things.
B
C
A
I
I
agree
so
back
to
cgio's
example.
I
think
for
elastic,
like
the
self-condensing
would
work
for
some
scenario,
like
you
mentioned
like,
if
you
think
you
want
to
do
elastic
with
integrated
authentication
with
a
different
authentication
provider,
and
that
thing
might
not
give
you
some
emulator
like
you
want
to
do
a
like
facebook
integration.
B
Yeah
yeah,
I
think
like
we
are
probably
not
yet
there
like.
We
are
just
like
in
a
state
we're
bringing
this
ripple
back
to
a
running
state
from
seemingly
abandoned
state.
So
it's
something
which
we
want
to
come
back,
but
I
think
we
can
afford
to
like
wait
a
little
bit
more
on
that,
let's,
let's
like
continue
to
make
progress
like
because
present
has
made
a
lot
of
progress
in
last
couple
of
weeks.
B
So,
let's
get
to
the
state
where,
like
this
repo,
is
completely
and
broke
from
releases
even
unblock,
there
are
like
specific
things
which
this
repo
is
waiting
for:
the
main
reporter
ship,
so
yeah,
I
would
say:
let's
just
focus
on
that,
probably
for
another
two
or
three
weeks
and
start
actually
shipping
new
gates
from
this
repo
then
come
back
and
see
like
what
should
be
the
right
approach
for
integration
test.
It's
definitely
important,
but
like
one
level
less
important
than
the
priority
of
bringing.
A
B
Yeah
sure
yeah
and
one
last
thing
about
the
same
topic.
Last
week
we
decided
that
we'll
try
to
create
a
separate
github
group
for
having
separate
maintenance
and
approvers
for
the
main
repo
and
country
proposal,
with
the
intention
of
like
adding
more
proverbs
and
maintenance
to
the
contributor
like
prashant.
Did
you
get
it
oh
actually,
for
this
year?
Let's
ask
again:
is
it
something
which
you
could
do
like
creating
a
new
group
and
ascending
people
to
it.
E
E
B
B
Do
we
have
okay?
We
don't
have
it's
listed
here:
okay,
yeah,
let's
add
it.
Who
are
the
owners,
and
this
is
one
yeah.
It
says
the
same
one.
So
we
need
to
like
use
the
new
group
here
instead
of
the
same
group
from
the
main
report
again.
C
Very
simply,
yeah.
I
think
we
should
always
also
have
like
approvers
for
different
pro
yeah
for
sub
directories.
B
Yeah,
but
my
first
concern
was
like
to
give
prasanth
like
write
access,
because
that's
the
only
way
he
can
validate
their
workflows.
You
cannot
do
that
unless
you
have
right
access,
you
cannot.
Can
someone
share
the
group?
Where
is
that
cool?
B
B
Okay,
so
there
are
two
groups
here
which-
and
it's
currently
sealed
with
the
same
members
as
the
main
one
right.
You
said
how
to
set
up
yeah
looks
like
the
same
yeah.
Would
you
like
expect
this
to
be
the
same
state
going
forward,
or
should
we
just
open
it
up
and
if
anyone
is
willing.
B
Let
them
be
maintainer
for
the
country,
people
and
like
keep
keep
it
like
really
separate.
Of
course,
there
can
be
common
people,
but
like
any
thoughts
on
that,
I
think
one
of
the
thing
which
we
discussed
was
like.
We
create
an
issue
asking
people
who
are
willing
to
be
maintainers,
and
then
we
can
add
them
to
either
a
prover
or
maintainer
group
in
the
counter,
independently
of
the
main
repo.
D
I
think
you
can
start
with
with
that
state
and
add
prashanth
and
then
go
with.
I
mean
you'll
figure
it
out
as
we
go.
I
don't.
I
don't
think
we
need
to
come
up
with
a
fund
right
now.
Okay,.
C
B
Yeah
we
have
that
link
in
the
issue
in
the
contributor
about
that
yeah.
Let's
follow
that
initially
as
like
we'll
stick
to
the
original
plan,
we'll
do
what
collector
is
doing
initially
and
as
it
grows,
we'll
we'll
figure
out
the
plan
on
like
probably
splitting
or
whatever
that
be
when,
when
we
reach
there,
okay
yeah
with
that,
like
we'd
like
to
I
think
carlos
has
joined
from
hello,
hello
boom,
then.
B
Said
send
remainder,
I
don't
think
he's
joining,
but
at
least
we
have
carlos
and
sagi
sorcerer
from
the
pc,
so
we
can
now
focus
on
the
1.0
release.
So
what
changed
since
last
week
is?
We
were
originally
planning
to
release
1.0
as
soon
as
the
specs
were
marked
stable,
so
that
part
is
done
same
open
elementary
tracing
spec
for
api
sdk,
the
source
and
environment
variables
are
marked
stable.
So
I
was
under
the
impression
that
that
means
we
are
not
blocked
from
the
spec
standpoint.
B
All
we
need
to
do
is
like
do
our
own
due
diligence
and
do
the
release,
but
it
turns
out
it's
like
tc
is
proposing
a
new
mechanism.
I
don't
know
yet
what
that
is.
I
was
told
it
would
be
officially
announced
like
tomorrow,
like
wednesday
and
we'll
be
like
every
language
will
be
doing
a
checkplace
checklist
kind
of
thing.
Do
you
satisfy
all
these
needs?
If
yes
go
ahead,
otherwise
block?
B
That
was
the
initial
understanding
I
have,
but
it's
not
yet
clear
what
that
process
would
be,
and
I'm
waiting
for
that
to
happen.
Both
then
said
it
would
be
tomorrow,
but
that
I
said
another
thing
which
was
agreed
was
people
from
tc
would
review
the
code
and
raise
any
issues
which
they
consider
important.
So
we
do
have
like
some
issues
like
borden,
and
I
spent
like
some
time
yesterday
and
he
opened
a
few
issues
and
it
looks
like
carlos
also
tried
to
open
some
issues
earlier
today.
B
So
basically,
the
ask
for
like
these
communities.
What
do
we
do
with
the
release
plan?
Like?
Should
we
like
try
to
address
each
of
these
issues,
release
another
rc
and
then
wait
and
eventually
release
1.0
at
a
future
date,
or
should
we
stick
with
original
plan
of
releasing
1.0
and
any
issues
which
are
opened?
We
need
to
go
and
individually
mark
them
as
blocking
one
dot
or
release
or
not
blocking
by
not
working.
B
I
mean
we'll
still
proceed
to
1.0,
even
if
we
have
non-bugs
but
we'll
address
it
in
the
coming
releases
like
1.11.2,
and
if
some
of
those
requires
a
breaking
change,
then
we'll
follow
the
typical
plan,
like
let's
assume
that
we
found
this
bug
like
six
months
from
now,
so
whatever
we
would
have
done
at
that
time.
We
just
do
it
now
itself,
so
we
treat
it
as
bug
and
if
it
requires
breaking
change,
for
example,
this
might
require
like
breaking
change
to
fix
it.
B
So
we'll
do
the
standard
process
we'll
mark
it
in
let's
say
1.5
was
absolute
and
ship
the
I
mean
completely
remove
it
in
2.0
whenever
2.
comes
so
that's
the
approach
which
I
I
would
like
to
propose.
But
since
there
are
more
folks
you
know,
I
want
to
hear
a
thought
process
from
others.
What
what's
your
take
on
this
and
is
there
like
any
any
opposition
from
tc?
B
We
had
rc
out,
for
I
think
three
months
october
end
is
when
we
released
the
first
rc
and
we've
been
like
holding
off
from
any
major
changes,
because
we
initially
assumed
we'll
do
one
daughter
very
soon,
but
we
put
it
now.
We
are
almost
at
february,
so
we
have
been
like
funding
or
delaying
all
the
major
work
until
like,
since
we
are
very
close
to
the
one.
B
So
my
my
take
is
we
should
release
1.0
with
with
the
non-issues
as
is
and
address
some
post
1.0,
because
we
already
have
rcs
available
for
users
in
like
three
months.
None
of
the
issues
which
are
opened
recently
are
reported
by
the
user,
mean
it's
it's
of
course,
good
bug.
It
is
a
bug,
it's
a
violation
of
the
spec.
However,
things
like
this
were
never
probably
in
from
the
actual
users
who
use
the
rc1
bits.
B
I
mean
I'm
not
saying
they're
not
bug
they
are
bugs,
but
what
I'm
saying
is
it
should
not
block
us
from
releasing
1.0,
because
that
way,
we'll
continue
to
like
satisfy
the
needs
of
our
users
rather
than
making
changes
now
and
delaying
it
like
further,
like
forget
and
like
carlos,
are
here
like
if
you
want,
you
can
comment
on
it.
Otherwise,
I
need
to
ask
everyone
like
what
are
their
opinions
on
this,
because
this
is
such
an
important
decision.
F
Basic
question:
any
of
them,
if
we
fix
after
1.0
our
breaks
from
the
user
perspective,
that
you
need
to
go
back
to
gold.
B
Well,
some
of
them
is
like,
for
example,
like,
let's
take
like
one
as
the
example,
so
this
issue
is
about
b3
propagators
packaging,
so
the
spec
says
it
should
be
a
separate
package,
not
part
of
the
same
core
sdk
with
the
current
implementation
is
b3.
Propagator
is
in
the
same
place
as
the
trace
context,
so
it
is
part
of
the
same
package
so
fixing
this
would
mean
remove
the
b3
from
the
sdk,
keep
it
as
a
separate
package.
F
But
in
principle
this
one
is
just
reimporting
report
importing
a
new
package.
B
Right
yeah,
it's
not
a
code
bug.
It's
just
I
mean
this.
One
specifically
is
not
a
code
book.
It
is
just
a
like
packaging
related
issue.
Let's
open
like
one
more
yeah.
A
A
One
way
of
doing
this
is
we
ship
the
b3
propagator
as
it
is
in
the
api,
because
it
has
been
there
for
for
more
than
a
year,
let's
keep
it,
and
then
we
introduce
a
separate
package
that
has
the
b3
propagator
we
can.
We
can
either
duplicate
the
code
or
do
some
smart,
like
redirection,
binding
thing
and
before
2.0
we
start
to
tell
people
we
mark
the
e3
propagator
in
the
api
as
deprecated,
but
all
the
like.
The
signature
interfaces
are
the
same.
A
D
Yeah
I
will
like
I
see
alan
made
a
thumbs
up
and
thumbs
up
for
me
as
well.
I
think
it's
pretty
fair,
and
even
if
issue
like,
if
discussion
still
is
experimental,
we
need
to
do
what
best
for
net
customers
yeah.
So
we
can
ship
what
we
have
now
and
then
specification
is
just
the
way
to
formalize
and
unify
across
all
the
sdks.
Not
so
not
the
governor's
body
per
se.
D
So
we
need
to
do
what
best
for
our
customers
and
what
will
complete
the
package
for
our
customers,
so
they
can
use
it
efficiently.
D
I
bet
there
is
some
unexpected
behaviors
that
will
be
different
in
python
and
dotnet,
like
maybe
some
axis
plan
is
not
propagated
the
same
way
or
like
some
like
weird
situation,
with
like
how
you
like
mutate
resources
and
eventually
it
will
be
documented
one
way
and
some
like
sdk,
either
python
or
sdk
or
c-sharp,
I'm
just
speaking
on
two
random
languages,
we'll
we'll
need
to
change,
and
we
will
deal
with
this
change
as
time
will
come.
G
Carlos,
do
you
have
some
guidance
yeah,
so
basically,
my
my
impression
is
that
all
of
these
issues
that
me
and
mostly
booked
and
have
been
feeling
should
be
taking
as
suggestions
or
recommendations
of
changes
that
you
guys
can
consider
doing
and
yeah.
Actually,
I
was
a
little
bit
afraid
myself
that
you
guys,
having
waiting
for
a
long
time
to
release
and
now
that
these
changes
were
trying
to
make
you
do
they
may
not
may
end
up
breaking
you
and
you
know
lose
stability
so
much
so.
A
Yeah,
so
just
thank
you
and
just
one
example.
I
want
to
have
some
feedback
from
from
everyone
here.
So
in
this
morning,
in
the
spec
meeting
we
mentioned
the
tris
id
ratio
based
sampling,
we're
going
to
remove
that
from
the
spike.
For
now-
and
hopefully
we
can
add
it
back
three
weeks
later,
trying
to
clarify
everything.
The
reason
we
want
to
remove
that
is
not
because
it's
wrong
or
anyone
is
like
is
doing
the
wrong
direction.
It's
just
because
we
have
that
in
the
spec.
We
also
mentioned
the
actual
algorithm.
A
Only
one
percent
of
the
chance
we
realize.
Oh,
we
really
want
to
change
the
algorithm,
and
that
would
be
a
surprise
for
everyone.
In
this
case,
I
think
for
this
project.
I'm
I'm
thinking,
there's
one
possible
way.
We
take
the
one
percent
risk,
we're
saying
we're
not
going
to
remove
the
trace
id
ratio
based
assembler.
A
And
if
that
one
percent
of
unfortunate
thing
happened,
we'll
have
to
admit
that
and
make
a
breaking
change
and
we'll
point
that
to
2.0,
but
given
the
chance
is
very
low,
I
think
the
outcome
might
be
better
because
99
of
the
chance
we're
going
to
save
a
lot
of
work
and
not
not
try
to
thrust
the
the
current
work
stream
and-
and
as
I
mentioned
here,
you
start
to
see
it's
not
a
very
strict
science.
It's
something
like
like
based
on
probability.
B
I
think
tracer
is
a
good
example,
where,
like
chances,
are
very
low
that
we'll
never
have
to
make
change.
So
it's
probably
okay
like
another
set
of
issue.
It's
not
really
a
it's,
not
an
issue
about
the
spec
itself.
It's
just
that
we
did
not
follow
the
spec
from
the
first
place.
So,
for
example,
this
issue
is
a
bug
I'll,
create
it
as
a
bug
where
expect
says
creating
a
key
is
the
key
is
not
that
indifferent.
You
can
read
the
same
key.
B
This
book
size
thing
like
white,
never
like
context
being
an
important
thing
in
respect,
then
I
realized,
like
dotnet,
does
not
rely
on
this
context
for
propagation,
like
we
have
activity
has
its
own
way
of
propagating.
We
don't
really
use
it.
The
only
users
of
this
are
like
sdk
itself
to
do
like
a
simplest
thing
to
prevent
live
loop.
So
can
you
release
okay,
even
though
it
is
a
bug
it?
It
should
not
like
just
block
us.
B
We
should
just
move
forward,
take
it
as
a
bug,
so
there
are
like
many
bugs.
Oh
I
mean
we
have
like
two
or
three,
not
not
a
lot
which
are
like
opened
in
the
last
day,
but
then
there
is
a
another
sort
of
thing
which
is
like
known
issues
with
respect
to
the
complaints
which
are
arising
out
of
the
fact
that
we're
using
activity
instead
of
span,
which
has
a
slightly
different
semantic.
So
all
those
things
are
already
marked
as
like
minus
in
the
spec
compliance
metric.
B
So
I
mean
if
that
metric,
that
improves
to
have
like
more
items.
Of
course,
we'll
have
like
more
negatives
here
like
we
are.
Probably
if
there
is
an
entry
in
the
spec
compliance
matrix,
which
says
b3
propagator
should
not
be
in
the
api.
Yeah
I'll
have
to
put
a
minus
mark
there
for
dot
net,
but
once
again
like,
we
have
like
all
sort
of
old
categories
of
issues,
but
so
far
nothing
from
what
I
hear
from
people.
B
F
Yeah,
I
I
just
told
you,
I
think
the
only
only
concern
because
so
far
the
examples,
the
trace
id
the
context
I
I
agree.
100
kind
of
the
only
thing
that
comes
to
my
mind
is
because
the
semantic
version,
if
we
change
the
surface,
that
the
user
has
to
change
the
api
and
the
actual
code
that
perhaps
we
should
try
to
consider
fixing
before
you
know,
but
the
stuff
that
I
saw
so
far.
None
of
them
qualifies,
I
think
package
just
changing
package.
Redirecting
is
totally
fine.
You
know
so
all
that
that
stuff.
F
A
One
thing:
I'm
thinking:
if
we're
going
to
break
some
api,
that
everyone
would
be
using
that
that
seems
to
be
the
most
dangerous
thing
and
I
I
would
probably
try
to
be
slow
if
it's
something
that
requires
people
change
a
package
like
package
name
in
one
configuration
you
can
imagine
most
of
the
people
when
they
set
up
the
project,
it
could
be
multiple
projects
but
sharing
one
single
nuget
configuration
file,
so
that
seems
to
be
a
less
concern
and
there's
a
balance.
A
So
if
we
are
going
to
change
some
icd
configuration
that
requires
people
to
change
the
initialization,
they
need
to
change
every
project.
If
they
have
a
100
project,
they
need
to
change
100
lines
of
code,
so
my
my
personal
bar
would
be
if
we're
going
to
change
the
instrumentation
api.
That
means
if
customers
is
doing
a
million
lines
of
instrumentation,
they
got
to
change
everything.
A
B
Yeah,
so
would
should
we
like
consider
going
through
the
issues
one
by
one
or
is
that
something
which
we
can't
resolve
like
offline
and
like.
B
Yeah,
but
I
think,
let's
hear
from
anyone
else
like
if
there
are
different
thoughts
like
allen,
probably
is
the
only
other
guy
who
hasn't
spoken
so
ellen
like?
B
Can
you
share
your
thoughts
as
well,
like
I
don't
think
michael
who
is
the
other
maintainer
is
going
to
join,
so
if
you
can
share
your
thoughts
as
well,
that
would
be
great
because,
like
I'm,
assuming
that
we
are
making
the
decision
today,
not
like
next
week
or
the
week
after,
we
are
making
the
decision
today
review
the
remaining
issues
offline
and
if
the
bar
does
not
meet
blocking
1.0,
we'll
go
and
release
1.0
this
week,
probably
tomorrow
or
the
day
after.
B
E
Yeah
sure,
no,
I
I'm
in
agreement
with
with
everything
that's
been
said
so
far.
I
feel
pretty
good
about
things,
at
least
from
the
standpoint
of
the
issues
that
have
been
filed
so
far.
I
don't
see
anything
there.
E
That's
maturely
concerning
my
understanding
is
that
maybe
more
issues
will
flow
in,
but
you
know,
I
guess
we'll
we'll
talk
if
something
big
comes
up
but
again,
like
you
know,
as
has
been
mentioned,
there's
actually
customers
that
are
using
this
in
in
production
today
and
I
feel
like
if
we
encountered
anything
major,
I
think
it
would
have
come
up
by
now.
So.
B
Yeah
I
mean
we've
been
very
careful
in
the
last
two
months,
since
we
already
we're
very
close
to
one
daughter.
We
are
just
telling
people
hey
this.
Pr
is
good,
but
let's
not
merge
it
until
after
we
we
go
one
daughter
just
to
avoid
any
like
major
changes
so
like
we
should
be
able
to
unblock
them.
Once
we
do
the
1.0,
because
we
can
add
incremental
changes
or
so
yeah.
B
Anyone
else
to
share
comments.
We
heard
from
extra
gay
carlos,
like
polo
and
really
are
proverbs
as
well,
so
we
heard
from
ellen
and
myself
so
if
there
are
no
concerns
I'll
market
us
that
the
decision
is
to
release
one
daughter
like
it's
on
me
and
I
learned
to
review
any
pending
issues
which
we
consider
talking,
but
that
I
said
it's
going
to
be
like
1.0
like
tomorrow.
It's
just
logistics
then
clicking
some
buttons.
B
A
Yes,
look
at
the
way.
I
have
one
question,
but
you
go
off.
You
go
first
really,
oh!
So
so
please
send
a
message
in
the
github
channel
and
also
notify
all
the
other
maintainers
who
are
not
able
to
join
this
time.
Just
make
sure
like
you
give
them
high
value
for
you.
You
move
on
sorry,
colors
yeah.
My.
G
G
A
But
somewhere
it's
there
yeah,
so
the
spec
merge
is
a
is
a
precondition
because
we
want
that
has
a
snapshot
to
communicate
to
people
with
the
donut
release.
What
other
features
we
support
and
which
one
in
the
metrics
is
a
minus?
Without
the
pr
get
merged
and
announce
100
respect,
we
won't
be
able
to
communicate
that
yeah.
So
this
is
a
prerequisite.
B
Like
there
is,
you
know
lining
we.
We
were
just
waiting
for
this
to
happen
for
so
long,
so
this
is
still
a
blocker
for
us,
but
from
what
I
heard
this
morning
as
well,
the
plan
is
to
get
it
merged,
like
grails
home,
like
today,
itself.
G
B
This
is
only
pr
which
we
are
waiting
on
so
once
this
is
in
I'll
mark
that,
like
dotnet
1.0,
is
implementing
one
daughter
of
the
spec
as
well
perfect.
Thank
you.
B
So
I
don't
have
any
other
topics
related
to
1.0
release,
but
I'll
quickly,
update
folks
who
are
using
the
metrics.
So
this
does
not
contain
matrix
and
matrix
would
be
a
separate
pre-release,
which
is
already
in
my
get.
So
if
you
are
like
currently
using
it
and
you
want
to
unblock,
please
use
the
daily
build
from
my
gate.
It
contains
all
the
matrix
code
which
we
previously
had
in
the
main
once
the
1.0
release
is
complete.
I
like
because
the
workflow
is
not
automated.
B
B
Now,
since
we
have
few
minutes
left,
we
can
discuss
if
there
are
any
open
questions
or
any
other
concerns,
or
anything
like
that.
I
mean
we
did
discuss
few
items
yesterday,
but
probably
something
which
we
can
just
solving
prs,
not
denoting
this
meeting.
B
But
are
there
any
other
questions
which
I
mean?
The
first
thing
I'm
going
to
do
is
I'll
release
like
rc4
like
today,
just
to
make
sure
the
process
is
still
smooth,
validate
that
the
packaging
and
or
the
overall
flow
is
working
and
then
release
the
actual
1.0
once
the
main
pr
in
the
spec
is
ready,
so
that
we'll
get
like
one
more
day
to
really
validate
that
versioning
and
everything
is
still
correct.
B
We
will
validate
it
in
rc3,
because
between
rc2
and
rc3
we
only
promoted
the
core
package
with
which
we
are
ready.
So
we
already
figured
out
how
to
work
in
packages
independently,
but
this
is
like
one
final
trial
run
by
doing
a
rc4
today,
we'll
once
again
validate
that
code
packages
are
in
good
shape
and
we
can
continue
to
use
like
instrumentations,
which
are
still
going
to
be
in
rc2.
E
B
Yes,
so
even
today
I
can,
I
think
I
closed
some
projects.
So
if
you
are
using
an
instrumentation
rc2
that
depends
on
any
version
of
the
core
sdk
greater
than
rc2.
So
it
should
not
be
an
issue
that
the
core
stick
is
moving
ahead
to
1.0
and
instrumentation
is
not.
You
can
still
continue
to
use
the
instrumentations.
It's
just
that
the
instrumentation
itself
is
not
1.0,
but
it's
it
would
be
1.0,
but
there
should
be
no
issue
upgrading
because
it
already
has.
F
Quick
question
kind
of
related
to
the
instrumentations
peptide
means
heard
this,
but
any
plans
to
move
then
through
the
contributor
they
are
staying
on
the
core
ripple.
B
As
of
now,
yes,
I
mean
they
will
remain
in
here,
but
once
we
figure
out
the
like
shape
and
long
term
line
for
the
country
people.
Yes,
at
that
stage,
we
can
move
everything
from
this
repo
which
are
not
required
by
the
spec.
So
that
means
all
the
instruments
we
have
like
how
many
one
two
six
instrumentation
and
one
extension:
it's
not
really
a
instrumentation,
it's
just
a
helper
for
hp
net
core.
So
this
can
move
out
of
the
main
ripple.
B
But
I'm
not
like
hurrying
to
do
that
because
right
now
they
are
like
tightly
integrated
and
we,
the
current
maintainers,
are
like
maintaining
these
codes,
but
once
we
move,
we
want
to
like
wait
for
that
process
to
be
really
established.
Understand
is
already
doing
that.
Work,
I'm
helping.
So
once
that
place
is
like
really
stable.
We
have
done
like
a
couple
of
releases.
We
would
be
adding
out
all
the
fine
details
at
that
stages.
We
can
move.
B
Okay,
follow:
is
there
anything
which
you
want
to
share
from
the
auto
instrumentation
world.
F
There,
because
I
think
one
interesting
thing
there
is
that
we've
been
kind
of
trying
to
solve
the
activity
source
issue.
That
brings
a
lot
of
difference
to
the
code
base
and
since
that's
progressing
very
slowly,
we
decide
to
take
a
different
approach
to
start
people
using.
So
since
december.
F
We
start
to
discuss
about
having
the
outer
instrumentation
work
without
the
activity
source
for
now,
so
that
will
bring
us
to
kind
of
really
start
to
adopt
the
symmetrical
conventions
and
do
other
stuff
for
open,
trace,
open
telemetry,
and
then
we
can
really
start
to
have
what
we
want
to
call
prayer
releases
that
people
can
start
to
use,
while
in
parallel
we
attack
the
active
source
issue.
F
So
I
think,
for
the
next
three
months
by
kind
of
end
of
april,
we
should
have
a
version
that
we're
going
to
be
calling
prerelease.
That's
not
going
to
be
integrated
with
the
activity
and
actually
source
yet,
but
is
auto
instrumentation
following
the
semantics
of
open
telemetry.
B
F
Right
now,
unfortunately,
we
can't
have
any
synergy,
because
the
the
instrumentations
inside
use
totally
different
types.
You
know,
so
that's
why
we
prefer
to
call
this
a
pre-release,
so
we
can
do
that
work
and
have
some
automation,
but
at
that
time
of
the
priorities,
yet
until
we
build
the
wrapper
that
can
do
with
the
active
source.
Unfortunately,
we
can't
have
synergy
with
the
sdk.
F
B
Yeah
that
probably
ends
today's
meeting.
If
no
other
topic,
we
can
end
ten
minutes
early
and
see
you
again
next
week.
B
Okay,
thanks
carlos
and
sergey
for
joining
us
yeah
thanks
everyone
else
for
sharing
your
thoughts,
so
it
looks
like
we'll
be
doing
the
release
very
soon.
So
thanks
for
waiting
patiently
and
I'll
update
the
notes,
because
I'm
very
bad
at
typing,
while
I'm
talking
so
I'll,
just
update
it
in
few
minutes
thanks.
Alright
yeah
thanks
everyone
bye-bye,
you.