►
From YouTube: 2020-07-29 JavaScript SIG
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
A
B
C
D
D
D
B
D
Okay,
so
first
I
just
want
to
mention:
we
had
the
0.10
release.
This
is
our
first
release
in
a
while,
so
it
contained
a
lot
of
stuff,
especially
a
lot
of
metrics
things.
So
I
want
to
say
thank
you
to
everybody
who
contributed
to
that.
There
was
a
huge
list
of
contributors
on
the
release,
so
thank
you
very
much
to
everybody.
D
One
thing
with
this
release
in
particular
was
we
had
a
bug
where
the
index.ts
file
was
missing
from
a
new
package,
so
it
couldn't
be
loaded
at
all,
and
I'm
not
here
to
harp
on
that
particular
bug.
Mistakes
are
easy
to
make
and
we
fixed
it
quickly,
but
would
anybody
be
interested
in
an
automated
release
process
which
published
nightlys
or
something
from
git
master,
or
anything
like
that
I'd?
D
D
Yeah
I
mean
I,
I
think
it's
a
good
idea.
Do
you
have,
does
your
user
have
permission
on
the
npm
repository
yet.
D
Yeah
yeah,
because
the
process
is
a
little
convoluted
I'd
like
it
to
be
more
automated
anyways.
So
this
is
probably
a
good
first
step
for
that,
but
I
I
don't
know
if
anyone
on
the
call
currently
I
know
we
have
some
people
that
join
these
calls
that
use
open
telemetry
in
production
use
cases.
But
I
don't
know
if
anyone
is
on
the
call.
E
So
for
azure
this
is
actually
yes,
something
I
would
be
interested
in
for
all
of
our
address.
Sdks
something
I
want
to
set
up
is
yeah
just
testing
on
a
canary
or
whatever.
So,
if
once
this
is
set
up,
I
can
definitely
use
it
for
the
address.
D
Okay,
because
the
it
only
a
canary
release
process
only
helps
if
somebody
actually
uses
that,
so
I
wanted
to
make
sure
before
we
put
the
effort
in
that
it
would
be
something
people
would
actually
use
yeah.
I
can
commit
to
at
least
using
it.
Okay,
so
bart,
you
said
you're
willing
to
work
on
that
yep.
Okay,
there
is
no
issue
currently,
so
can
you
make
one
and
assign
yourself.
A
D
Yeah,
I
think
we
can
have
it
any
time
you
merge
to
master.
We
could
use
the
learn.
A
publish
has
built-in
canary
features
that
can
just
it
tacks
on
the
git
hash
to
the
end
of
all
of
the
versions
and
publishes
them,
and
then
it's
installable
using
like
the
at
next
tag.
So
it's
it's
fairly
well
supported
in
lerna
and
I
think
it
shouldn't
be
too
much
of
a
problem.
D
A
A
Is
it
possible
I'm?
I
think
there
was
a
ticket
for
that
and
it
was
already
like
six
months
ago,
but
maybe
we
could
have
like
automatic
ends
to
edge
test
and
if
we
have
button
in
particular
like
the
sdk
all
packaging,
we
got
basically
find
out
this
here.
B
D
G
H
The
issue
is
open
and
we
haven't
worked
on
that,
and
other
thing
I
wanted
to
mention
is
we
have
a
bunch
of
example
in
our
repos,
if
you
can
trigger
the
example
run
along
with
the
build
that
might
also
helpful
to
catch
this
kind
of
bugs.
F
Yeah
that
was
kind
of
what
I
was
getting
at
not
to
you
know.
I
don't
I'm
certainly
not
running
this
in
production,
but
I
can
give
some
experience
from
the
vendor
side,
which
is
we've
found
a
lot
of
success,
having
what's
essentially
like
a
reliability
environment
where
you're
essentially
just
running
an
example
app
and
then
you
deploy
into
a
reliability
environment
that
has
some
simulated.
You
know
bet
traffic
or
behavior,
and
you
can
you
know
it
helps
catch.
F
There's
just
a
you
know,
there's
sort
of
a
ton
of
unknown
unknowns
that
even
end-to-end
tests
can
can
leave.
You
know
give
you
don't
give
you
visibility
into
so
sometimes
just
looking
at,
like
you
know,
did
did
my
app
crash
in
a
reliability.
Environment
sometimes
helps
but
yeah
end-to-end
tests,
I
think,
are
a
wonderful
idea.
D
Okay,
I
I
think
the
first
step
is
we
need
to
like
the
nightly
is
an
easy
win
that
we
can,
we
can
do
and
then
we
can
move
on
to
more
advanced
testing
and
deployment
from
there.
D
D
D
Currently,
the
contrib
hasn't
been
released
for
a
while,
and
it's
currently
at
8.x
on
the
versions.
Should
we
bump
it
to
9
or
10
like?
Should
we
should
we
try
to
keep
it
in
sync
with
the
main,
or
do
we
not
care
about
that
at
all.
D
D
It
just
makes
it
a
little
bit
easier
from
like
a
compatibility
standpoint
for
for
users
to
say
as
long
as
I
have
10
everything
it
should
work.
H
Right,
I
I
think
we
talked
about
this
last
time
also
and,
as
per
my
understanding,
it's
very
hard
to
keep
both
the
version
in
sick
masters
and
in
country
most
of
the
time
we
are
doing
a
lot
of
activities
on
the
master
repo
and
not
on
the
content
side.
H
So
personally,
I
don't
feel
like
releasing
contrib
along
with
the
along
with
the
actual
master
repo
yeah.
Let's
go
yeah
keeping
them
in
sync.
It
is
very
hard
now.
H
So
the
question
that
you
raised
about
the
keeping
the
version
like
same
version
everywhere.
I
think
for
that.
What
we
discussed
last
time
is,
we
can
add
some
contrib
or
something
in
the
package
name
for
the
counter
paper.
H
So
every
package
in
country
paper
will
have
contrary
by
some
extra
name
in
the
package
just
to
distribute
between
the
master
packages
versus
these
contract
packages.
D
Yeah
and
we
need
to
do
that
package
rename,
we
need
to
add
contrib
to
the
name,
and
we
also
need
to
change
the
instrumentation
name
to
be
or
the
plugin
name
to
be
instrumentation,
so
we
probably
need
a
mass
renamed
pr.
D
D
Itself,
okay,
so
I'll
handle
that.
A
D
Yeah:
okay,
that's
probably
a
separate
pr
but
I'll
make
an
issue
for
that.
D
D
It
will
be
hard
for
now,
but
once
we
go
to
1.0
we
should
have
no
breaking
backwards
changes.
So
once
we
go
to
1.0,
we
should
be
able
to
say
if
you're
running,
1.0
or
later
you're
good
up
to
the
point
that
we
go
to
two.
I
H
I
was
just
worried
about
the
the
list,
is
gonna
go
really
big
very
soon,
and
it
might
be
confusing
for
the
users
like
we
have
10
to
15
items
in
the
list
saying
that
this
wasn't
compatible
with
this
and
and.
D
A
A
I
mean
so
whenever
you
go
to
country
people,
you
see
at
least
like
okay,
all
the
packages
were
compatible
with
version
10,
because
now
it
would
be
hard
to
guess.
You
know.
H
Usually
we
always
say
master
is
compatible,
I
mean
latest.
Please
do
we
run
some
sort
of
I
mean
we
don't
have
integration
test,
we
don't
have
end-to-end
tests.
C
D
D
H
The
other
option
is
once
we
have
this
indication
test
in
control
paper,
then
at
least
we'll
have
some
authenticity
of
the
master
version,
but
before
that
I
don't
see
how
to
validate.
H
A
Do
you
agree
about?
I
mean
my
idea
was
like
just
you
know,
because
in
pakistan
you,
you
are
using
some
version
anyway,
yes,
and
whenever
we
publish
something
new,
we
update
all
the
version
to
the
same
anyway.
So
my
idea
was
just
you
know,
so
user
doesn't
need
to
go
and
check
packet
json.
We
can
say:
okay
latest
version,
that's
it.
A
I
added
the
same
for
the
for
the
proto,
actually
because
it
was
confused
for
someone
also
like
why
our
current
version
doesn't
work
with
latest
open
telemetry
collector.
So
I
decided
that
hey.
This
is
compatible
with
version.
H
I
mean
yeah,
I
I
certainly
agree
with
your
point.
My
only
concern
was
how
do
we
know
the
number
like
which
version
is
compatible
and
all,
and
maybe
right
now
it's
easy
to
see,
but
in
the
future
it
would
be
like,
like
the
task
would
be
really
cumbersome
to
update
every
time
without
having
end
to
end
test
or
without
having
this
ga
and
all
kind
of
things.
D
D
D
H
D
D
D
Is
it
okay
to
have
it
be
the
same
name
as
the
other
like
contrib
packages,
or
because
this
is,
you
know,
vendor
specific?
Should
we
have
like
open,
telemetry,
slash
vendor
dash
aws,
or
is
it
okay
to
just?
Have
it
be
like
open,
telemetry,
contrib,
aws
x-ray
propagator?
H
Everybody
just
a
quick
question.
I
mean
I'm
not
following
this
pr
earlier.
We
discussed
not
to
have
any
vendor-specific
package
or
code
in
the
in
the.
D
Repo
so
yeah,
this
has
come
up
at
the
maintainers
meeting
twice
now
and
the
the
other
maintainers
feel
like
we
should
have
propagators
in
our
contrib
repos,
because
the
propagation
formats
are
well
documented
in
public,
but
that
exporters
should
not.
D
D
H
Okay,
I
see
because
recently
for
google
cloud
we
have,
we
are
keeping
our
propagator
inside
google
cloud
platform,
repo.
D
Is
the
so
I
know
the
the
intern
is
from
aws
is
on
the
call
today,
but
kong?
I
don't
I
don't
know.
Do
you
know
whether
this
matters
to
aws,
where
it's
hosted
you
know,
is
it?
Would
it
be
difficult
for
aws
to
host
this.
C
D
C
Okay,
I'm
yeah,
because
I'm
not
so
sure
I
maybe
discuss
this
question
with
my
mentor
and
my
manager
in
the
first
place.
So
oh,
we
basically
want
to
like
keep
our
code
out
of
the
like:
no,
not
repo,
both
either
javascript
repo
or
javascript,
contribute
contributor.
You
want
to
keep
keep
our
code
out
of
that.
Did
you
mean
that
yeah?
If
possible?
D
Or
the
other
way
to
go
mayor
would
be
you
know
if
we
you
know,
is
it
okay?
If
we
host
it,
I
guess
this
is
probably
something
that
barton
mayer
and
I
should
discuss
separately-
is
coming
up
with
a
policy
for
this.
C
Okay
got
it.
Let
me
file
this
issue.
D
So
I'll
I'll
send
you
a
message
on
gator
after
the
after
this
meeting,
and
we
can
find
the
time
to
talk
about
it.
Part
is
that,
okay
with
you.
C
D
The
policy
is
to
have
four
people.
We
sometimes
go
with
three.
If
the
initial
you
know,
if
the
pr
author
is
also
an
approver,
that's
kind
of
a
that's
an
implicit
approval,
I
guess
sometimes,
but
we
like
to
have
four.
D
This
okay,
so
this
issue
came
up
either
early
this
week
or
late
last
week.
Essentially,
our
resource,
auto
detection,
is
interfering
with
the
instrumentation
of
the
node
fetch
module.
D
D
It's
loaded
too
early
in
the
process
before
plugins
are
loaded
related
to
this
is
a
recent
otep
that
merged,
where
that
specifies
that
auto
detectors
should
be
in
separate
packages
separately,
deployable
modules.
D
And
this
is
an
issue
that
will
have
to
res
the
load.
Order
issue
is
something
that
will
have
to
be
resolved
in
order
to
be
able
to
to
instrument
node
fetch
for
now,
but
any
resource
detector.
That
is
added
once
they're
separate
modules.
You
know
you
could
have
any
number
of
resource
detectors
that
may
load
other
modules
also
early
in
the
process.
D
D
J
I
understand
a
bit
about
the
load
order
issue.
I
actually
encountered
something
else
with
a
new
release
that
I
think
comes
down
to
load
order
as
well,
so
yeah
not
to
get
off
topic,
but
I
notice
when
I'm
using
the
sdk
package,
and
I
use
the
collector
exporter.
For
example,
it's
like
I
have
to
initialize
the
collector
exporter
before
to
pass
that
in
the
configuration
to
the
sdk
package
and
I
at
least
get
a
warning
that
you
know.
Grpc
was
loaded
early
and
bart.
J
J
Okay
in
terms
of
doing
the
resource
work
like
yeah,
I
think
it
depends
a
lot
on
timeline,
I'm
pretty
busy
the
rest
of
this
week
and
I'm
off
next
week.
So
as
soon
as
I
would
get
to
that.
That
would
be
like
in
two
weeks,
but
I
would
be
fine
trying
to
cue
up
that
work
if
that
works
for
everybody.
D
Yeah,
that's
fine,
I
mean,
I
guess
I'll
just
leave
it
unassigned
for
now
then,
and
if
somebody
takes
it
between
now
and
then
then
great
and
if
not
you
know
you
can
get
to
it
when
you
get
to
it,
I
guess
it's
not.
D
D
Already
loaded
yeah,
that
was
my
initial
thought,
also
that
it
would
be.
D
Required
as
late
as
possible,
hopefully
after
everything's
already
been
instantiated,
it
would
be
a
little
odd.
I
think
you
would
probably
see
a
trace
to
the
gcp
metadata
call,
but
that's
probably
not
a
problem
to
see
an
extra
trace.
It
is
something
your
application
is
doing.
So
I
guess
it's
not
really
wrong.
K
Just
a
quick
question:
yeah
is
this
something
that
maybe
the
plugin
manager
could
be
useful
for
maybe
loading
the
plugins
before
you
create
a
tracer,
because
I
think
the
tracer
loads,
the
resource
detection
right.
D
J
Let's
see
you
yeah,
I
mean
resource,
auto
detection.
Ultimately
it
isn't
loaded
by
the
tracer
outright.
I
don't
think
I
think
this
is
this
is
something
you
have
to
do
early
on
in
your
process
to
get
things
to
work.
A
Right,
this
is
not
only
about
the
plug-in
loader
but
like
with
the
exporter,
because
it's
using
jrpgc
and
it
need
to
be
instantiated
before,
but
and
that's
already
a
problem
so
to
solve
this,
I
would
say
correctly
would
have
ability
of
like
creating
the
exporter
and
keep
it
in
the
state
that
it
hasn't
been
started.
Yet.
A
Yeah,
I
think
even
go
ahead
yeah
so
because
currently
we
have
like
only
the
export
function,
and
so
that
would
mean,
for
example,
we
could
have
like
kind
of
start.
Let's
say
start
method
on
exporter,
so
we
can
instantiate,
nothing
is
happening
and
before
the
first
call
you
simply
say
start
exporter,
and
then
that
would
be
a
moment
where
you
can
basically
require
or
import
the
required
dependency.
D
Yeah,
I'm
a
little
hesitant
on
that
just
because,
like
when
you
start
to
have
third-party
exporters
you're,
adding
that
requirement
on
them
and
you're
you're,
requiring
them
not
only
to
implement
the
interface,
but
to
know
that
they're
expected
to
follow
this
load
order,
and
if
you
have
some
naive
third
party
exporter
that
can
break
the
process,
I
think
that's
not
ideal.
D
I
think
better
would
be
to
have
plug-in
loading
happen
as
early
in
the
process
as
possible.
D
D
D
I
I
think
the
real
solution
to
this
problem
is
to
move
the
plug-in
loading
to
be
the
absolute
first
thing
and
to
document
clearly
that
it
needs
to
happen.
First,
even
to
the
point
where
we
may
want
to.
D
Log,
a
warning
or
something
like
that.
If,
if
plugins
have
not
been
loaded
when
the
tracer
provider
is
created
or
something
like.
D
That
I
will
I'll
create
an
issue
specifically
around
this,
because
the
current
issue-
that's
open,
is
specifically
the
node
fetch
bug.
D
About
the
load
order
reza,
this
may
actually
affect
your
plug-in
loader.
So
if
we
can
find
a
way
to
easily
incorporate
this
into
your
plug-in
loader,
then
I
may
have
you
you
know.
I
may
work
with
you
on
this.
If
that's
okay,.
K
Yeah
sure
I
was
just
thinking,
maybe
we
can
have
the
plug-in
manager.
I
mean
the
project
that
I'm
working
on
to
not
get
the
meter
or
meter
and
tracer
provider
on
construction
time
and
then
maybe
you
can
call
the
plugin
manager
dot
start
or
something
that
can
get
the
providers
and
then
use
that.
D
K
Yeah,
just
one
thing
that
I
want
to
mention
is
that
my
internship
is
going
to
end
in
next
week
on
friday,
so
yeah
we're
a
little
bit
short
on
time.
Okay,.
D
D
Okay,
are
we
okay
with
this?
Should
I
move
on
to
the
next
topic,
or
does
anyone
still
have
concerns.
D
Okay,
I
just
wanted
to
call
out
the
ga
burndown
project
that
we
have.
There
are
a
handful
of
unassigned
issues
in
here.
You
can
also
find
them
by
looking
at
the
required
for
ga
tag,
but
these
issues
are
high
priority
issues
as
we
move
towards
ga.
So,
if
you're
looking
for
something
to
do
look
at
these
issues
first,
hopefully,
and
then
similarly,
there
are
prs
that
are
required
for
ga
that
are
awaiting
review.
D
Really
nothing
more
than
that-
I
did
add
a
handful
of
plugins
here
that
are
also
not
necessarily
in
that
project,
but
that
are
some
of
them
have
been
around
for
a
while
and
are
adding
new
instrumentation
modules
and
things
like
that,
and
they
are
ready
to
be
reviewed.
So
I
was
hoping
that
people
could
please
review
some
of
these
pr's
so
that
we
can
get
them.
D
I
mean
anyone
can
review
we're,
welcome.
We
welcome
feedback
from
anyone
in
terms
of
the
actual
required
approvals
to
merge.
Then,
yes,
you
do
need
to
be
an
approver
okay.
So
your
when
you
approve
it,
we
can
actually
look
at
the.
D
Id
generator
as
an
example,
if
you're
not
an
approver,
then
your
check
mark
over
here
is
gray
instead
of
green
and
if
you
scroll
down
to
the
required
approvers
thing,
it
says
two
approvals
here,
even
though
there's
three
check
marks
at
the
top.
D
The
feedback
is
welcome,
but
it
does
not
count
towards
the
required
approvals
for
merging.
F
Okay,
I
just
wanted
to
understand
whether
sure
I
can
I
can
still
try
to
add
some
reviews
for
a
couple
of
these,
because
I'm
familiar
but
good
to
know.
Thank
you.
D
Reza
I
saw
that
you
added
this
here.
Are
you
just
looking
for
reviews
on
it,
or
did
you
want
to
talk
about
it
specifically.
K
Yeah
sure
so
last
time
we
talked
about
like
how
you
wanted
to
talk
internally
about
whether
you
want
to
use
the
api,
the
global
api,
tracer
meter
providers,
but
right
now
we
I've
gone
the
path
that
we
talked
about.
Not
using
that,
and
I
mean
it's
using
that
if
no
provider
is
given
to
it
but
yeah
this
apr
is
ready
to
be
reviewed.
Should
I
just
undrafted.
D
If
you
believe
it's
ready
to
be
reviewed,
then
yeah
take
it
out
of
draft.
I
think
most
people
don't
have
the
insane
level
of
notifications
turned
on
that.
I
do
so.
People
are
probably
not
getting
it
in
their
notifications
until
you
take
it
out
of
draft
mode
right
so
yeah.
If
you're
looking
for
reviews,
you
should
mark
it
as
ready
to
review.
F
I
I
didn't
drop
it
on
the
the
sig
google
doc.
F
I
apologize,
but
I
am
curious
about
the
issue
I
opened
regarding
trace
id
injection
into
logs,
which
is
it
seemed
like
the
where
you
know
I
had
sort
of
asked
if
there
was
interest
in
migrating
some
of
the
data
dog
instrumentation
of
like
winston
and
pino
and
bunyan
etc,
and
you
brought
up
a
good
point,
which
is
you
know
it
like
modifies
state
and
it
might
be
better
to
sort
of
like
just
include
examples
which
I
tend
to
agree
with
just
because
in
terms
of
like
actually
getting
something
done.
F
That
feels
like
this
short.
You
know
the
least
friction
the
whatever
the
thing
that
would
get
done
quickest.
Would
you,
if
I
put
together
like
a
you,
know
a
markdown
doc
with
examples?
Should
I
make
a
pr
to
contribute?
Should
I
make
a
pr
to.
D
Say
if
it's
just
like
examples
in
a
markdown
file,
putting
that
in
the
main
repo,
we
have
a
doc
folder
in
the
main
repo,
and
I
would
say
that
that's
probably
the
best
place
for
it.
We,
you
know
we
have
a
handful
of
other
guides
in
here.
D
D
If
you
want
a
new
module
which,
for
example,
like
the
log
form
formatter,
if
you
want
to
create
a
module,
that's
just
an
easily
importable.
You
know
create
a
require.
This
log
form
formatter
and
jam
it
into
bunion,
and
it
will
just
work.
Then
I
think
that
that
would
go
into
contrib.
F
That's
interesting,
yeah,
that's
a
thought
too
yeah
I
mean
what
I
what
I
really
want
is
to
be
a
little
port.
You
know
stupid
automatic
instrumentation.
Okay,
that's
let
me
look
into
that.
It
might
just
be
the
the
lowest
probably
markdown
doc
feels
like
the
thing
that
I
can
most.
You
know
I
can
actually
get
time
to
do
quickly
enough,
but
long
term
it
it's
probably
more
useful
to
have
a
contrib
thing,
but
cool
okay.
Thank
you.
I
just
wanted
to
clarify,
because
I
figured
I
had
you
at
the
you
know.
D
Yeah
and
just
to
be
clear,
like
I'm
not
against
having
an
instrumentation
that
that
injects
log,
you
know
injects
things
into
logs
like
ids
and
things
like
that
into
the
logs.
I
just
think
that
that
shouldn't
be
enabled
by
default,
because
there
are,
I
have
seen
a
lot
of
applications
that
actually
depend
on
the
logging
output
for
behavior.
F
H
D
Processes-
and
things
like
that,
so
I
would
be
very
hesitant
to
modify
the
standard
out
output
right
or
that
without
some
user
saying
yes,
I
want
this.
F
Sure
yeah
definitely
agree.
I
am
curious
what,
because
logs
are
part
of
like
what
the
spec
ends
up.
It
sounds
like
you
had
pointed
to
a
speck
around
how
long
context
should
look
where
it
should
include.
So
I
guess
I
am
curious,
long
term
where
the
responsibility
for
that
lives,
but
for
whether
that's
been
implemented
at
all
or
it's
just
it's
just
a
spec
right
now
that's
been
approved,
but
yeah.
I
definitely
agree
that
yeah,
you
don't
want
to
just
like
start
touching
people's
logs
without
them
explicitly
saying
like.
Yes,
please.
F
D
D
A
D
D
So,
right
now
the
only
two
vendor
specific
modules
we
have
are
aws
and
gcp
mayor.
Obviously,
you
work
for
google
and
you're
hosting
everything
in
the
the
google
cloud
repos.
H
That's
interesting
because
I
I'm
not
the
owner
of
that
particular
repo
for
google
cloud
platform,
so
I
need
to
check
with
the
with
the
team
and
the
owner
of
that
repo,
but
yeah
yeah.
That's
what
I
can
say
now.
D
Yeah
exactly
I
don't
want
to
end
up
in
a
situation
where
we
have
like
a
million
where
we
have
like
the
dynatrace
one
and
the
honeycomb
one
and
the
light
step
one
and
the
new
relic
one
and
everything
just
like
all
propagates
in
the
repo
and
it's
all
proprietary
stuff
and
each
one
is
a
small
maintenance
burden
but
they're.
You
know
there
are
a
lot
of
proprietary
propagation
formats
and
I
I
really
don't
want
to
necessarily
support
them.
All.
H
D
Yeah,
so
that
the
propagator
one
in
particular,
the
the
at
the
maintainers
meeting,
the
other
maintainers
essentially
were
saying
like
because
it's
a
small
piece
of
code-
and
it's
well
documented
how
it
works,
and
it
doesn't
change
very
often
that
it's
okay,
but
I
I
just
see
it
as
a
a
can
of
worms
waiting
to
be
opened
just
because
it's
not
a
problem
now
doesn't
mean
it
won't,
become
a
problem
and
it's
gonna.
It
would
be
very
hard
to
go
back
on
that
decision.
A
D
Well,
we
would
be
the
admins
on
it,
I
think,
but
the
idea
would
be.
You
would
put
right
in
the
readme
like
the
open,
telemetry
maintainers
do
not
maintain
this
code.
This
is
maintained
by
the
vendors
and
we
would
only
accept
a
module,
probably
with
like
the
readme
would
contain.
D
This
is
the
the
contact
person
at
the
vendor.
You
know
like
so
you
would
have
for
issues
with
the
gcp
propagator
contact.
You
know
this
person,
but
we
we
would
put
very
explicitly
in
there
like
we
as
open
telemetry,
make
no
guarantees
about
this
code.
D
I
I
think
that
that
is
I.
I
would
be
okay
to
do
that,
but
I
think
the
vendors
probably
wouldn't
necessarily
want
that
because
then
that's
the
worst
of
both
world
worlds.
For
them,
they
don't
own
the
repository
and
it's
not
being
maintained
by
the
open
source
community,
which
would
be
the
advantage
for
them
of
having
it
hosted
by
open
telemetry.
D
So
then,
we
end
up
at
a
point
where
we
have
every
vendor
has
to
have
somebody
who
has
right
access
on
the
repo
and
it
would
be
on
the
whole
repo.
D
I
I
think
we
probably
I
mean
I
am
leaning
towards
just
saying
I
don't
want
to
support
vendor
specific
code
in
in
our
repositories
and
leaving
it
like
that
and
letting
letting
aws
do
the
same
thing.
That
gcp
is
doing
where
you
host
it
in
your
own
repositories
and
when
you
have
bug
fixes
you
have
your
own
maintainers
that
can
merge
them
and
things
like
that.
D
They're
working
on
it,
I
think
I
don't
think
it's
been
public,
but
I
I
know
they're
working
on
it,
because
the
same
intern
kong,
I
think
is
his
name.
Is
writing
the
propagator.
Originally
he
reached
out
to
me
asking
where
should
this
live
and
he
asked
about
the
propagator
and
the
exporter
and
what
I
told
him
at
the
time
was
we're
not
hosting
the
exporter,
but
we
can
talk
about
maybe
hosting
the
propagator.
D
H
So
what
I
was
saying
is:
if,
if
export
is
there
and
if
they
are
managing
the
exporter,
then
like
moving
this
propagator,
there
won't
be
a
big
ask
for
them.
H
What
right
so,
at
least
on
aws
perspective,
I
don't
see
big
issues
hosting
this,
maybe
maybe
for
the
companies
like
who,
who
don't
have
their
own
repos
and
they're,
not
managing
the
stuff.
H
Maybe
it
would
be
harder
for
them
to
do
and
the
the
option
that
bath
suggested
having
the
third
ripple
together
that
might
work
for
them.
D
D
A
H
Yeah
so
now
we'll
wait
for
that
intent
to
get
back
to
us
right
and
we
are
not
accepting
the
vendor-specific
thing.
D
Yeah,
we're
not
gonna,
accept
the
pr.
I
guess
I'll
comment
on
the
pr
that
we
talked
about
it
and
after
I
I'll
probably
tag
you
guys
in
the
comment
just
so
that
you
can,
you
know,
give
it
a
thumbs
up
or
whatever
so
that
it.
They
know
that
we
all
three
of
us,
talked
about
it
and
feel
the
same
way.
H
Yeah
but
yeah,
so
you
know
recently,
I
have
been
doing
a
lot
of
work,
internal
google.
So
that's
why
I'm
not
able
to
find
a
good
time
to
spend
on
this
open.
Telemetry
thing
like
we
have
something
called
20
work,
so
I'm
committed
to
do
20
stuff
on
the
open
telemetry,
but
that
is
also
unofficial.
I
would
say
so.
H
That's
okay!
For
now!
Actually
so
the
thing
is
yeah
that
that's
my
current
status
on
the
on
the
open
telemetry
side,
if
you
guys
feel
if
I'm
not
active
and
not
contributing,
much
then
feel
free
to
remove
me
from
the
maintenance
list
and
maybe
put
in
the
uproars
and
like
like,
whatever
you
feel,
is
good.
D
So
I
think
for
now
I
like
having
three
maintainers
for
a
handful
of
reasons.
If
you
have
an
odd
number,
then
it's
easier
to
resolve
conflicts
right,
because
if
you
have
two
people
want
one
thing
and
one
person
said
you
know
it's
easier
to
say
you
know
majority
rules
here
and
just
having
more
people
that
can
approve
and
merge
prs.
Even
if
you
don't
have
a
ton
of
time
to
do
it,
you
still
do
every
now.
You
know
it's
not
like
a
zero.
D
D
So
I
guess
before
we
talk
about,
you
know
removing
you
as
a
maintainer.
I
would
want
to
talk
about
who
we
would
want
to
promote
and
make
sure
that
they
have
time,
and
everything
like
that.
I
know.
H
D
Lot
of
people
are
only
contributing,
you
know,
10
15,
20
of
their
time,
it's
hard
to
find
people
that
are
contributing
50
or
more.
So,
I
think
you're,
probably
you
know,
probably
still
above
average
in
terms
of
the
amount
of
time
you're
spending,
even
among
the
the
other
approvers.
I
don't
know
if
any
of
the
others
are
anywhere
near
full-time
on
this
anyways.
H
Okay,
but
at
least
from
now
we
can
kind
of
I
don't
know.
Personally,
I
thought
I
should
talk
to
you
and
see
what
you
guys
think
about
this.
I
didn't
want
it
to
be
like
not
active
that
much.
That's
why
I
just
wanted
to
discuss
with
you
and
see.
What's
your
opinion,
yeah
yeah,
maybe
one
thing
we
can
do
is
in
next
month
or
two.
D
D
Then
we
have
mark
wolf,
legendicus
and
nassim,
and
I
think
I
think
all
of
them
are
in
a
similar
vote
to
you,
where
they're
only
really
able
to
contribute
sort
of
you
know
a
small
percentage
of
their
time.
I
don't
think
they
have
dedicated
time
to
the
project
I
see
so
I
just
don't
see
who
else
we
would
promote.
But
if
someone
comes
up
or
if
you
think
of
someone-
or
you
know
anything
like
that,
then
you
know
I'm.
H
Yeah
sure
so
I
mean
I'm
still
trying
to
find.
I
find
a
time
to
review
and
contribute
in
between,
and
it's
going
to
be
like
this
for
next
month
or
two,
but
for
the
longer
term,
I'm
I'm
not
sure.
What's
how
it's
gonna
look
like.
So
we
have
new
team
in
sydney
in
google
who
is
taking
responsibility
of
open
telemetry,
so
they
hired
already
three
people,
I
believe,
and
they
already
working
on
collector
java
and
go
repo.
H
So
I
think
the
plan
is
to
have
two
more
contributors
on
python
and
node,
but
sorry
full-time
contributors,
yeah.
Those
are
like
full-time
contributors
like
like
me.
I
was
like
earlier.
There
was
four
contributors
on
open
telemetry
from
google
side
all
were
doing
only
open,
telemetry
thing
and
that's
what
we
are
trying
to
build
in
sydney.
There
is
three
contributors
already,
and
hopefully
I
mean
I
don't
know
whether
they'll
hire
or
they'll
divide
their
work
into
repos.
H
But
there
is
some
plan
on
that
side
and
yeah.
Meantime,
I'm
still
still
trying
to
find
the
time,
but
just
wanted
to
let
you
know
before
the
time
I
mean
we
still
have
a
month
or
two
months
or
maybe
maybe
more
than
that,
but
just
wanted
to
share
this
thing
with
you.
Okay,.
D
Well,
I
appreciate
you
letting
us
know.
I
guess
this
is
something
that
we
should
just
keep
in
mind
that
ga
is
coming
up.
So
you
know
I
I
don't
know.
If
we
get
too
close
to
ga,
I
don't
think
we
want
to
rock
the
boat
too
much,
but
also,
if
you
find
that
you
don't
have
enough
time
to
contribute
on
it,
I
don't
want
that
to
necessarily
hold
up
the
ga
effort
either.
So
it's
just
something
that
we're
gonna
have
to
balance.
H
Right
so
I
I
discussed
this
with
my
manager,
and
I
mentioned
the
same
thing.
Ga
is
gonna
come,
and
I
would
like
to
be
there
around
that
time.
H
So
I
mean
yeah
that
that's
the
thing
we
discussed
and
the
one
more
point
I
wanted
to
the
one
more
reason
I
wanted
to
say
this
is
because
I
didn't
wanted
others
to
say
this
thing
about
me
like
this.
Guy
is
not
contributing
and
still
he's
maintainer
and
all
kind
of
thing.
That's
why
proactively?
I
wanted
to
share
this
point
with
you.
Both.
D
Yeah,
okay,
nobody
has
brought
up
anything
to
me.
I
don't
know
if
anyone
has
with
you
bart,
but
I
I
don't
think
it's
a
problem.
No
yet,
but
if
it
becomes
a
problem
we'll
just
you
know
we'll
talk
about
it,
then
I
guess.
A
I
don't
understand
that
basically,
the
that
provides
another
focusing
on
writing
the
code,
so
the
number
of
people
that
really
do
the
radius,
not
that
much
as
I
would
like
to
yeah.
H
Yeah
I
mean
we
had
a
two
approver
like
without
doing
anything
for
like
more
than
six
months.
I
believe
no
one
complained
about
that.
G
D
H
Awesome
then
yeah
I'll
try
to
find
time,
and
I
will
guys
I
will
update
you
guys
if
I,
if
something
change
in
next
month
or
two
months
and
all
okay
thanks.