►
From YouTube: 2021-02-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
Hey
hello,
everyone,
let's
wait!
One
more
minute.
A
I
think
we
can
start
it's
one
minute
past
four,
so
it
should
be
good.
A
Please
add
your
name
to
the
attendees
if
you
haven't
done
so
already
so
I'll
give
a
bit
of
quick
updates
on
where
are
we
with
the
releases
and
then
we'll
look
at
the
proposal
in
the
contract,
repo
on
how
how
to
arrange
things
there,
and
you
also
want
to
get
some
feedback
on
a
couple
of
issues
which
are
open
very
recently.
A
A
We
will
be
officially
unblocked
from
the
spec
perspective
from
releasing
one
auto,
but
it
doesn't
mean
like
we
can't
release
tomorrow,
because
I
have
a
couple
of
issues
to
discuss
which
might
affect
the
1.0
release,
but
at
least
from
spec
we
will
get
a
green
light
very
soon,
probably
by
end
of
day
today
or
tomorrow
morning.
A
Second
update
is:
we
did
a
release
yesterday
or
day
before
yesterday.
It's
rc2,
and
this
is
the
release
which
do
not
contain
any
metrics
at
all.
The
metrics
code
are
moved
from
the
master
branch
and
it
is
released
as
a
separate
package
alpha
package-
it's
not
yet
in
nougat,
it's
currently
only
in
my
gate.
So
if
you
are
using
a
matrix
api-
and
you
want
to
continue
just
get
it
from
my
gate
for
now,
I
will
be
putting
it
into
nuget
zone.
A
I'm
just
trying
to
figure
out
whether
I
can
like
do
a
little
bit
more
automation,
because
publishing
to
nougat
is
right
now
manual,
so
you
manually,
run
the
build
and
take
the
packages
locally,
and
then
you
push
to
look
it
so
I'll,
try
to
see
if
I
can
automate
it
but
respectively
of
that
I'll
have
matrix
or
next
alpha
package
which
would
contain
the
matrix
code
into
nuget
as
well.
A
There
will
be
like
more
rc
releases
today,
because
we,
I
I'm
still
looking
at
spec
complaints
and
a
couple
of
things
were
brought
up
today.
It
will
just
discuss
it
today
towards
the
end
so,
based
on
that,
we'll
release
an
rc3.
The
idea
is
the
last
rc
release.
Let's
assume
it
is
rc3
would
be
as
good
as
1.0
from
a
api
perspective
will
not
break
any
api
change
in
rc3.
A
Whatever
is
the
last
rc
I
may
have
like
rc3
and
rc4,
because
some
of
the
release
things
we
are
only
figuring
out
just
by
doing
the
actual
release
like
you
get
signing
and
things
so
we
could
have
rc4,
but
by
default
I'll
assume
it
will
be
rc3,
which
is
likely
to
come
today
or
tomorrow,
closely
followed
by
actual
1.0
any
questions
on
release,
dates
or
release
plans.
Other
ways.
B
Again
yep,
I
just
got
a
quick
question
like
so
like
on
the
actual
1.0
release.
I
know
we
still
are
waiting
on
a
few
things
and
there's
a
little
obviously
some
discussion
around.
That
is
there
any
possibility
that
that
would
happen
before
say
next
week's
meeting.
A
I'm
I'm
thinking
it
would
happen
in
the
next
two
three
days,
because
we
we
should
be
getting
like
green
light
today.
Okay,
then
it's
only
a
matter
of
like
us
doing
like
completing
anything
which
are
required
for
1.0.
So
I
did
a
another
review
comparison
with
spec
like
where
we
stand
in
terms
of
spec
complaints.
A
A
There
are
a
few
things
which
you
can
see.
It's
not
marked,
there's
an
active
pr
which
is
addressing
it
right
now
in
the
spec.
I
pushed
it
like
a
few
minutes
back,
but
then
there
are
certain
things
which
we
are
not
complaining
with
respect
anyway,
because
of
like
reasons
which
we
cannot
solve
in
this
ripper.
A
lot
because,
like
one
of
the
thing
is
we
are
using
activity
and
activity,
has
its
own
slightly
different
semantics,
so
we
won't
be
able
to
solve
it
anyway,
so
that
would
remain
like
minus
here.
A
So
this
shouldn't
block
us
from
listening.
This
is
one
good
example.
There
is
a
spec
requirement
which
says
the
parent
should
only
be
in
the
form
of
context,
not
in
the
form
of
a
span
context,
but
activity
allows
parent
to
be
specified
as
activity
contact.
So
this
is
like
negative
and
we
are
not
going
to
change
it
at
least
in
the
near
time,
and
then
there
are
few
optional
things
which
we
are
like
conveniently
not
doing
right
now,
all
these
environment
variables,
but
it's
clearly
saved
it's
optional.
A
We
can
do
it
after
one
dot
so
and
the
last
thing,
which
is
also
the
topic
which
I
have
towards
the
end,
which
is
about
the
otlp
exporter.
It
looks
like
we
are
mostly
in
compliant.
If
you
purely
look
at
the
spec
compliance
metrics,
the
spec
says
we
just
need
to
support
at
least
one
protocol,
and
we
do
support
this
option.
These
are
optional
and
everything
else
is
optional,
so
it's
it
still
puts
us
in
compliance
like
these
are
all
optional
things.
A
But
then,
if
you
look
at
the
actual
otlp
protocol
itself,
there
are
few
things
which
we
are
not
complaining.
So
I'll
cover
it
like
later
and
to
see
to
make
a
decision.
Should
we
delay
the
one
daughter
release
to
make
otp
exporter
complaint,
or
should
we
exclude
or
tlp
or
do
something
else,
so
we
will
discuss
it
shortly,
but
this
this
is
where,
like
overall
things
stand,
I'm
still
doing
like
manual
review
of
each
and
every
public
api.
A
So
I
expect
another
change
in
zipkin,
xbox
or
jager
exporter
today,
but
that
should
be
the
end
of
it,
like
everything
else
is
already
reviewed
several
times,
so
I
don't
expect
any
change,
but
once
again
like
it's
only
the
next
release,
which
will
confirm
that
we
are
finally
like
looking
all
public
apa.
B
Right,
okay,
so
obviously
it
sounds
like
we're
really
really
close.
Is
there
any
kind
of
requirement
for,
like
the
you
know,
the
last
rc
for
that,
like
you
know,
being
there
for
a
few
days
before
we
go
1.0.
A
I
mean
there
is
no
requirement
defined
in
the
spec.
I
mean
different
languages
are
taking
different
approach,
like
java
just
published,
like
rc
like
last
week.
They
expect
to
keep
it
at
least
two
weeks
before
they
called
1.0
before
I
don't
think
any
other
language
is
releasing
rc's.
As
of
today
morning,
I
haven't
heard
it
from
anyone
for
dot
net.
We
had
rc's
since
december
1st.
A
I
think
I
I'm
not
really
sure
whether
we
really
need
to
like
wait
another
two
weeks,
it's
most
likely,
okay
to
release
within
a
day
or
two
but
like
if
there
are
like
concerns,
please
like
price
it
now,
because
by
default,
I'm
assuming
we
should
be
like
good
to
release
by
end
of
this
week,
assuming
we
can
like
close
these
two
issues
as
well,
which
is
about
the
otlp
exporter,
specific
things.
B
Yeah,
okay,
yeah!
No,
no!
Concern
on
my
on
my
side.
I
guess
the
last
question
on
that,
then
is,
will
you
I
mean?
I
know
we
have
the
medium
post.
That's
going
up
and
everything
are
you
gonna
make
an
announcement
on
gitter
as
well
too,
when
we
do
the
release
yeah.
A
Let
me
see
if
and
keep
this
on
call
like.
There
is
a
can
you
share
like
that
dope
and
yeah
this
one
right?
I.
B
C
Some
quick
changes
to
it
earlier,
but
the
idea
would
be
to
post
this
on
medium
and
then
I
can
add
it.
To
I
mean
I
can
I
can
link
the
medium
post
on
getter
channel
once
it's
posted.
Does
that
make
sense
yeah.
That's.
A
Perfectly
fine,
except
we
just
need
to
make
a
few
more
open
issues
because
we're
not
releasing
instrumentation
libraries
in
1.0
at
least
okay,
so
this
guy
feel
free
to
delete
that
I
can
oh
yeah.
I
can
need
it
right,
yeah,
okay,
yeah!
Then
I
can
just
delete
it
myself
rather
than
leaving
comments
here.
A
Okay,
so,
like
is
this
what
you
are
asking
about
right
like
this.
C
Yeah
it
takes
it
takes
a
few
yeah,
I
would
say
it
takes
at
least
like
a
day
or
two
when
we
send
it
out.
I
need
to
wait
for
approval,
so
I
would
just
buffer
it
into
two
days,
but
if
everything
works
out,
you
can
probably
publish
it.
On
the
same
day,
when
you
give
me
a
green
light,
okay.
A
Any
other
questions
about
sdk
releases.
I
think
I
made
another
pr
like
today,
which
will
clarify
what
are
the
things
which
were
releasing.
It's
also
part
of
the
washing
dock
which
I
haven't
yet
merged.
But
the
easy
way
to
look
at
is
full
request
closed,
so
basically
marking
anything
which
are
like
spec
requirement.
A
A
So
the
prs
in
this
I
mean
this
pr
shows
like
what
are
the
packages
which
will
become
one
auto
in
the
next
couple
of
days.
It
involves
all
the
exporters
which
are
spec
mandated,
so
it's
jager,
zipkin,
oklp
memory
and
console,
and
then
the
api
and
sdk,
but
you
know
that
there
are
at
least
like
15
projects
in
this
repo,
so
all
of
them
are
not
going
to
be
released
at
this
stage.
A
I'll
come
back
with
the
date
when
we
have
it
ready,
because
for
instrumentation
we
have
a
dependency
on
again
spec
and,
for
extension,
slot
hosting.
This
is
something
which
we
have
to
like
make
some
core
changes
herself.
There
is
no
spec
dependency,
but
it
will
come
slightly
delayed,
also
the
shim
for
open
racing.
This
is
also
tied
to
a
spec
being
released
for
open
tracing.
It's
not
yet
there.
I
think
someone
is
working
on
it
so
maybe
like.
A
If
we
get
the
green
light
like
in
the
next
day,
then
we
might
be
able
to
include
it
in
the
one
daughter
release,
but
otherwise
it
would.
It
will
be
like
following
whenever
the
spec
gets
green
light.
It
will
be
one
daughter
at
that
time.
A
Okay,
I
mean
there
is
a
versioning
pr
which
I
haven't
merged
yet,
but
it
also
discusses
what
are
the
core
packages
and
based
on
today's
understanding,
maybe
sometime
in
the
future,
we'll
have
a
different
understanding
like
like,
assuming
that
if
we
move
some
things
from
this
report
to
the
control
repo
like,
for
example,
there
are
certain
instrumentations
and
the
asp.net
core
extensions
for
hosting.
A
A
Okay,
let's
open
the
issue
so
prashan
like
are
you
in
the
call
like?
Can
you
walk
us
through?
Oh,
there
are
more
discussions
yesterday
morning:
okay,
yeah,
could
you
just
like
walk
us
through
like
the
proposal
and
yeah?
I
didn't
read
the
last
part,
but
I
read
the
initial
ones.
D
Yeah,
I
added
the
last
part
this
morning,
so
that's
okay
yeah.
So
I
think
everyone
who
was
present
in
the
last
sig
meeting
you
might
be
aware
of.
We
had
a
little
discussion
on
the
contra
repo
like
as
of
today.
It's
kind
of
like
fallen
behind
the
core
repo
and
the
base
open,
telemetry
sdk
version,
which
is
right
now,
is
at
rc
2,
but
the
contract
repo
still
is
still
at
0.7.0.
D
So
and
in
order
to
bump
that
quantum
repo
version,
there
are
quite
a
few
breaking
changes
and
some
changes
still
needed
on
the
open
telemetry
sdk,
namely
the
activity
source,
adapter
yeah
activity,
source
adapter
to
be
made
public
so
that
most
of
the
instrumentation
in
the
contra
repo
can
use
that
to
like
maintain
compatibility
with
the
latest
version.
D
So
so
this
is
all
like
kind
of
ties.
The
contrib
report
together
and
prevents
one
component
to
be
released
if
there
is
even
a
single
component,
that's
broken
so
in
my
proposal
at
a
higher
level.
What
I
proposed
initially
that
within
the
same
contra
repo,
if
we
can
split
the
build
and
release
building
release
of
each
component
so
like
each
component,
can
target
a
different
version
of
open,
telemetry
sdk
and
can
follow
a
different
version.
D
For
example,
like
the
stackdriver
can
point
to
0.7.0
and
have
itself
versioned
as
0.7.0,
while,
like
aws
component,
can
point
to
rc2
and
then
can
follow
its
own
versioning.
So
I
I
had
a
bunch
of
points
on
that.
Probably
we
don't
need
to
go
into
all
of
those
points,
but
one
of
the
benefits
of
this
approach
was
not
depending
on
the
single
version
of
open
telemetry,
which
is
currently
governed
by
yeah.
D
But
andrag
and
sergey
had
some
feedbacks
on
that
proposal,
which
kind
of
states
that,
within
a
single
repo,
having
different
pills
and
releases
different
versions
is
kind
of
like
not
a
good
practice.
Because
then
the
users
get
confused
as
to
which
version
is
the
repository.
D
As
at
right
now
and
the
github
structure
itself
like
leans
towards
having
a
single
project
as
a
single
repository
with
everything,
building
as
a
single
version
and
a
single
object,
so
then
I
had
some
discussion
with
underrog,
based
on
sergey's
comment
of
like
splitting
the
re
contrib
repo
into
multiple
repositories
for
each
component
or
whatever
suits
grouping
the
components
together.
D
So
this
morning,
I
kind
of
like
revisited
the
feedback
and
kind
of
put
together
every
next
step
that
we
could
take,
or
an
alternate
option
that
we
can
consider,
which
is
like
splitting
the
contra
breeper
into
separate
repos,
where
similar
components
that
wants
to
be
get
maintained
and
released
as
a
single
version
are
kept
in
that
repo,
with
a
separate
workflow
for
build
and
release.
D
And
then
each
of
this
repository
would
at
least
commit
to
build
against
the
current
or
the
latest
state
of
the
open,
telemetry
sdk,
which
is
the
common
dependency.
And
the
build
is
passing.
So
if
the
build
breaks
that
the
maintainers
of
that
repo
can
go
in
quickly
or
as
quickly
as
possible
and
fix
the
build.
D
And
then
one
point
that
sergey
mentioned
that
this.
What
to
do
with
the
zombie
repos
or
reapers,
which
do
not
get
enough
attention
to
be
continuously
built
and
maintained.
So
in
that
case,
that
can
be
marked
as
like.
Unmaintained
and
they're,
like
the
maintainers,
can
be
notified
to
hey
just
fix
three
pro
with
the
latest
version
of
sdk.
Whatever
breaking
changes
was
and
get
it
to
work.
D
So
that's
that's
kind
of
the
option
I
am
also
leaning
towards
and
second
option
is,
maintain
the
repo
contra
repo,
as
is,
but
we
go
in
and
fix
everything
and
kind
of
like
commit
some
of
the
maintainers
to
maintain
the
contrabrepo
and
do
whatever
is
necessary
to
maintain
the
contra
people
in
the
consistent
state
with
the
core
reaper.
A
A
I
don't
know
if
any
downsides
yeah.
Of
course
we
need
to
make
sure
like
there
are
enough
maintainers
for
each
of
that,
but.
E
But
I
mean
both
approaches
has
their
downsides.
I
think
splitting
into
multiple
repositories
may
have
a
little
bit
more
overhead
and
it
likes
this
benefit
of
people
helping
each
other.
So
one
person
cleaned
up
like
upgrade
to
one
point
of
open,
telemetry
api
and
every
component
benefits
from
that.
So
we
will
be
liking,
this
kind
of
maintenance
and
helping
each
other.
E
My
suggestion
actually
was
to
start
with
a
separate
component
in
one
repository
and
try
to
see
how
far
we
can
go
with
that
and
see
when
we
will
hit
the
limitations
of
github
and
then
once
we
realize
we
really
need
a
separate
repository.
It's
quite
easy
to
create
a
new
repository.
So
I
think
it's
it's
almost
a
no
op
to
create
this
new
repository.
We
just
need
to
make
sure
that
we
have
enough
energy
to
support
three
repositories
now
and
then
four
repositories.
A
E
D
Like
if
one
component
targets
a
different
version
of
open,
telemetry,
sdk
and
another
component
target
wants
to
target
another
one
or
maybe
there's
a
breaking
change
in
something
and.
D
Even
within
components
so,
like
sergey
said,
it
can
be
grouped
together
if,
if
they're,
like
similarity
in
components
or
maintainability,.
F
One
question:
perhaps
you
guys
already
discussed
this
above,
but,
for
instance,
the
the
collector
has
keeping
the
components
in
sync
because
it
wants
to
build
all
of
them
and
ship
in
the
same
binary.
So
they
require
the
same
dependencies.
F
D
Right
so,
like
my
reason
for
supporting
or
proposing
the
separate
reaper
was
or
actually
not
having
the
monorepo
with
built
together,
because
we
don't,
we
don't
really
need
to
ship
the
all
the
components
together
with
the
same
version
right
in
the
contrib
repo.
F
A
What
poll
is
initial
same
thing
as
now,
but
like
split
the
like
build
process
in
such
a
way
that,
like
each
folder
in
that,
can
like
take
a
different
version
rather
than
like
right
now,
it's
like
a
common
one
like
instead
of
that,
have
each
project
define
its
own
dependencies.
Whatever
version
they
want,
so
aws
can
depend
on
one
dot.
Rc1
mass
transit
can
depend
on
one
dot.
D
Rc5
yeah-
that
was
my
initial
proposal
like
every
project
having
its
own
dependency
on
the
hotel,
sdk
and
kind
of
like
release
a
different
version
of
itself,
or
the
component
also
wants
to
be
released
together.
F
I
I
I
think
if
you
don't
have
the
resources
to
go
and
do
this
it's
much.
It
makes
much
more
sense
for
each
component
walk
by
itself.
You
know.
D
F
I
I
I
can't
I
I
I
must
be
sincere.
I
didn't
read
the
whole
the
whole
thread,
I'm
I'm
just
based
on
what
we
talked
about
last
week
and
this
week,
so
I
will
try
to
read
and
catch
up,
but
at
first
it
seems
to
me
that
dotnet
having
a
bunch
of
separate
contrib
repos,
make
a
little
bit
harder
for
us
to
kind
of
have
people
aware
of
stuff.
F
Let's
say
if
there
is
a
contributor
for
one
of
these
projects
here
that
want
to
change
something
or
talk
to
us
is
just
one
single
group.
If
we
start
to
have
a
bunch
of
repos,
I
think
the
tennis
is
not
tired
for
sure,
but
I
think
the
tendency
is
to
kind
of
dispersate
the
disperse
the
interest
and
the
the
people
too
much
around.
You
know
somebody
may
not
follow
what's
happening
in
one
repo,
but
follow
just
that
single
project.
So
it's
kind
of
I
think
it's
harder
to
coordinate.
E
Yeah
paul,
but
I
mean
at
the
same
time
there
is
a
proposed
pr
for
wcf
support
and
we
can
merge
it
in
and
we
will
support
it,
but
then
it
will
rarely
change.
Wcf
is
not
that
agile,
and
I
mean
why
should
we
build
it
all
the
time
with
every
single
like
pr?
Why
do
we
need
to
pay
attention
at
all
if
it's
not
changing
and.
F
E
F
E
A
Yeah,
so
it's
basically
saying
like
keep
the
current
one,
except
we
need
to
like
more
like
organize
a
project
in
such
a
way
they
can
like
independently
version.
But
the
question
of
like
separate
github
repo
per
component
is
something
which
we
will
need
to
discuss
when
we
have
like
enough
components,
because
I
can
see
like
python
has
like
30
or
40.
D
So
cj
you
mentioned
that
some
of
the
instrumentations
in
the
core
repo
which
are
not
like
required
by
spec,
would
also
be
moving
to
contrib.
A
Yeah,
I'm
happy
to
move
them
off
from
the
main
ripple
because
it's
not
required
by
the
spec.
We
can
always
move
it
around,
but
I
I
just
want
to
make
sure
like
we
have
a
good
good
policy
for
counter
breaker
first,
before
moving
things
from
there.
A
So
look
one
difference
is
like
for
the
main
repo
like
who
is
the
current
maintenance.
They
accept
the
responsibility
of
maintaining
it.
There
are
like
six
instrumentations
and
four
exporters.
I
mean
exporters
are
required
by
the
spec,
but
then
there
are
like
at
least
six
or
seven
instrumentation.
So
as
a
maintainer
or
an
approver
in
that
repo,
we
assume
ownership
of
that.
A
A
So
moving
that
off
is
like
relatively
easy
thing:
it's
not
a
big
burden
as
of
now,
because
those
are
like
just
common
dot-net
concepts
like
sp.net
or
sql
or
http
client,
it's
generally,
okay,
to
expect
the
maintainer
to
be
like
up
to
date
with
those,
but
not
the
same
for
like
when
things
when
the
report
grows
bigger,
especially
when
it
has
things
like
azure
or
aws
or
stackdriver.
This
would
be
like.
A
A
D
From
my
initial
look
at
the
workflows,
if
each
of
the
component
is
targeting
a
separate
version
of
open,
telemetry
sdk
and
ensuring
that
the
component
builds,
then
the
work
get
a
workflow
would
also
build.
A
Built
successfully
oh
yeah,
I
mean
I
was
asking
like:
will
there
be
like
a
separate
workflow
per
directory
or
per
folder,
or
will
we
be
just
having
a
single
workflow?
So
if
you
basically
submit
a
pr
to
an
aws
project,
the
workflow
will
kick
off
and
run
all
the
other
projects
as
well.
Is
that
what
you're,
saying
or
when
you
submit
apr
against
aws,
only
the
aws
component
will
be
built
and
not
the
other.
That's
the
part
which
I'm
not
sure
I
am.
A
I
get
the
feeling
that
it
will
be
building
everything
together,
even
if
you
make
no
changes
at
all,
so
other
other
packages
will
also
get
built
and
that's
one
potential
issue,
because
if
somebody
fails
in
like
some
unrelated
that
might
block
one
component
from
moving
forward,
I
mean,
given
that
it's
like
only
five
it
might
be.
E
We
can
always
have
separate
build
definitions
and
they
will
be
marked
as
optional
in
prs
and
we
can
use
exercise
judgments
when
we
merge
prs.
A
Okay,
good,
so
what
we're
saying
is
like,
let
all
workflows
run
and
when
who
is
the
maintainer
like,
because
maintainers
are
the
only
one
who
can
click
the
merge
button,
so
they
can
look
at
two
things
before
they
merge
one
is:
does
it
have
enough
approval?
Second,
does
it
pass
the
relevant
workflow?
Not
all
the
workflow.
E
A
Yeah
I
mean
this
sounds
good,
like
I
say
like
initial
step,
I
think
this
is
acceptable.
I
I
don't
know
whether
it's
it's
worth
our
time
to
explore.
Whether
workflows
can
be
like
separated
as
well,
so
that
there
should
be
like
no
no
need
of
like
triggering
the
entire
workflow.
When
you
just
touch
one
dedicated
component.
D
A
On
related
topic
like
releasing
so
in
the
main
repo,
I
just
split
the
repo
basically
into
like
core
versus
known
core,
but
I
think
it's.
I
don't
expect
that
to
happen
like
long
time
like
it
should
be
like
relatively
moving
at
the
same
pace.
So,
but
here
like
it,
it's
not
likely
that
you'll
be
able
to
release
everything
in
same
flow.
A
So
any
thoughts
on
like
the
release
process
like
would
you
expect
to
have
the
ability
to
release
individual
components
or
would
you
expect
like
a
like
a
github
workflow,
where,
once
you
kick
it
off,
it
will
build
everything
here
and
publish,
even
if
there
is
no
change.
D
That
point
I
mentioned
in
my
proposal
that
we
would
want
to
have
the
ability
to
release
each
component
separately
so
like
could
be
a
release
workflow,
which
takes
the
input
as
the
component
project
name
and
the
version
number
and
just
builds
that
particular
project
and
pushes
to.
A
A
And
and
the
version
like
that,
versioning
can
also
like
the
tool
which
we
use
is
meanwhile,
and
meanwhile
has
the
ability
to
version
like
each
folder,
independently,
okay
yeah,
because
it's
basically
based
on
jit
tag.
So
when,
when
you
tag
something
it
gets
like
applied
to
all
projects,
but
as
we
already
did
it
in
the
main
ripper
we
can
like
assign
different
versions.
So
if
aws
thinks
that
you're
ready
to
go
like
one
zero,
zero
but
elastic
such
things,
it's
still
like
beta,
it
can
be
done
yep.
A
But
it's
still
like
from
a
actual
release
to
my
get
slash,
nuget
perspective.
Yes,
we
need
to
spend
some
time,
like
writing
the
automation,
because
it's
manual
right
now
and
since
we
are
releasing
everything
together,
it
was
not
a
big
issue
because
you
just
download
the
zip
file
run
that
partial
script
and
you're
done.
But
now
it's
like
you
have
to
do
it
for
each
and
every
thing.
So
we
definitely
want
to
write
some
scripts
to
automate
the
whole
whole
flow.
A
We
did
automate
the
hardware
we
can
push
to
mygate
but
after
that
it's
still
manual,
so
I
think
yeah.
We
we
can
use
the
same
approach.
D
And
slightly
more
actually
that's
where
the
confusion
would
happen,
like
the
change
log
and
the
github
release
like
which
package
or
project
would
you
mark
in
the
github
and
that's,
I
think
the
point
which
anurag
point
pointed
out
that
this
this
kind
of
practice
of
individual
bills
and
release
is
kind
of
like
not
seen
in
github
or
not
a
very
common
and
okay.
That's.
A
D
A
I
mean
like
sergey
or
polo
like:
do
you
have
any
thoughts
on
that
part
like,
let's
assume
that
we
want
to
keep
the
requirement
of
releasing
each
packages
independently?
A
A
E
A
Yeah
I
mean
combine
change
log
and
do
the
actual
github
release
like
when
I,
when
I
click
like
github
release.
Let's
say
we
need
to
pick
a
tag,
but
it
could
be
like
one
package
could
be
in
one
dot.
Oh
and
another
package
could
be
in
like
point
five.
E
A
A
E
A
Got
it
yeah,
I
mean
my
personal
preference
is
just
to
keep
it
same.
I
think
from
the
main
repo.
There
is
no
need
of
like
tagging
it
with
contrib,
because
in
the
new
gate
it
links
back
to
the
repository
which
will
take
you
right
here
and
there
should
be
a
readme
which,
which
can
clarify
this
name.
A
Elementary
control,
yeah
yeah
right
now
it
is
prefixed
with
the
contrib
name
at
the
end.
So
that's
what
I
was
asking
this
is:
it
has
a
name
like
open
elementary
dot,
contrib
dot,
instrumentation
dot
mass
transit,
but
I
mean
I
don't
think
we
need
to
solve
this
problem
right
now,
because
let's
try
to
do
step
by
step
so
like
if
you
can
just
modify
the
repo
to
independently
build
things
that
shouldn't
block
at
least
the
current
one
like
we,
we
should
be
able
to
like
unblock
all
of
them.
A
We
can
worry
about
the
future
ones
when
we
reach
there
so
that
we
can
like
make
some
progress.
D
Okay,
yeah.
A
I
I
can
do
that
for
all
the
products.
Please
check
if
you
can
like
write
the
automation,
so
that,
like
you,
don't
have
to
like
I
mean
if
you
have
to
ask
a
maintainer
each
time
to
do
the
release
and
if
maintainer
is
doing
some
manual
work
to
do
the
release,
then
it
could
be
like
yeah
not
very
like
efficient,
because
you
have
to
like
maintain
how
to
constantly
respond
to
release
requests
from
each
component.
A
But
if
we
have
the
script
and
like
releasing
is
only
a
matter
of
like
going
to
action
and
like
clicking.
A
Right
now,
yeah,
you
need
like
right
access
and,
like
maybe
like
even
higher
access.
So
I
don't
know
whether
you
you
would
see
this
unless
you
are
a
maintainer,
so
you
cannot
run
this
manually
right,
yeah
yeah.
So
if
it's
like
automated,
then
like
it
should
be
like
fairly
easy,
like
just
like
tell
off
open
an
issue
asking
or
just
ping:
maintainer
hey,
do
a
release
for
xyz
and
they
can
just
run
the
like
script,
and
it
should
do
everything,
including
publishing.
A
To
my
I
mean
you
get
right
now,
it's
still
my
get,
but
it's
very
straightforward
to
do
the
nougat
as
well.
It's
just
that
we
haven't
done
it.
Yeah.
A
For
this
repo,
I
don't
think
we
have
defined
the
correct,
but
for
the
main
ripple,
the
way
I
looked
at
is
like
daily
builds
are
published
to
my
get
so
every
day
there
is
a
workflow
which
looks
at
the
current
master.
I
mean
now
main
branch
and
publishes
it
to
myget.
A
So
it's
like
people
who
want
to
like
really
try
the
latest
build
on
a
daily
basis,
or
they
are
like
looking
for
trying
a
bug
fix
which
is
not
yet
released,
so
they
can
just
try
make
it,
but
once
in
a
while,
we
haven't
defined
the
cadence
yet,
but
typically
like
once
a
month
or
once
in
two
months,
we
publish
packages
to
nougat
and
packages
in
nougat
have
like
more
stability,
guarantees
about
it.
A
It
doesn't
mean,
like
aps,
won't
break
or
anything
it's
just
that
it
has
gone
through
like
much
more
scrutiny,
so
most
customers
would
consume
it
from
negatively,
but
people
who
are
like
really
actively
like
trying
out
features
they
would
use
the
migrate
one.
A
D
So
I
yeah
it
was
about
the
next
action
item.
So
what
I
do
is
go,
go
into
the
components
and
add
the
dependency
to
the
opentelemetry.net
in
each
of
the
projects
and
then
also
do
the
automation
of
for
the
separate
bills.
A
I
think
I
can
help
you,
it
should
be.
Just
like
I
mean
you're
not
going
to
make
code
changes
right,
you're
just
going.
E
Maintainers
and
include.
D
B
E
In
the
country,
mountaineers
and
these
people
may
be
mentioned-
and
code
owners
files
already.
A
So
sega
what
you're
suggesting
is
like
we
need
to
create
a
new
github
group,
specifically
like
open
elementary.net,
contrib,
maintainers
approvers,
which
would
be
separate
from
the
open,
elementary.net
maintenance
and
approval.
Of
course,
there
can
be
same
people
but
like
physically.
It's
a
different
group
I
see
like
is
that
something
which
you
can
create,
or
I.
E
A
Yeah
I
mean
this
is
a
time
for
like
recruiting
more
people
to
be
maintainers
in
country
people
so
maybe
like
we
can
do
like
something
like
we
can
create
an
issue
like
ask
for
people
who
has
who
are
committing
to
be
like
a
maintainer,
because
millionaires
have
like
some
extra
like
bookkeeping,
slash,
maintenance
job.
So
just
asking
indicator
like
to
see
like
how
many
are
interested
in
becoming
like
maintaining
and
for
approver.
I
think
we
can
do
like
on
a
per
folder
basis,
yeah.
A
D
Okay,
so,
like
we,
everyone
agrees
that
we
are
going
to
separate
the
bills
within
the
same
contract,
repo
right.
E
F
A
A
I
need
to
open
one
more,
so
I
found
like
otlp
exporters,
which
we
currently
have
does
not
have
full
compliance
with
the
spec,
and
let
me
open
the
issue,
so
this
is
about
otp
exporters
and
it's
compliance
with
this
pick.
So
basically
the
exporter
spec
says
like
it
supports
all
these
options.
A
The
current
otp
exporter
does
not
support
this
directly,
like
some
of
them
are
like
indirectly
supported.
A
But
basically
the
point
which
we
are
I'm
trying
to
say
is
the
exporter
was
written
in
the
assumption
that
it
would
be
like,
like
grpc
specific.
So
all
the
options
which
we
currently
have
configurable
options
in
the
exporter
are
like
tied
to
grpc
in
the
options.
Class
itself
contains
grpc
channel
options
or
channel
options
which
are
all
like
classes
directly
coming
from
the
grpc
package
and
now,
given
that
the
spec
allows
the
possibility
of
oh
sorry,
I
accidentally
clicked
yeah.
A
So,
given
that
the
spec
is
allowing
the
possibility
of
like
exporter
or
dlp
exporter
using
http,
so
it's
json
or
http
or
grp
protocol
buffer,
I'm
wondering
what
should
we
do
into
the
otlp
exporter?
Options
like
one
option
is:
oh
yeah.
A
We
have
more
comments
from
helen
already,
so
one
option
which
I
was
thinking
was
make
all
the
options
like
purely
agnostic
to
whether
it
is
using
grpc
or
http
just
like
the
spec,
so
it
would
be
protocol
name
and
the
path
to
the
certificate
and
headers
which
are
just
like
string
of
key
value,
pairs,
no
connection
to
the
actual
grpc,
headers
or
http
headers
class
and
internally,
the
exporter
can
parse
the
string
and
call
the
appropriate
classes
or
options
in
the
underlying
mechanism.
A
So
if
it
is
grpc,
we
would
construct
the
grpc
metadata
instead
of
headers
and
for
http
we'll
do
like
http
headers
itself.
So
that
is
one
way.
I'm
here
to
look
at
the
comment
from
ln
so
I'll
I
mean
the
reason
why
we
want
to
do.
That
is
because,
once
we
add
http
support
in
the
future,
we
wouldn't
need
to
make
any
changes
to
the
options.
A
It
will
be
just
like
just
matching
what
the
spec
says,
which
are
mostly
like
basic
string
type
options,
so
we
can
add
support
without
breaking
any
public
ap.
The
only
thing
which
we
would
need
to
add
in
the
future
is
like
one
option
to
let
user
pick
the
protocol.
It
will
default
to
grpc
and
when
we
add
like
more
options,
we
don't
need
to
touch
any
of
the
other
things
so
that
so
that
will
remain
backward
compatible,
so
allen.
If
you're
here,
can
you
describe
your
suggestion
as
well.
G
Yeah
so
one
of
the
questions
I
post
here
was
just
instead
of
a
generic
structure
having
two
separate
options.
G
I
think
the
one
thing
that
this
might
enable
is
it
would
maintain
direct
access
to
the
the
protocol
specific
options,
allowing
it
things
to
be
a
little
bit
more
flexible
for
the
consumer.
G
A
I
see
so
what
are
the
reasons?
Why
would
someone
want
a
full
access
to
channel
options?
Is
there
any
field
which
I
mean?
Are
there
more
settings
than
allowed
by
the
spec
I
haven't
played
with
it?
So
I'm
just
asking
us
a
question
like?
Is
there
any
known
reasons
why,
like
accessing
the
direct
classes,
might
be
beneficial.
G
I
don't
have
a
great
use
case
off
the
top
of
my
head,
but
I
can
say
that
there,
yes,
there
are
additional
options
that
one
could
see
could
use
so
yeah
I
mean,
but
I
think
that's
a
legitimate
question
is,
is,
you
know,
is
access
to
those
options,
I'm
really
necessary
again.
In
absence
of,
like
some
concrete
use
cases,
I
I
can't,
I
can't
really
say
very
strongly
yes
or
no.
Okay,.
A
Okay,
yeah
one
way
I
was
thinking
was,
I
mean,
let's
assume,
that
there
is
a
genuine
reason
for
users
to
get
a
hold
of
the
full
class.
But
if
that
reason
is
like
really
good
enough,
then
we
should
be
able
to
like
allow
the
spec
itself
to
be
modified
to
support
that
unless
it's
a
very
totally
thingy.
A
Yeah,
so
so
the
reason
why
this
is
important
that
this,
like
from
my
timing
perspective,
is
because
whatever
we
decide,
it's
going
to
be
a
public
api
change,
so
one
thing
we
can
do
is
just
like:
don't
expose
anything
like
no
expose
and
ship
1.0
and
then
discuss
this
in
like
1.1
release,
or
we
can
delay
the
one
daughter
release
until
we
migrate
from
http
specific
options.
Sorry,
grpc
specific
options
do
like
pure
string
based
spec
one
or
the
alternate
option
like
keep
like
separate
files.
A
So
it's
like
right
now.
We
will
have
only
grpc
options
and
in
the
future
we
can
introduce
a
new
one,
so
it
will
still
be
backward
compatible.
So
the
actual
answer
to
that
question
I
think
we'll
have
to
like
really
try
whether
how
much
effort
it
is
to
like
convert
from.
A
A
So,
depending
on
like
how
much
effort
this
is
we'll
come
to
a
conclusion,
I
think
we
don't
need
to
make
a
like
final
conclusion
here.
So
someone
is
already
looking
at
it
utkar
she's
already
in
the
course
so
he's
trying
to
look
at
it.
So
is.
A
Some
bandwidth
to
help
us
with
this
transition
like
who
has
like
some
familiarity
with
like
grpc
for
both
like
one
is
for
dotnet
framework.
We
are
using
the
grpc.net
and
then
for
newer
dotnet
framework.
We
are
using
a
different
package.
I
think
there
are
fairly
big
differences
between
these
two.
So,
like
anyone
who
has
like
more
bandwidth,
please
raise
your
hands
or
like
comment
here,
so
we
could
use
some
help
to
make
this.
This
is
probably
the
last
thing
which
we
need
before
1.0.
A
So
if
you
can
help,
that
would
be
really
great
I'll,
like
we'll
definitely
reserve,
because
you,
you
have
like
most
expertise
in
this
like,
but
if
there
are
anyone
else,
we'd
be
happy
to
be
in
touch
to
get
some
help,
yeah
absolutely
yeah,
and
I
I'm
not
yet
convinced
that
we
have
a
easy
way
of
like
shipping
it.
As
is,
and
then
add
these
features
without
breaking
us,
because
the
moment
we
add
http,
all
these
options
would
look
like
bit
ugly
because
it
says
like
grpc.
A
In
the
I
mean
it's
all
about
like
grpc
channel
android,
so
I
think
we
have
to
solve
this
before
one
daughter.
There
is
no
way
we
can
release
a
utility
exporter
1.0
without
this,
because
we
cannot
afford
to
have
any
breaking
change
after
that.
So
it's
probably
the
I
mean
probably
right
thing
to
market
us
like
the
blocker
for
1.0
and
we'll
get
to
work
on
it
like
right
away.
A
That
was
the
last
yeah.
There
are.
F
A
One
more
again
related
to
grpc.
A
This
is
like
there
is
a
requirement
that
otlp
exporter
should
have
retry
mechanism,
and
so
this
already
found
that
like
there
is
no
need
of
doing
that
right
now,
because
the
underlying
package,
which
we
are
using
the
grpc
net
client,
it
is
planning
to
improve
and
add
built-in
support
for
retries
it's
linked
here.
So
it's
going
to
come
sometime
very
soon,
so
we
should
be
able
to
just
wait
until
the
new
version
of
grpc,
not
neckline,
is
released
and
then
just
leverage
that
instead
of
implementing.
A
So
I
think
this
is
fairly
easy
to
decision
to
make.
We
don't
need
to
block
one
data
for
this.
We
can
just
do
this
after
as
an
incremental
change,
but
for
the
options
yeah
we'll
try
to
solve
this
as
soon
as
possible.
A
F
Forgot
there
was
mute.
I
I
I
can
take
a
look
with
the
the
things
that
match
the
collector,
but
I'm
I'm
will
be
pretty
busy
in
the
next
two
weeks,
so
I
don't
think
I
can
directly
help.
I
can
help
you
with
reviews
and
that
kind
of
stuff.
You
know
yeah
that.
A
A
Yeah,
thank
you.
Yes,
so
she's
going
to
work
on
it
like
I'll,
be
also
working
on
it,
we'll
try
to
like
split
so
that
we
can
do
this
sooner
and
use
like
all
the
help
we
can
get
from
others
as
well.
A
Okay
and
like
there
was
an
issue
which
allen
opened
and
we
were
asking
people
to
review.
I
believe,
like
we
got
like
lot
of
issues
open
and
I
most
of
them
are
either
tagged
as
like
required
for
ga
or
not
when
the
issues
are
open
and
so
far
like
based
on.
Let's
look
at
all
the
issues
in
1.0,
I
don't
see
anything
other
than
what
I
just
discussed.
A
I
mean
there
are
few
issues
about
this
package,
but
that
package
is
something
which
is
not
going
one
dot
or
next
week
or
this
week,
so
we
don't
need
to
do
anything
for
now.
Of
course,
we
need
to
solve
it,
but
it's
not
blocking,
but
all
other
issues
are
relatively
small
or
like
either
already
sold
or
properly
just
a
small
documentation.
So
I
would
say
that
we
can
keep
this
issue
open.
A
Just
for
the
purpose
of
like
whatever
is
the
whatever
are
the
packages
which
we
are
not
releasing,
for
example
the
instrumentation.
We
still
need
more
eyes,
but
for
everything
else
like
alan
and
we
can
go
ahead
and
like
mark
these
components
are
complete
in
the
next
day
and
proceed
with
1.2.
A
Are
there
any
questions
about
1.0
release?
If
not
think
I
out
of
agenda,
we
can
yeah.
I
think,
oh
this.
Let
me
paste
this
into
the
editor
right
away.
So
please
take
a
look
at
the
like
upcoming
announcement.
A
It
requires
some
edits,
but
please
see
if,
like
we
are
missing
something
or
we
are,
we
need
to
like
refactor
this
in
any
way,
this
announcement,
which
will
which
will
come
in
the
medium
blog
from
official,
open
telemetry,
handle
yeah
I'll,
like
update
the
notes
with
what
we
discussed
and
I'll
sing
with
prashanth
offline
to
get
this
movie
all
right.
Thank
you.
If
there
are
no
questions,
see
you
again
next
week,
all
right.
Thank
you
seriously.
Yeah
bye-bye.