►
From YouTube: 2021-03-03 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
A
Hey,
let's
start
it's
like
two
minutes
past
four,
so
we
can
go
ahead
and
start
yeah.
Please
add
your
names
to
that
in
this
list,
we'll
go
over
the
very
short
agenda,
so
the
first
update
is
about
the
contrib
repo.
So
I
created
an
issue
here,
asking
explicit
ack
from
the
current
approvers
and
maintainers
to
like
to
confirm
that
they
are
willing
to
be
a
maintainer
and
approver
for
the
counter
preparation.
So
we'll
keep
that
issue
open
for
one
more
week
to
give
everyone
a
chance
to
look
at
it.
A
We
hope
that
all
the
maintainers
and
approvals
would
still
remain,
but
it's
up
to
them
to
make
that
final
call.
So
let's
come
back
to
it
by
next
meeting
and
we
can
also
add
like
more
maintenance
or
approvals
to
the
country
projects
next
week
after
we
know
who
all
are
going
to
be
working
as
a
maintainer,
slash
approval.
A
That
also
brings
is
very
much
related
to
the
next
question,
which
I
think
prashant
posted.
Oh
yeah,
prashant
like.
Can
you
share
what?
What
exactly
is
the
thing
which
you
are
asking.
B
Yeah
yeah,
so
I
had
that
if
you
can
open
that
issue,
which
kind
of
started
the
discussion
for
the
proposal
of
separate
projects
within
the
control
repo.
So
a
few
things
that
I
mentioned
there
that
we
decide,
we
need
to
decide
on
the
project
structure
like
what
things
when
someone
is
contributing
a
new
project.
B
They
should
have
this,
how
the
source
code
the
test
and
the
workflow
are
to
be
laid
out,
and
then
a
few
things
were
about
the
ownership
of
that
which
you
have
already
created
an
issue
for
so
other
than
laying
out
the
releasing
process
for
maintainers
and
also,
I
think
we
had
a
discussion
earlier
about
updating
one
of
the
sections
on
the
contrib
contributing
sections.
B
Is
there
something
else
that
anyone
feels
is
left
on
this
proposal
issue?
And
is
it
good
to
be
closed
because
otherwise.
A
A
Yeah
so
at
least
for
phase
one,
we
are
good,
assuming
you
do
the
pr
which
I
think
we
briefly
discussed
this
last
week
about
like
like.
If
someone
is
submitting
a
brand
new
pr,
we
need
to
modify
the
codeones
file
to
include
the
contributors
name
as
the
owner
for
that
new
component,
but
that
I
said
I
I
don't
really
see
anything
I
mean.
Of
course
we
may
have
more
issues
coming
up
later,
but
as
of
now,
that
should
close
the
initial
thing.
A
A
Everything,
so
you
got
it
correct.
The
two
things
left.
One
is
updating
this
to
include
that
if
you
are
submitting
a
brand
new
project
list
yourself
as
the
code
owner
in
the
code
owners
file
and
second
is-
we
need
to
like
do
a
release
like
an
actual
release
with
one
of
the
components.
B
We
did
for
the
aws
one
and
actually
came
across
few,
actually
not
few
just
one
hiccup
during
the
instrumentation
aws
release.
B
So
I
think
it's
good
for
everyone
to
know
that
how
many
versioning
works,
because
we
released
the
extensions
project
first
and
then
the
instrumentation
project
had
a
pro
project
reference
to
the
extension
so
when
it
tries
to
build
again,
if
the
extensions
tag
is
not
the
latest
one,
the
menuer
tool
tries
to
calculate
the
new
version
with
the
with
the
height
difference
from
the
latest
commit
which
was
kind
of
messing
up
the
versioning.
B
So
we
had
to
kind
of
break
the
project
dependency
and
switch
to
the
package
dependency
for
instrumentation.
So
it
was
yeah.
It
was
kind
of
not
not
a
very
smooth
what
you
call
experience,
so
I
think
for
releasing
yeah,
it's
good
to
link
to
how
many
works
and
what
things
are
absolutely
critical
for
getting
the
you.
A
C
B
A
Oh,
I
think
if
that
is
the
case,
then
we
should
see
if
we
can
make
the
tag
prefix
exactly
the
same
for
both,
then
they
will
be
like
released
in
one
shot.
I
think.
B
They'll
get
the
same
version.
I
I
kind
of.
I
was
expecting
experimenting
with
this
in
my
fork,
so
there
are
two
ways
so
either
we
have
a
common
prefix
for
both
the
instrument,
aws
components
or
we
do
like
two
tags
pointing
to
the
same,
commit
using
the
follow
tags.
The
get
follow
tags
you
see,
so
in
that
case,
both
the
tags
would
be
on
the
same
height
and
would
be
the
latest.
A
So
if
you
were
to
follow
what
we
did
in
the
main
ripple,
I
think,
like
you,
don't
need
to
do
the
package
reference.
You
can
keep
it
projector
friends,
but
do
a
common
prefix
for
both
the
aws
components,
so
they'll
get
the
same
version.
Okay,
it's
very.
B
A
To
what
we
have
in
the
main
tripod
like
we
released
a
bunch
of
thing
in
one
shot,
so
let's
take
one
of
them.
For
example,
so
zipkin
was
released
along
with
the
sdk
and
it
has
a
project
reference
to
the
sdk
and
the
prefix
is
like
core.
So
everything.
B
A
So
you
can
follow
the
same
thing
for
all
aws
components.
So
if
you
have
x-ray
extension
and
instrumentation,
you
can
just
prefix
it
with
like
something
like
open,
telemetry,
contrib,
hyphen,
aws
and
yeah.
Then
you
can
keep
the
project
reference.
B
Not
time
yeah
that's
very
use
based.
If
you
have
a
co-dependent
projects,
then
the
best
strategy
is
to
release
them
together,
because
then
they
all
get
the
same
version
and
what
what
you
would
expect.
A
Yeah
yeah,
if
you
can
just
clarify
that
in
your
country,
but
it
shouldn't
be
an
issue
for
like,
for
example,
mass,
transit
or
elasticsearch,
because
they
are
like
standalone.
They
are
not
depending
on
anything
else.
From
this
project
itself,
I
mean
this
cycle
itself,
yeah.
B
Absolutely
so,
actually
I
have
a
question
on
that.
So
when
there's
a
pro
it's
kind
of
like
a.net
question,
so
when
we
have
a
project
reference
versus
a
package
reference,
is
there
a
more
difference
to
how
the?
If
we
have
a
project
reference,
then
I
understand
that
the
dependent
the
depending
project
gets
built
along
with
the
all
the
dependencies
and
if
there's
a
package
reference,
there
is
no
building
just
different
pulling
in
of
the
nougat
package
right.
Is
there
any
more
difference
to
it
than
that.
A
Yeah,
the
actual
new
spec
will
be
different
as
well
like.
If
you
have
a
project
reference,
then
it
will
be
listed
as
greater
than
or
equal
to,
I
believe
in
the
new
spec,
but
that
is
something
which
we
can
easily
try
out
and
confirm,
but
the
reason
why
I
would
prefer
to
keep
project
references
you
will
instantly
know
if
you
are
breaking
anything.
A
Yeah
the
same
principle
in
the
code
reports
in
the
main
repo,
all
core
components:
they
are
like
tightly
coupled
to
the
actual
sdk,
so
they
have
a
project
reference
to
the
sdk.
So
if
we
ever
make
any
change
in
sdk
which
might
break
them,
we
will
know
instantly.
A
And
the
new
spec
one,
I
think
you
can
just
do
a
like
hello
world
and
see
what
what
exactly
is
generated
thing.
If
you
explicitly
list,
I
mean,
if
you
have
a
project
reference
it
by
default,
translate
into
the
greater
than
or
equal
to
version
dependency
in
your
spec.
B
A
Yeah,
so
you
don't
have
like
a
lot
of
flexibility,
yeah,
whatever
is
generated,
you
just
have
to
stick
with
that,
but
if
it's
package
reference
you
can
do
like
like
like
rangers,
I
think
it's
somewhere
here.
We
yeah.
B
Like
wild
card.
A
Yeah,
but
for
project
it's
like
auto
generator.
We
tried
to
find
a
way
to
override
it.
It
was
not
very
straightforward,
so
we
just
gave
it
gave
up.
B
A
A
I
think
eddie
and
I
tried
like
some
option,
but
it
was
all
like
really
complex
things,
so
we
just
decided
it's
best
to
use
the
simple
approach:
it's
not
a
bad
deal
because
we
consider
them
as
one
like
core
thing,
so
they
can
version
together.
A
E
You're
saying
that
these
two
packages
are
very
tightly
coupled,
so
I
understand
one
package
provides
a
way
to
utilize,
aws,
specific
headers
and
another
bundle
fit
together
with
all
other
experts
and
such
do.
We
see
scenario
when
people
want
to
use
just
headers
piece,
and
is
it
something
that
will
be
more
stable
and
will
be
released
less?
B
So
yeah
so,
like
you
said
so
one
package
that
is
just
for
the
trace
headers
that
that
we
don't
expect
to
change
a
lot
over
time.
So
we
won't
probably
be
needing
to
release
it
more
often,
but
the
instrumentation
dot
aws,
which
is
the
aws
client
instrumentation,
that
we
that
definitely
would
be
undergoing
some
changes,
adding
new
attributes
and
other
stuff.
So
I
don't
see
a
very
specific
need
to
bundle
them
together
and
it's
mostly
because
of
simplifying
the
release
process
that
that
has
to
be
like
releasing
together
for
both
of
them.
E
Because
I
mean
if
somebody
would
take
a
dependency
on
aws,
specific
headers,
just
for
the
sake
of
running
on
aws
but
exporting
blocks
to
some
other
place,
then
it
may
be
a
little
bit
concerning
that
the
version
of
trace
headers
changes
so
often
just
because
it
was
bundled,
but
I
I
don't
have
certain
strong
feelings
here.
I
and
I
don't
even
know
how
many
people
would
need
that
scenario
I
just
like.
If
you
don't
need
them,
bundle,
don't
make
them.
Bundled
that's
what
I
tried.
B
We
only
need
that
bundle.
So
if,
if
someone
is
using
instrumentation,
they
would
definitely
need
the
extensions
aws
extension,
the
trace
header
package.
So
that's
a
that's
a
strong
dependency.
E
I
don't
care
about
that
part
like
bundling
is
aside.
I
I'm
just
kidding
curious,
like
if
somebody
using
jaeger
for
viewing
traces,
but
I
still
want
to
use
trace
headers
from
this
like
smaller
package,
if
they
bundle
together,
every
change
to
exporter
will
also
up
the
version
for
for
this
trace.
Header
thingy
and
the
person
may
not
need
this
version
bump
every
time
that,
like
expert
changes,.
E
E
Have
to
bundle
just
don't
bundle,
don't
try
to
say.
B
A
There
is
an
exception
to
some
of
them,
which
we
are
still
discussing
in
some
peers
like
there
is
a
need
to
suppress
the
trace
from
that,
then,
in
that
case
it
requires
access
to
the
surplus
flags,
which
is
only
in
sdk,
but
that
I
said
all
instrumentation
should
simply
depend
on
the
api,
which
is,
which
means
this.
A
This
reference
of,
like
instrumentation,
referring
to
extensions,
might
might
not
be
required,
like
I
have
to
like
look
at
it
one
more
time
to
see
whether
it
is
actually
required
to
be
bundled.
But
this
is
something
which
I
think
I
left
a
comment
like
long
back,
but
I
don't
know
what
was
the
status
when
it.
B
Other
than
that,
that's
the
only
thing
that,
even
on
our
end,
we
are
kind
of
debating
so
once
that
is.
That
is
the
discussed
and
like
agreed
upon
that.
That
would
be
a
small
change
for
for
the
instrumentation
package.
E
And
I'm
not
talking
about
reference
like
I'm,
I'm
fine
with
references
from
project
to
project
or
from
package
to
package,
I'm
just
talking
about
using
the
same
tag
for
both
packages,
just
because
they
have
the
same
prefix
that
I'm
trying
to.
A
Yeah,
so
the
current
reason
why
they
are
tied
together
is
because
they
have
a
project
reference
to
each
other,
but
if
there
is
no
dependency
between
these
two
projects,
then
they
can
be
released
like
independently,
like
extension,
can
be
released
like
once
a
very
less
frequently
and
instrumentation
can
keep
release
like
every
week
without
affecting
this.
So
this
would
eliminate
the
problem
which
sergey
is
describing
as
well
right.
B
A
Because
you
would
only
release
like
the
header
package
or
if
there
is
a
change
just
because
there
is
a
change
in
instrumentation,
that
doesn't
mean
like
you
have
to
release
extension,
so
that
should
alleviate
the
concern
with
sake
about
so
the
root
of
the
problem
is,
there
is
a
dependency
between
these
two,
which
should
be
revisited
and
like
avoided,
if
possible,
that
would
like,
as
a
side
effect,
eliminate.
B
Yeah,
so
that's
that's
what
we
have
right
now.
We
have
a
nuclear
dependency
to
actually
bypass
the
issue
that
meanwhile
versioning
was
having
so
yeah
yeah.
A
B
Okay,
okay,
so
for
me
I
would
call
this
out
in
the
releasing
guide
for
the
con
contract.
Reaper.
A
Yeah,
and
will
you
I
mean,
how
did
you
do
the
release
like?
Did
you
like
use
a
script
or
something
which
you
can
like
contribute
back.
B
A
B
B
But
I
feel
that
you
know
that
it
actually
depends
on
the
confidence
level
of
well
when
releasing
for
the
package.
If
we
want
to
automate
the
pushing
to
neoget
step
as
well.
A
Yeah
I
mean
we
should
be
able
to
like
automate
it
and
put
like
breaks
on
it
like.
If
you
can
probably
like
push
or
click
some
button,
we
should
do
the
whole
thing
or
that
button
can
only
do
everything
except
pushing
to
get
your
torque.
A
B
B
So
this
that
script
for
generating
the
change
log,
I
don't
know
how
that
would
fit
into
the
contributory
persons
yeah.
A
B
It
wasn't
yeah
would
be
different,
so
what
we
did?
We
created
a
change
log
in
each
of
the
project
like
aws
project,
and
I
think
that's
that
would
be
a
common
practice
going
forward.
A
Would
it
also
do
the
like,
like
you,
did
the
I'm
just
curious
like
whether
did
you
do
the
actual
github
release
as
well.
D
A
A
Is
it
something
which
you
have
time
to
like
writes,
because
I
want
to
try
it
out
in
the
content
repo
before
we
do
it
in
the
across
all
projects.
B
A
Yeah
but
at
least
documenting
what
you
did
would
be
the
right
first
step.
Second
step
yeah.
We
can
see
if
we
can
automate
it
because
at
some
point
like
we
want
to
release
like
more
packages
from
the
control
paper.
So
we
don't
want
to
do
repeat
the
manual
process
because,
right
now
the
main
repair
has
a
manual
process,
but
it's
more
or
less
okay,
because
we
are
only
releasing
like
once
in
two
months
and
we
release
everything
in
one
shot.
A
A
Yeah
the
last
thing
I
think
it's
just
an
update
from
last
week,
we
merged
the
pr
in
the
main
repo
which
remote
activity
source
adapter,
and
there
are
like
couple
of
pr's
prs
active
in
the
contrary,
proper,
which
is
trying
to
leverage
the
new
feature.
So
one
of
them,
I
think
it's
very
close
to
be
approved
like
elasticsearch
one,
and
then
there
is
a
mass
transition.
So
if
we
can
prove
like
one
of
them
works
without
activity,
source
adapter,
and
that
confirms
the
like
approach.
A
The
last
thing
which
is
being
discussed
is
about
like
it
required
to
achieve
the
feature
called,
suppress
downstream
instrumentation,
which
is
required
in
case
of
elastic
elasticsearch.
A
We
are
still
debating
in
the
main
repo
in
the
pr
like
what
is
the
best
way
to
handle
it
because
to
achieve
suppress
downstream,
which
is
basically
if
elasticsearch
is
using
http
underneath
and
if
a
user
is
enabling
both
elasticsearch
and
http
instrumentation,
they
would
get
two
spans
like
one
representing
the
elastic
search
code
and
one
representing
the
underneath
http.
A
So
many
instrumentations
have
that
flag
to
turn
off
the
underlying
one.
Elasticsearch
is
one
of
them
which
requires
that,
but
to
really
make
that
happen,
it
we
needed
to
make
something
else
public
from
internal.
A
We
are
not
yet
sure
whether
it's
in
the
right
state
to
be
made
public
so
but
that's
a
relatively
smaller
issue,
but
that
that
should
be
the
last
thing
to
unblock
elasticsearch,
but
mass
transit
should
be
working
with.
I
don't.
I
don't
really
think
the
current
version
of
mass
transit
is
having
a
feature
which
suppresses
underneath.
A
B
Sorry,
I
think
I
missed
the
initial
part.
What's
the
problem
or
what's
the
issue
when
instrumentation
uses
the
suppressed
downstream
instrumentation.
A
You
probably
don't
use
the
one
which
is
used
by
this,
so
I'll
show
you
the
excite
one,
which
requires
to
be
which
was
required
to
be
so.
There
is
a
suppress
method
called
decrement
increment.
If
triggered.
This
is
used
by
thing.
It's
it's
relevant
if
you
have
a
if
you
are
an
instrumentation
which
is
built
on
top
of
something
else,
which
also
has
an
instrumentation
right.
A
A
C
D
A
But
that's
done
only
for
the
purpose
of
the
suppress
underneath
the
instrumentation
so
that
whole
flag
or,
like
this
method,
was
introduced
to
support
the
scenario
in
grpc
net
client,
which
required
it
to
suppressor
underneath
one.
They.
A
Okay
in
combination
of
that,
so
in
so,
if
okay,
let
me
try
to
open
the
grpc
one,
so
it
codes
the
it
holds
the
ender
scope,
one
under
suppression,
scope
and
if
you
do
not
have
the
I
mean,
if
the
diagnostic
listener
is
not
modified
to
call
increment
requirement
trigger,
then
it
will
prevent
the
stop
from
being
called
I'm
trying
to
recollect
the
issue
from
like
some
time
back,
but
it's
kind.
D
B
A
What
is
being
made
public
or
being
proposed
to
be
made
public?
Is
this
one,
and
this
is
used
by
the
diagnostic?
Is
that
classia,
the
diagnostic
listener
class,
and
so
the
current
plan
is
like
in
contrib
you'll,
just
duplicate
that
thing,
so
I
have
a
hard
time
moving
between
tag
like
repose.
D
A
A
So,
like
the
reason
why
you
are
not
affected
is
because,
like
in
aws,
the
instrumentation
which
you
have
it
does
not
have
the
diagnostic
source.
Currently,
yes,
but
if
you
imagine
that
you
had
like
diagnostic
tools
already
just
like
elasticsearch
or
grpc
client,
and
then
you
need
to
suppress
underlying
one.
B
C
A
Only
an
issue
for
those
instrumentations
which
rely
on
the
things
from
this
folder,
which
means
those
instrumentations,
already
produce
an
activity
using
the
old
way.
So
it's
only
an
issue
for
those
instrumentation.
That's
why
I
said
it's
not
an
issue
for
the
aws
instrumentation,
because
it
does
not
rely
on
this.
B
A
A
Yeah,
I
I
really
need
to
like
read
the
comments
again
to
get
back
to
what
michael
was
asking.
Do
we
really
need
this
or
not
so
my
easiest
way
to
validate
that
would
be
I'll,
just
modify
the
grpc
instrumentation
and
see
if
it
works.
A
That
would
be
the
easy
way
to
validate,
but
then
we
can
see
why,
if
it
doesn't
work,
then
we
can
see
like
whether
the
reason
is
because
the
diagnostic
source
is
not
calling
this
method
so
right
now
this
method
is
internal
and,
like
all
all
the
instrumentations
which
are
part
of
this
repo
is
like
able
to
use
it,
but
once
we
copy
this
thing
into
the
control
repo,
which
is
already
happening
in
the
elasticsearch
pr,
so
this
whole
thing
is
being
copied
over
into
the
control
paper.
A
So
at
that
time
it
will
lose
access
to
the
increment.
If
triggered
method
like
this
method,
because
it's
not
public
and
I
can
validate
what
exactly
is
going
on
and
come
back
before
next
c
goal,
I
can
respond
in
this
pr
itself,
but
that
that
would
be
a
blocker
like
if
elasticsearch
wants
to
support,
or
in
general,
like
if
any,
if
any
instrumentations
which
is
written
outside
of
this
repo
wants
to
use
the
once,
you
provide
a
feature
called
surplus
downstream,
then
it
might
require
exposing
this
api
public.
A
A
A
So,
let's
I
mean
the
action
item
is
on
me
to
respond
to
the
github
issue
or
the
discussion
and
see
if
it
we
are
okay,
to
expose
this
as
public.
If,
yes,
then
we
need
to
like
probably
document
what
this
is
supposed
to
do
and
modify
the
in
modify
the
document
which
says
which
asks
people
how
to
write
instrumentation,
because
we
currently
have
a
document
which
is
now
update
outdated
by
now,
because
we
recently
changed
the
activity
source
adapter,
and
this
is
a
special
case.
A
That,
okay
yeah,
is
there
anything
else
to
be
discussed.
A
Okay,
that
means
we
can
end
early
and
just
to
like
remain
anyone,
everyone
who
is
an
approver
or
maintainer.
Please
look
at
this
issue
and
mark
your
explicit
permission
to
be
listed
as
a
contributor.
Sorry
maintainer,
slash
approver
in
the
country
repo,
also,
if
you
are
like
new
and
you
want
to
be
a
approver
for
the
contrib
repo,
even
for
a
sub
project.
A
Please
comment
in
that
issue,
so
we
can
add
you
and
prashant
just
to
confirm,
like
you
will
create
a
pr
in
the
control
repo
to
update
the
contributing
document
and
releasing
document
to
like
the
premise
document,
what
you
learned,
and
also
to
indicate
that
if
you
are
contributing
a
brand
new
project,
you
are
by
default,
should
be
added
as
a
code
owner
in
that
folder.
A
Okay,
yeah,
that's
pretty
much
it.
If
there
are
any
questions
we
can
take
now,
otherwise,
we'll
see
again
next
week,
all
right
see
you
next
week,
bye,
bye,.