►
From YouTube: 2021-09-22 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
C
B
D
D
There
was
already
a
pr
which
moved
prometheus
to
the
experimental
directory.
This
is
because
prometheus
depends
on
metrics,
which
are
also
all
experimental.
So
there
was
no
no
reason
and
not
a
good
idea
to
make
the
prometheus
exporter
stable.
D
So
that's
been
done.
Will
ramiros
is
working
on
splitting
the
otlp
exporters
into
separate
packages
for
traces
and
metrics,
and
I
think
he's
going
to
talk
about
that
a
little
bit
later,
so
just
hold
off
on
that.
For
now.
D
And
bart
obechny
created
a
pr
to
vendor
the
lowdash.merge
dependency
in
order
to
fix
our
esm
builds.
So
any
reviews
on
that
pr
are
welcome,
but
bart,
correct
me.
If
I'm
wrong,
it's
mostly
just
a
directly
copy
and
pasted
implementation,
correct.
E
No,
it's
not
it's
completely
different.
Oh
the
only
things,
the
only
things
from
low
dash
merch
is
the
way
they
detect
whether
this
this
object
should
be
should
be
measurable
or
it's
object
rated
from
the
classroom,
so
it
shouldn't
be
measurable
at
all.
So
this
is
the
only
functionality.
B
D
The
first
issue
that
I
wanted
to
talk
about
today:
I've
actually
run
into
this
twice.
In
the
last
week,
I've
had
users
reach
out
to
me
and
say
that
they're
confused
they're
trying
to
get
started
with
open,
telemetry
and
they're
looking
through
the
examples
and
that
the
examples
don't
work
for
them
and
that's
because
the
examples
typically
show
what
we
have
in
the
github
main
branch
not
what's
been
released.
D
D
But
I
think,
if
we're
going
to
have
something
like
that,
we
should
have
a
directory
named.
D
D
D
I
assume
from
the
silence
that
people
think
it's
okay
to
to
change
the
examples
so
that
they
only
show
released
functionality.
G
Oh,
I
was
just
a
comment
on
the
silence
because
I
feel
like
when
I
come
in
and
yeah
go
to
the
examples
I
kind
of
like
the
idea
of
being
able
to
just
clone
it
or
run
it,
as
is
so.
It
would
be
nice
if
they
were
referencing
published
packages,
because
I
wouldn't
want
to
set
up
lerna
locally.
D
Yeah
and
I
think
a
lot
of
people
not
only
do
they
not
want
to
set
up
learner,
they
don't
realize
that
you
have
to
and
then
even
to
get
the
examples
to
work
against
the
unreleased
packages.
You
have
to
modify
the
learn
adjacent
because
I
don't
think
the
examples
are
in
the
learn
adjacent
by
default.
I
could
be
wrong
about
that.
In
any
case,
it
is
kind
of
weird
and
I
think,
for
new
users
in
particular.
D
Yeah
stable
a
lot
of
things
are
less
of
an
issue
once
we're
stable
because
they
just
won't
change.
As
often
that
said,
some
of
the
examples
do
reference
experimental
packages,
so
it
is
something
that
I
think
we'll
still
run
into
a
little
bit,
but
I
think
what
I'm
really
getting
at
is
right.
Now
we
treat
those
examples
as
a
development
tool
and
I
think
we
should
really
start
treating
them
as
documentation.
E
E
I
mean
this
would
be
like
a
documentation
either.
I
don't
know
whether
this
would
be
a
new
repo
or
a
new
page
or
anything
just
would
be
some
kind
of
documentation,
because
I
mean
the
reality
is
like
we.
E
I
E
Examples
to
be
able
to
to
debug
and
add
new
stuff,
basically
and
people
will
need
some
like
nice
entry
point
of
of
scene
and
without
the
need
of
cloning,
or
anything
just
just
the
examples,
and
if
they
are
not
working
already,
so
I
mean
if
we
keep
them
in
the
way
that
we
keep
now
we'll
be
just
confusing
them,
no
matter
how
we
call
it.
I
think,
because
there
will
be
always
like
up
to
date
with
the
master
and
not
with
the
latest
release
yeah.
D
Yeah,
so
I
think
what
I
would,
what
I
would
say
is
we
should
take
all
of
the
examples
we
have
take
that
examples
directory
and
just
rename
the
directory
to
be
test
apps
or
something.
D
And
then
create
a
new
examples
directory,
I
think
if
we
create
it
as
a
separate
repository,
it's
likely
to
be
completely
forgotten
about
by
most
people
and
much
harder
to
find
for
new
people.
We
just
google
open
telemetry.js.
D
E
E
I
mean
no,
the
they
would
still
go
to
the
to
the
main
repo,
but
I
don't
know
in
the
readme
we
could
put
like.
I
don't
know
the
examples
and
somehow
easy
for
the
people
to
find
a
certain
example
for
the
certain
version,
and
if
that
means
we
just
can
do
this
with
the
links.
Fine.
If
not,
then
I
know
we
can
think
of
some
smarter
solution,
because
currently
people
going
to
the
repo
and
yeah
they
they
see
the
master
examples
instead
of
the
release
one.
D
Yeah
I
mean
we
definitely
could
you
can
link
to
like
a
specific
tag.
Yes,
examples
tags,
you
know,
maybe
we
create
like
a
latest
tag
or
something
like
that
and
you
know
move
it
every
time
we
have
a
release.
That
could
be
one
way
to
do
it.
No.
E
They
don't
need
to
be
linked
by
learner.
People
just
want
to
see
in
a
certain
version
how
a
copy
paste
examples
to
be
ready
to
to
use
in
their
own
reaper
in
their
own
code
and
currently.
B
D
Right
now
we
have
this
sdk
trace
base,
which
I
believe
is
not
yet
released
linked
by
at
least
this
example.
B
There's
two
distinct
issues
here:
one
one
is
actually
going
through
like
a
history
of
examples
and
navigating
those
which
is
I'm
something
I'm
not
talking
about
right
now,
but
yeah
I
was,
I
was
curious
about.
How
does
it
actually
break
and
I
guess
there
are
references
to
modules
that
will
be.
I
guess
then
installed
from
the
root
it
cannot
be.
It
looks
weird
the
the
view
I'm
looking
at
right
now.
The
the
single
require
here.
D
So
this
is
just
this
is
the
otlp
example.
If
you
look
in
the
package
jason,
it
lists
the
sdk
tradespace,
which
is
not
released
at
version
25.
I
believe
it
was
a
different.
It
was
tracing
right.
A
Hey
just
just
several
speaking
sorry
for
being
late.
I
I
just
joined
you
and
I
think
I
I
I
joined
at
the
right
point
because,
as
you
remember,
that's
a
topic,
I'm
I'm
also
curious
about.
So
if
I
get
this
right,
the
problem
is
that
the
examples
do
not
compile
because
they
link
into
into
packages
not
released.
But
that
means
we
need
to
make
sure
that
yeah
we
we
disconnect
them
from
from
learners.
So
that
that's
what
I
understand
right
now.
A
D
E
Whenever
you
match
something,
it
goes
directly
to
the
master,
but
it's
not
yet
released.
So
if
you
adding
a
new
things
or
changing
something
in
the
master,
you're
also
updating
the
example.
So
once
you
do
it,
the
examples
are
already
already
outdated
towards
the
version
you
are
using
right
at
the
moment.
So
I'm
talking
to
have
the
examples
that
are
strictly
dedicated
to
each
version
that
we
released
and
how
we
achieve
that.
That's
another
story.
E
D
D
The
readme
is
pretty
good,
but
the
code
itself
is
is
not
exactly
obvious
and
it
has
extra
things
that
aren't
really
needed
to
show
how
to
set
up
the
collector,
and
then
we
have
like
an
example
for
each
instrumentation
package,
which
is
not
exactly
how
we
would
normally
expect
them
to
be
used,
because
we
would
normally
expect
the
user
to
install
an
auto
instrumentation
package.
D
I
think
we
need
to
just
create
a
new
set
of
examples
that
are
far
fewer
examples
that
are
significantly
simpler,
and
you
know
very
verbosely
documented,
so
that
when
new
users
are
looking
for,
how
do
I
get
started
with
open
telemetry
when
they
look
at
the
examples?
They
don't
get
completely
lost.
A
I
I
mean
on
that,
and
I
mean
if
you
now
go
into
the
open
telemetry.js
it
lit
with
the
getting
started.
It
still
links
to
getting
started
in
the
repo,
and
I
think
that
piece
is
broken.
Anyways
shouldn't.
We
also
make
sure
that
this
links
back
to
the
open,
telemetry
docs
itself,
where
we
have
at
least
a
few
of
those
examples
that
that
are
documented
and
very
both.
A
So
if
you
go
into
into
the
open
into
the
readme
md
of
the
of
the
repository
itself,
and
if
you
click
here
on
getting
started,
then
then
you
are
still
in
the
repository,
and
my
understanding
was
that
this
example
here
is
not
working
anymore.
A
As
you
know,
there's
a
very
similar
thing
now
I
what
I
also
try
to
to
build
out
in
the
open
telemetry
I
o
docs,
there's
also
a
getting
started
section.
So
I
think
the
very
first
thing
we
need
to
do
to
not
confuse
people
is
making
sure
that
that
it's
clear
where
things
are
living
because
there
is
like,
I
think,
if
you
go
here
into
the
no
chess
example,
it's
it's
let's
say
similar
to
to
what
you
find
there.
A
So
I
think
the
first
start
would
be
to
say,
like
hey,
they're,
getting
started,
you
find
it
here
and
then
maybe
here
we
add
a
section
called,
or
this
actually
already
won,
instrumentation
examples
where
we
then
link
back
and
maybe
really
also
call
out
like
hey
those
are
test.
Apps
they're
not
really
relevant,
but
here's,
maybe
a
few
other
apps
you
you
could
use
to
to
learn
more.
A
Explaining
what
they
are
exactly,
maybe
really
for
now
is
to
to
to
fix
the
problem
for
now
to
say,
like
hey
those
those
are
not
let's
say
examples
in
that
sense.
Those
are
more
yeah,
as
you
said,
test
apps
to
to
play
around
with
things
and
then,
as
you
said,
building
a
a
better
example
or
a
better
set
of
examples
that
are
eiser
also
documented
here
in
in
the
docs
or
our
verbose
as
they
are
and
there's
an
open-ended
question
to
that.
A
I
was
wondering
anyways,
it's
like
if
we
have
that
kind
of
example,
and-
and
I
think
I
like
the
idea
of
having
an
examples
repository,
why
should
this
be
only
javascript?
Why
not
have
one
that
spans
over
multiple
languages
to
make
it
clear
to
end
users
how
to
interact
with
that?
Having
like
I
have
javascript,
I
have
go
and
those
pieces
are
working
together.
That's
maybe
long-term
thinking,
but
but
that's
also
something
that
that's
floating
around
in
my
head.
D
I
D
Likely
want
to
have
those
examples
directly
on
the
website
and
I
think
that
that's
probably
the
right
place
for
it.
I
mean
that's
almost
what
you're
talking
about
right
here
is,
I
see
a
list
of
languages
and
some
of
them
like
I
know
the
collector
actually
has
some
decent.
You
know
configuration
examples
here.
I
think
that
go
has
a
decent
getting
started
going
on
here,
and
I
think
that
this
is
probably
the
correct
place
for
something
like
that.
A
Also,
I
said
the
javascript
one
is:
is
not
bad
so
so
I
mean
you
can
you
can
go
through
that?
So
I
mean,
but
still,
let's
say
a
few
things
copied
over
from
from
the
example
folders.
It
could
be
better
and
I
said
I'm
happy
to
help
with
that,
improving
on
that,
but
I
think
yeah
this.
E
Yeah,
okay:
is
there
any
way
to
have
here
like
some
kind
of
versioning,
so
you
could
see
the
documentation
from
different
version.
D
I
I
I
mean
it
would
technically
be
possible,
but
I
think
at
that
point
it's
a
lot
more
work,
for,
I
think,
a
pretty
limited.
H
E
D
E
You
take
whatever
was
in
the
previous
version
and
create
a
just
javascript
invention,
025,
then,
and
if
we
don't
have
like
documentation
for
the
newest,
I
think
that's
okay,
but
at
least
we
indicate
this
here
and
we
will
have
to
update
it
whether
this
will
be
a
copy
paste
and
then
updating
few
things.
That's
another
story,
but
but
this
user
won't
be
confused
like
what
is
what
and
why
why?
He
see
the
example
and
with
the
latest
it
doesn't
work.
D
D
I
mean,
I
think,
that
generally
the
website
docs
are
pretty
good
right
now
from
from
a
getting
started
standpoint,
they
can
maybe
be
expanded
a
little
bit
to
show
how
to
use
different
exporters
and
stuff
like
that.
But
even
this,
I
think,
is
pretty
good.
D
D
A
I
think
there's
a
few
things.
That's
then
required
to
review
the
docs
again.
So
I
said
maybe
also
then
removing
the
link
back
to
to
the
examples
or
to
calling
out
that
is
a
test
app
and
then,
as
you
said
like
considering
to
to
build,
build
a
new
yeah
example
app
that
that's
maybe
going
beyond
the
getting
started,
maybe
something
maybe
even
an
example-
application
that
that
makes
sense
already
or
has
some
some
back
ends
or
whatever.
D
A
Exactly
yeah,
did
you
say,
there's
an
express
and
then
maybe
it
uses,
I
don't
know
a
mongodb
or
postgresdb
at
the
back
end,
and
so
you
have
some
we're
calling
out.
I
don't
know
some
external
api
to
to
get
some
prices
or
stock
market
information
or
whatever,
so
that
you
have
some
some
good
understanding.
What
what
you
can
see
than
in
traces
and
what
not.
D
Well,
maybe
I
think,
probably
for
an
example
like
that
we
would
want
to
show
how
to
do
like
the
the
auto
instrumentation
package,
where
it
just
pull
down
instrumentation
all
or
something
like
that
and
use
the
defaults.
I
don't
think
we
would
do
anything
very
specific
to
any
instrumentation
module
or
anything
like
that.
E
A
That
I'm
missing,
maybe
it's
just
as
a
side
note
thinking
about
it
and
I'm
I'm
just
thinking
out
loud
again.
Maybe
this
whole
example.
Maybe
it
could
also
be
some
kind
of
let's
say
microservice
in
javascript,
so
that
we
then
say
if
the
go
community
is
building
another
service
and
then
we
can
stitch
them
together
at
some
point,
so
this
is
really
more
like
hey.
A
Maybe
it's
it's
it's
flexible
enough
to
to
bring
it
together
with
other
examples
that
that's
just
a
open-ended
idea,
because
I
mean
at
the
end
what
what
people
are
going
to
do
is
have
some
micro
service
architecture
where
they
have
different
services,
doing
different
things,
and
so
maybe
javascript
is.
I
don't
know
whatever
part
of
that.
That
could
be
interesting.
I
E
D
And
stuff
like
that,
yeah
yeah,
I
think
it's
a
good
example
or
a
good
idea.
I'm
sure
that
there
are
already
example
projects
like.
I
know.
Google
and
microsoft
have
like
microservice
example,
projects
that
we
could
probably
you
know,
show
an
instrumented
version
of
of
something
like
that.
Like
a
fake
e-commerce,
app
of
some
kind.
A
D
Okay,
I
mean,
I
think,
that
that's
probably
a
little
bit
more
of
a
longer
term
goal
in
terms
of
what
we
can
do
right
now.
I
think
that
these
items
are
probably
you
know.
These
are
things
that
we
can
do
quickly
to
drastically
improve
the
situation
in
a
very
short
period
of
time.
D
F
F
F
So
I
mean
in
that
sense
renaming
it
to
test.
Apps
is
a
little
confusing,
but
I
guess
you
said
that
you'd
be
okay
with
still
linking
to
those
right.
D
Yeah,
I
just
think
examples
if
I'm
a
new
user-
and
I
go
to
a
repository-
and
I
see
a
folder
named
examples-
I
very
often
just
click
on
it
and
start
looking
through
that
and
if
they're
not
it's,
not
clear
that
those
aren't
really
meant.
As,
like
an
entry
point,
I
usually
expect
you
know
an
examples
directory
to
be
sort
of
an
entry
point
for
a
new
user
where
ours
clearly
is
not.
D
I
mean
maybe
we
have
two,
maybe
in
the
examples
folder.
We
have
like
some
simple
examples
and
then
we
just
have
a
subdirectory
of
the
examples
directory.
That's
like
advanced
or
something
like
that
that
we
put
you
know
more
of
a
dumping
ground
for
that
for
the
types
of
examples
we
already
have.
D
I
do
think
we
should
have
an
examples
folder
with
some
simple
examples.
I
just
think
the
examples
that
we
currently
have
are
not
you
know
they
just
need
some,
some
updating
and
some
commenting,
and
some
of
them
need
some
readmes
to
be
updated
a
little
bit
to
make
it.
You
know
more
clear
what
they
are
and
what
they're
trying
to
show.
D
Like,
for
example,
in
the
contributory,
both
we
look
at
the
contributory
bow,
there's
like
an
example
for
each.
You
know
instrumentation
module
where,
if
you
look
in
here
they're
depending
directly
on
like
these
instrumentations,
when
most
of
the
time,
I
think
what
we
will
actually
expect
is
for
users
to
depend
on
these
auto
instrumentation
packages,
which
already
pull
in
all
of
those.
D
Yeah
that's
kind
of
what
I'm
getting
at
and
then
I
think
like
these.
These
examples
that
we
have
that
only
like
you
know
show
one
package
like
this
example
can
maybe
just
be
moved
into
the
mysql
instrumentation,
because
it's
very
specific
to
my
sequel.
I
don't
think
there's,
although
maybe
that
makes
it
more
difficult
to
discover.
B
E
D
So
I've
been
put
in
the
chat
here,
I'm
sorry
to
kind
of
change
the
subject
a
little
bit.
I've
been
put
in
the
chat
here
that
he
already
has
a
full-blown
example
with
the
hotel,
collector
and
prometheus.
E
I
Yeah
for
some
zom,
this
you
use
nashjs,
but
the
concept
is
the
same.
It's
just
a
quick
replacement
for
node.js.
I
D
J
Yeah
for
sure,
so
I
I
did
make
the
pr
and
for
context
the
purpose
of
the
pr
of
is
that
currently,
the
exporter
packages
in
the
core
repo
contain
exporters
for
both
traces
and
metrics
and
by
virtue
of
having
metric
exporters,
depend
on
the
on
submetric
packages,
which
are
still
experimental,
and
so
the
idea
was
that
we
shouldn't
be
moving
the
x
border
packages
to
1.0
stable
if
they
still
have
experimental
dependencies.
J
So
this
pr
separates
the
metric
exporters
into
new
packages,
one
for
each
protocol
that
are
in
the
experimental
directory
along
with
all
of
the
other
metrics
packages,
and
then
they,
the
metric
exporters,
depend
on
the
stable
trace
exporters
for
kind
of
just
like
some
common
or
base
logic,
and
so
there
there
were
just
kind
of
two
things
that
I
wanted
to
bring
up
or
call
out
in
the
meeting
and
make
sure
that
everyone
was
like
seen
the
same.
J
The
only
way
to
merge
this,
while
you
know
passing
the
ci,
is
to
basically
do
it
in
two
pr's
and
so
the
first
pr
would
just
remove
all
the
metric
things
from
the
stable
packages,
and
then
we
would
release
the
stable
packages
so
that
they
are
available
in
npm
and
then.
Lastly,
we
would
add
the
metric
packages
into
experimental
in
a
second
pr.
E
But
I
I
was
quite
against
doing
this
and
I
said
that
in
the
discussion
that
we
have
that
we
should
first
I
mean
you
move
this
to
the
to
the
experimental
without
changing,
really
anything,
because
I
think
we
there
is
really
high
chance
of
breaking
something
and
we
call
it
stable
and
by
splitting
this,
then
we
can
think
of
of
doing
this,
because
I
mean
there
were
also
some
attempt
in
the
in
the
past
of
refactoring
this
too,
so
that
we
can
have
some
some
functions
and
just
for
converting,
for
example,
data.
E
J
So
is
the
problem
that,
in
the
experiment,
like
the
there's,
a
high
chance
that
when
we
release
the
main
exporters
as
as
stable
like,
we
could
have
to
still
go
back
and
make
breaking
changes
to
accommodate
the
metric
exporters
or.
D
It
as
stable,
you
know,
stable
sort
of
implies
that
it's
been
used
and
tested
and
that
we
expect
it
to
work.
But
if
we
make
a
change
this
big
and
call
it
stable,
that's
not
necessarily
you
know
good
practice.
E
E
E
You
were
trying
to
split
some
time
ago,
also
the
the
functionality
that
is
in
the
exporter
collector,
and
we
might
also
think
about
this
when,
when
doing
this
refactoring,
so
maybe
we
can
have
like
a
base
class
with
just
converting
the
data
and
then
all
exporters,
whether
this
is
metric
or
tracy,
can
inherit
from
this
package.
E
Convert
data
and
just
do
like
appropriate
transport,
and
that's
it
nothing
more.
K
J
Yeah,
so
I
I
I
cannot,
I
can
make
that
change
to
this
pr,
and
I
think
that
would
be.
That
would
definitely
be
a
doable
change
for
this
pr
to
also
separate
out
the
trace
packages
and
move
them
into
experimental.
J
It
really
should
be
the
same
thing
as
what
I
currently
have
and
just
moving
the
trace
packages
into
experimental
and
yeah,
and
then
we
can.
We
won't
have
to
do
the
two
pr
business,
because
they'll
be
able
to
be
linked
via
learner
if
they're,
both
an
experimental.
E
E
D
D
Obviously,
it
will
need
to
live
there
for
some
time
to
make
sure
that
it's
well
tested,
but
I
think
that
it
should
be
a
high
priority
for
us.
J
Yeah
I
I
would
agree
with
that
and
yeah.
I
don't
know
if
any,
if
barter
anybody
else
wants
to
make
that
change
to
just
move
them
into
experimental
or
yeah,
move
them
to
experimentalizes,
and
then
I
can
do
a
pretty
ugly
rebase
on
this
and
just
try
to
keep
the
same
pr
for
splitting
them,
which
we
can
merge
later
on.
J
That
makes
sense:
okay,
yep
so
I'll
rebase.
On
top
of
that,
but
yeah
that
I
mean
that
would
be
great
if
it
unblocks
the
1.0
release,
at
least
because
that
would
definitely
be
very
useful.
J
The
only
other
thing
was
just
this
bug
that
I
was
having,
but
if
it's
all
an
experimental
then
it
should
actually
be
showing
up
in
ci
and
be
easier
to
explain
but
yeah
bart.
I
saw
that
you
kind
of
were
had
written
a
lot
of
those
tests.
I
think
that
I
was
having
this
really
tricky
plug
on,
but
if
you
just
have
a
second
to
read
through
it,
I
don't
know
if
it's
totally
gibberish
or
not,
but
yeah.
J
J
But
yeah:
that's
that's
pretty
much
it
from
for
this
pr,
then,
and
if
they
are
on
experimental,
that
actually
probably
makes
things
considerably
simpler.
Maybe
that'll
help
resolve
it.
H
Okay
is
that
it
then
yeah,
I
think
so.
Okay,.
D
H
D
E
Yeah,
I
did.
I
have
just
worked
in
progress.
Also.
I
have
already
some
integration
tested
test,
our
instrumentations
on
a
different
browsers,
even
on
ie.
So
so
this.
C
E
I
mean
I
can
make
some
draft
pr
in
the
end
of
this
week.
I
mean
it
it.
It
won't
be
rather
in
the
state
that
it
can
be
pushed,
but
it's
because
I
mean
that
it
should
be
integrated
ci
currently
and
running
this
locally.
So
you
have
to
have
access
to
the
prostate
stack
account
to
be
able
to
run
them
yeah,
but
you
can
also
run
them
like
locally.
E
D
Okay
and
the
last
item
that
I
wanted
to
talk
about
for
those
that
didn't
notice
or
see,
we
did
have
the
first
like
release
using
release.
Please,
and
it's
named
it
to
go
relatively
smoothly,
so
we
released
the
aws
lambda
version,
26
automatically
and
also
the
test
details,
so
it
seems
to
be
working
pretty
well.
So
thank
you
to
people
who
have
helped
contribute
to
to
this.
D
The
release
prs
will
be
created
as
we
merge
things
into
main.
We
just
need
to
be
very,
very
sure
that
we're
using
the
commit
messages,
f-e-a-t
and
fix
you
know
prefixes
on
the
commit
messages
so
that
the
versions
are
properly
incremented.
D
That's
going
to
be
very
important
to
make
sure
that
this
automation
works
smoothly
for
everybody,
but
that
said,
I
think
I'm
going
to
try
to
get
into
a
cadence
of
merging
that
pr
at
least
once
a
week
and
if
it
goes
smoothly
for
a
while,
I
may
even
automate
it
so
that
it's
automatically
automatically
released
on
each
merge
to
main,
but
probably
not
for
for
a
while,
but
just
for
those
that
are
interested
in
this,
it
seems
to
be
working.
So,
no
a
few
weeks
of
work
to
get
this
working.
D
One
quick
caveat
that
I
do
want
to
mention
that
we
had
with
this
release
that
will
is
already
familiar
with
the
aws
and
packages
depended
on
unreleased
changes
in
the
test
utils
package,
which,
because
in
ci
the
lerna
links
those
properly
the
ci
passes
on
a
pull
request,
but
for
the
actual
release
because
it
bumped
the
version
numbers
of
the
test
utils
package,
I
the
ci,
actually
failed.
So
I
was
able
to
manually
modify
the
release
pr
so
that
it
would
work.
D
We
need
to
make
sure
that
those
changes
are
released
before
we
depend
on
those
changes
in
the
instrumentation
packages
or
the
release.
Pr
ci
will
fail.
D
D
That
was
everything
that
I
had
on
the
agenda
today,
I'm
probably
going
to
get
started
on
cleaning
up
some
of
the
examples,
and
I
think,
once
the
exporters
are
moved
into
the
experimental
directory,
we'll
probably
be
ready
for
a
a
release.
D
E
D
I'll
try
to
do
that
fairly
quickly
and
if
everything
goes
well,
that'll
be
this
week,
so
I
guess
look
out
for
those
pr's
and
thank
you
everybody
for
your
time,
and
I
will
talk
to
you
next
week,
see
you.