►
From YouTube: 2022-01-19 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
B
C
C
D
C
D
Oh
okay,
can
you
can
you
put
the
that
link
in
the
in
the
document.
A
G
A
G
G
And
I
will
recreate
the
zoom
link
for
next
weeks
and
at
some
point
next
week
I
will
set
things
back
to
the
way
they
used
to
be
in
zoom,
or
at
least
that
might
take
a
few
weeks
to
set
them
back,
because
we're
gonna
need
a
couple.
New
zoom
accounts
from
the
cncf.
That's
why
we
switch
to
this
mode,
because
we
had
four
overlapping
meetings
and
we
only
had
three
accounts.
G
Maybe
zoom
is
just
working
on
a
on
a
mechanism
for
time
travel.
That's
not
quite
ready.
Yet
no,
it's
it's
a
generic
error.
So
if
you
join
from
the
browser
you
actually
it's
not
generic.
If
you
join
from
the
browser
instead
of
the
client
app,
you
get
a
different
error.
Interestingly,
if
you
join
from
the
browser,
it
will
say
that
the
host
is
not
yet
in
the
meeting,
which
is
interesting
because
all
of
our
meetings
have
configured
are
configured
to
not
require
the
host
to
be
in
the
meeting.
G
But
it's
it's
it's
an
issue
of
zoom
where
we
used
to
have
for
those
who
don't
know
like
multiple
zoom
accounts,
so
we
would
just
use
zoom
instant
meetings,
and
so
then,
if
you
had
overlapping
meetings
like
four
at
the
same
time,
you
needed
four
different
zoom
accounts,
and
so
people
had
to
manually
sort
of
use
those
ids
and
and
if
we
ever
had
five
overlapping
meetings,
suddenly
couldn't
do
it.
G
So
we
switched
to
using
one
zoom
account
and
scheduling
it
kind
of
the
way
a
human
would
with
their
calendar,
where
you
have
unique
ids
for
each
meeting
and
apparently
zoom
doesn't
like
that.
Sometimes
for
all.
I
know
it's
almost
like
a
drmish
thing
like
because
we're
having
a
bunch
of
people
use
one
account
they
don't
like
that
because
they
want
more
money.
I
don't
know,
but
that's
that's
kind
of
the
downside
of
of
this
new
mechanism.
B
Yes,
hi
everyone
so
well
looking
into
the
way
how
we
can
speed
up
stability
of
the
open,
telemetry
collector,
and
there
are
a
couple
of
questions
we
need
to
just
discuss
and
decide
whether
we
want
to
hold
that
approach
or
not,
and
the
first
one
is
whether
we
would
like
to
use
multi-mode
tool
and
keep
splitting
existing
packages.
F
Yeah
no
go
ahead.
Sure
I
have
a
question
but
please
please
share
and
then
then
we
can
discuss.
B
Yeah,
I
am
working
on
the
doc
right,
as
I
mentioned,
to
reorganize
the
module
packages
to
reduce
the
dependence,
but
it's
still
in
progress,
and
I
would
like
to
share
just
the
part
that
covers
whether,
like
pros
and
cons
of
the
have
in
different
modules,
so
it's
like
with
the
more
modules
we
can
solve.
They
will
deliver
stability,
guarantees
top
inflammatory
collectors
users
sooner.
Some
of
them
will
be
j
already.
B
B
As
a
downside,
we
would
need
to
have
to
maintain
two
sets
of
modules
that
require
that
release
it
under
different
versions,
and
we
can
re
use
multimod
tools
multi-mode
for
that
that
make
it
easier
and
it's
already
utilized
by
open
telemetry
go
seek.
So
I'd
like
to
seek
some
thoughts
around
that.
What
do
people
think.
B
Yeah
I
it's
like
it's
just
work
in
progress,
so
for
now
we
just
want
to
remove
the
blocker
on
whether
we
want
to
go
with
that
approach
or
not,
and
then,
when
I
propose
plan
how
to
split
existing
packages
into
modules
in
a
cleaner
way,
I
will
share
it
because,
right
now
it
doesn't
have
it
yet.
F
F
Because
kubernetes
has
this
that
they
have
features
in
each
individual
feature
can
have
its
state
like
it
can
be
alpha
beta
or
stable.
The
individual
features,
yes,.
B
F
B
Yeah,
as
far
as
I
remember,
I
didn't
look
closer
but
remember
they
mark
every
package,
as
it
is
a
different
version.
So
there
are
based
on
the
api
that
kubernetes,
provides
and
and
also
in
in
every
every
other
package.
They
have
some
experimental
parts
that
can
be
changed,
that
our
market
has
experimental
explicitly
so.
E
Can
I
can
I
chime
in
here
yeah
sure
I
can
probably
just
answer
the
question
so
kubernetes
client
go
is
actually
quite
a
small
package
and
it
does
have
features,
but
those
are
feature
gated,
so
they
don't
provide.
H
E
So
the
way
that
kubernetes
versions,
most
of
its
features,
is
through
api
objects
and
versioning.
Those
api
objects.
So
you
know
pod
is
part
of
a
v1
version
of
the
core
api
group
right
and
there
are
plenty
of
other
objects,
and
so
you
version
per
object
generally
for
features,
and
then
you
use
feature
gates
to
turn
on
or
off
code
paths
that
you're
worried
about
yeah
kubernetes
doesn't
really
do
code.
Stability
they're,
mostly
focused
on
object
stability
as
the
api
that
they
present
to
users.
F
What
about
the
internal
apis
like
kubernetes,
that
the
source
code
of
the
kubernetes
itself
is
there?
There
are
I'm
guessing
some
internal
apis
right
as
well.
Modules
depend
on
one.
Another
packages
depend
on
one
another.
Similarly,
to
how
we
have
this,
and
I'm
saying
they
have,
they
should
have
the
same
problem
right.
How
did
they
solve
this?
They
must
have
sold
it
somehow.
H
Us
I
think
it
is
as
bogdan
points
out
it's
a
monorepo,
so
within
the
repo
they
change,
whatever
they
want,
whenever
they
want
and
as
david
points
out,
their
compatibility
guarantees
are
via
the
apis,
the
the
http
restful
apis
that
they
expose
where
they
expect
interaction
from
programmatic
consumers
to
happen.
E
E
I
was
going
to
say
they
have
a
what
they
call
a
staging
directory
and
within
each
staging
directory,
subdirectories
become
their
own
repository.
So
if
you
look,
for
example,
for
client,
go
there's
a
repo
for
client
go,
but
if
you
look
at
the
readme
it
just
says
this
was
copied
from
kubernetes
kubernetes
from
this
directory
over
here.
So
they
have
a
mono
repo
that
ends
up
having
changes
to
individual
folders
that
they
want
to
expose
published
as
separate
repositories
for
people
who
want
to
take
dependencies
on
them.
F
F
F
Yes,
and
if
not,
the
alternate
is
to
have
one-
I
guess
maybe
more
than
one
but
a
single
module
marked
as
one
point
x
version
may
contain
some
apis,
which
are
somehow
explicitly
labeled
as
unstable
and
are
exempt
from
the
stability
guarantees
that
are
normally
normally
part
of
what
cool
believes
should
be
when
you
declare
them
only
one
point
x.
That
is
the
question
right
and
this
is.
B
This
is
another
question
because
we
do
have
logs
and
we
possibly
can
add
another
experimental
data
type.
So
here
we
need
to
decide
whether
we
so
it's
a
separate
question
as
well.
We
can
we
can.
We
can
reduce
number
of.
We
can
split
the
current
big
module
into
more
to
accelerate
stability
of
the
collector,
but
also
we
need
to
decide
what
we,
what
we
are
doing
with
experimental
experimental
data
data
types
and
that's
what
I
added
to
the
agenda
as
a
second
question.
B
B
Split
every
every
package
by
telemetry
data
type
into
different
modules,
so
this
is
going
to
be
pretty
hard
and
what
I'm
thinking
we
can
do
if
we,
if
we
can
still
accept,
allow
having
experimental
data
types
in
different
models,
for
example,
in
p
data
and
the
data
or
model
module
can
be
released
first
and
then
we
skip
gradually
splitting
them.
F
I
never
work
on
a
cod
base
with
with
a
large
number
of
modules
in
our
repository
there
is.
There
is
this
tool
right
that
that
mentioned
there.
H
F
J
I
Go
ahead,
I
I
was
going
to
say:
if
you
think
that,
could
I
think
that
it
is,
it
is
more
complicated
in
core
than
in
contrib.
I
So
if
you
start
with
contrib-
and
you
say,
okay,
you
know,
contrib
has
x
number
of
modules
and
I
will
try
to
generalize
from
that
experience
to
that
number
of
modules
and
core.
I
think
code
will
be
harder
because
the
module
versions
may
move
in
at
a
different
pace
and
they
will
be
interrelated
rather
than
just
being
kind
of
us
a
hub
and
spoke.
H
World
right
currently
in
contrib,
all
of
the
modules
are
at
a
single
version,
so
we're
using
multi-mod,
but
we're
largely
using
it
to
ensure
that
we
have
appropriate
references
between
the
modules
and
we
haven't
used
much
of
the
independent
module
versioning
capabilities
of
it.
We
have
used
that
in
go
and
go
contrib.
H
We
haven't
run
into
any
significant
issues
there.
The
only
issue
we've
run
into
recently
is
that
we've
been
unable
to
advance
some
of
the
contrib
metrics
modules,
because
doing
so
would
basically
make
some
of
them
worthless.
But
that's
that's
because
of
the
metrics
api
changing
and
not
because
of
the
modules
split.
I
think
we
need
to
take
a
decision
there
about
whether
we
even
want
to
keep
some
of
those
exporters
around
that
are
going
to
have
very
little
real
functionality
with
the
current
sdk.
H
H
H
I
think
that
may
provide
us
a
way
forward
for
some
of
the
experimental
data
types.
As
I
mentioned
on
dimitri's
issue,
the
interface
for
a
logs
consumer
is
going
to
be
a
method
called
consume
logs
that
takes
into
context
and
p
data
logs.
I
think
we
can
all
say
with
high
confidence
that
that's
not
going
to
change
what
p
data
logs
looks
like
might
change,
and
that
will
be
in
an
experimental
package.
H
J
It's
not
gonna
work
that
way,
because
if
people
start
using
logs,
you
hit
the
same
problem
as
having
experimental
apis
in
your
stable
things.
You
cannot
upgrade
because
of
the
dependencies
transitive
dependencies
on
that
unstable.
So
if
you
broke
the
unstable
thing,
you'll
be
stuck
with
that
version
and
so
on.
So
I'm
not
sure
if
this
solves
the
problem,
once
you
start
exposing
unstable
apis
indirectly
by
consume
logs,
I
think
you
hit
the
same
problem
as
just
having
unstable
and
experimental.
I
I
think
we
are
just
by
doing
that.
J
H
J
J
Back,
I
mean
that
means
the
third
option,
which
is
to
split
everything,
but
everything
by
signal
which
is
probably
unnecessary,
amount
of
work
and
too
much.
I
would
rather
go
with
the
experimental
api
in
stable
than
doing
that.
Work.
I
Can
I
ask
a
question
that
may
have
already
been
answered,
which
is
who
are
going
to
be?
Who
are
the
people
who
will
adopt
this?
Only
conditional
on
us
conforming
to
go
versioning
or
are
we
doing
it
because
we
think
it
is
good
engineering
discipline
to.
I
Yeah,
if
we
by
some
means
get
to
a
point
where
our
stable
modules
are
stable
according
to
the
go
way
of
marking
modules
to
models
modules
table,
who
will
that
like
who
will
be
helped
by
that
like
we
are
weighing
costs
here?
Right
and
I
want
to
just
articulate-
is
the
benefit
that
we
will
will
be
good,
go
citizens
or
is
the
benefit
that,
like
key
customers
abc,
will
use
it,
who
would
not
otherwise
have
used
it.
So
so.
J
J
Google
has
the
same
problem
with
a
bunch
of
enterprise
customers
that
they
really
want
to
see
one
zero,
not
zero
in
front,
because
for
them
zero
means
unstable.
Now
what
it
means
one
zero
for
us.
We
can
define
it
to
mean
something
different,
but
it's
it's
clearly
that
we
have
a
lot
of
ask
for
one
zero.
That's
one
thing.
The
second
part
is
at
least
in
terms
of
p
data.
We
do
have
the
example
of
google,
which
we
discussed
last
week,
david.
I
I
don't
know
if
you're
here
punya
but
david.
J
Sorry,
david
told
us
about
the
the
the
fact
that
you
start
depending
on
that.
So
it's
clearly,
at
least
at
the
p
data
level
that
we
do
want
to
have
api
stability,
because
it
will
be
extremely
or
almost
impossible
for
us
to
to
manage
the
transitive
dependencies
and
dependencies
in
contribute
unless
we
we
get
there.
So
so
there
is
a
clear
need
for
at
least
the
p
data
to
be
stable.
J
There
are
other
packages
that,
for
example,
component
probably
and
consumer
and
couple
of
them
that
also
needs
to
be
pretty
stable
in
order
for
us
to
be
able
to
allow
you
to
to
have
things
like
your
own
exporter
in
your
own
repo.
J
So
there
are
other
things
that
are
are
pushing
us
towards
this
direction.
So
now
now
depends
on
what
we
are
prioritize.
We
can
do
different
things
but
yeah.
I
think
these
are
the
the
the
problems
that
we
are
trying
to
solve
and
and
cases
where
we
saw
clearly
that
we
have
a
problem.
H
So
my
concern
and
the
reason
that
I'm
so
strongly
advocating
that
we
adhere
to
zimvir
and
the
go
module,
versioning
policies
and
also
the
the
hotel
general
module
versioning
policies
for
client
libraries.
I
know
it
doesn't
apply
to
sdks,
but
the
project
as
a
whole
has
made
this
version
of
guidance
as
well.
H
The
reason
I
think
that's
so
important
is
that
it
may
not
necessarily
get
us
people
who
will
only
come
over
and
start
using
us
if
we
do
that,
but
it
certainly
has
the
possibility
to
lose
us
customers
and
faith.
If
we
do
not
do
that
and
if
we
say
we're
stable
by
by
putting
a
1.0
label
on
it,
but
act
as
if
we're
not
that
has
significant
downside
risk.
I
think
to
our
our
trust
with
the
community.
I
Yeah,
just
just
to
be
clear
about
how
I
was
understanding
it.
I
would
have
looked
at
the
kubernetes
example
and
said:
let's,
let's
make
it,
let's
keep
it
at
0.x
and
tell
people
that
stability
is
nuanced
rather
than
calling
it
one.x
claiming
blanket
stability
and
then
failing
to
deliver
on
that.
So
I
I
would
certainly
not
advocate
for
like
adopting
1.0
and
then
yeah
cool.
C
Yeah
completely
agree
with
when
you're
here
so
first,
we
should
aim
to
have
a
stability
without
1.0,
so
try
to
be
what
we
need
to
be
tomorrow.
So
try
to
be
today
what
we
need
to
be
tomorrow,
but
I
think
it's
clear
that
we
have
two
versions
here
right.
So
one
is
for
the
apis
that
we
want
to
provide
to
downstream
distributions
and
then
the
versions
of
the
distributions
themselves.
C
So
people
who
are
who
think
that
some
components
are
stable
already
and
you
can
release
if
you
want
of
their
distributions
and
and
provide
to
their
customers
for
things
that
are
not
the
one
or
for
for
our
official
distributions.
C
I
think
we
should
follow.
I
mean
we
can
release
a
tracing
collector
with
v1,
because
that's
what
we
have
right
now,
as
you
know,
stable
in
general,
open
telemetry,
and
then
I
view
1.x
with
metrics
in
the
future
whenever
we
feel
that
that
metrics
is
ready.
So
in
terms
of
the
end
users,
we
can
have
the
distribution
version
independent
from
the
collector
and
the
control
components.
C
Have
we
considered
doing
something
like
this?
What
is
common
for
kubernetes
in
terms
of
crgs
like
having
a
different
namespace
like
a
beta
namespace
or
for
like
matrix
packages,
and
then,
whenever
we
deem
them
stable,
we
just
move
them
or
just
rename
or
copy
the
package
to
remove
the
beta
label
from
the
package.
H
That
was
something
that
we
discussed
in
the
go
sig
as
we
were
trying
to
figure
out
how
to
structure
our
modules
to
enable
us
to
have
experimental
and
stable
modules.
We
really
wanted
to
avoid
that,
because
that
would
require,
as
bogdan
to
point
out
users
to
to
break
or
to
have
to
make
a
change
in
order
to
get
to
the
current
stable
version
like
they
would.
They
would
have
to
go
through
and
find
all
of
the
references
to
the
beta
module
name
and
change
that
to
the
stable
module
name.
H
And
so
we
we
settled
on
using
the
module
names
that
would
be
used
in
practice,
ultimately,
but
giving
them
unstable
indicators
to
version
and
then
for
any
global
modules
that
were
intended
to
aggregate
things
like
the
the
hotel
module
that
that
aggregates
access
to
the
global
tracer
provider
and
will
eventually
have
access
to
the
global
meter
provider.
H
We
simply
have
a
metrics
global
that
duplicates
that
functionality,
while
it's
unstable
and
when
it
becomes
stable.
We
add
that
to
the
hotel
package
as
forwarding
to
the
to
the
metric
global
implementation,
or
vice
versa,
one
or
the
other.
But
that
way
we're
always
adding
and
never
requiring
users
to
move
around
where
they
get
the
code.
C
C
H
It
might
be
a
different
situation
and
it
might
be
that
the
the
collector
builder
makes
that
different
as
well
right,
because
that
aggregates
into
a
manifest
all
of
the
references
that
hopefully
will
make
it
easier
to
update.
I
think
for,
like
I
said
at
aws
with
our
ada
distribution-
we're
not
using
that
currently,
and
I
don't
know
if
we'll
be
able
to
use
it
going
forward.
H
C
I
think
it
because
we
don't
have
that
that
difference
right.
We
did
have
that
that
decision
on
whether
or
not
it
is
stable
or
not
stable,
and
I
guess
the
difference
is
only
whether
it's
marked
as
part
of
the
package
name
or
if
it's
marked
as
a
version
number
and
at
least
when
I'm
developing
I'm
I'm
really
not
always
looking
at
the
version
number
or
I
don't
have
the
version
number
of
all,
my
all
of
my
dependencies.
C
C
So,
with
what
I
had
in
mind
is
the
collector
has
would
have
one
version
as
a
whole
like
it
is
today.
The
only
difference
would
be
that
unstable
packages
would
be
under
a
like
module,
but
not
the
gold
module.
H
The
future
name
so
so,
I
think
the
risk.
There,
though,
is
that
anybody
who
is
using
it
as
a
go
module
can
and
will
eventually
have
that
change
out
from
under
them
in
a
way
that
is
incompatible
to
them,
that
they
do
not
expect
because
go
will
see
that
as
a
1.0
module
expect
stability
and
choose
the
minimum
supported
version
to
get
all
of
the
transitive
dependencies
supported,
and
so,
if
something
that
they
depend
on,
has
a
higher
version
required
and
that
higher
version
has
a
break
in
the
experimental
portion
of
it.
C
C
I
guess
my
question
is
right:
now
it's
a
theoretical
problem:
would
it
be
worth
trying
a
single
module
or
the
way
that
we
have
today
and
stability
marketing
the
package
names
and
if
it
doesn't
work,
we
split
them
into
modules,
and
then
you
know
go
about
is
the
way
this
proposal
was
made.
H
B
Only
question
this
is
also
about
how
we're
going
to
treat
experimental
data
types
going
forward,
because
if
we
don't
allow
having
experimental
parts
in
stable
package,
we
have
to
split
everything
right
now,
because
consumer
component,
even
even
can
trip
even
configure,
has
some
public
api
parts
that
are
specific
for
your
particular
data
type.
And
if
we
are
going
to
add
in
future,
for
example,
let's
imagine
we
add
some
additional
experimental
type.
B
B
J
The
most
worried
for
me
is,
if
we
decide
to
add
profiling,
for
example,
it's
going
to
be
impossible
for
because,
let's,
let's
put
this
way,
everything
unifies
at
the
service
level,
so
service,
the
last
one
that
that
builds
the
pipelines
and
everything
has
to
know
about
the
experimental
thing
correct
and
that
will
depend
on
an
experimental
part
and
that
will
depend
on
the
public
kpi
on
an
experimental
part.
So
we
are
going
to
expose
that
experimental
api
transitively,
but
it's
going
to
be
in
the
go.
J
Doc
is
going
to
be
in
the
public
things,
the
the
experimental
part,
and
now
you
know
I
don't
know
how
to
solve
that.
So
so
we
we
we're.
Gonna,
have
everything
split,
a
lot
of
work
to
do,
and
hence
even
with
that
at
the
last
moment
we
have
to
unify
and
we
have
to
to
bring
that
unstable
part
in
a
stable
in
a
stable
module
and
then
then,
because
of
this,
for
for
me
my
mind,
it's
just
going
everywhere.
I
think
I
think
the
only
reasonable
thing
is.
I
So
hearing
that-
and
I
know
dmitry
you
said
that
it's
not
about
1.0,
but
maybe
we
can
scope
it
down
to
make
it
about
1.0.
One
version
of
this
is
to
say,
create
a
1.0
package
that
only
that
cannot
be
depended
upon.
So
if
you
create
a
module
that
whose
only
package
has
a
main
method
right,
this
can
be
the
service
like
the
service
package
can
be
declared
1.0
with
no
harm
to
anybody,
because
if
it
only
has,
if
it's
only
a
a
binary,
it's
not
a
library.
I
And
we
can-
and
we
can
do
that
with
whatever
semantics
we
want.
We
don't
really
have
binaries
in
the
collector
anymore,
though
they're
all
built
by
the
collector
builder,
then
the
collector,
then
the
thing
that
the
the
I
guess
I'm
trying
to
understand
what
is
the
artifact,
whose
version
our
like
these
countries,
these
potential
contributors
or
potential
users
care
about,
and
I'm
I'm
guessing.
I
I
don't
have
evidence,
but
I'm
guessing
that
a
substantial
fraction
of
them
care
about
the
binary
now,
even
if
it's
not
in
our
repo
right.
Even
if
what
we're
saying
is
the
collector
builder
generates
this
binary
and
the
one
dot
number
is.
It
is
attached
to
something
that
gets
checked
in
or
something
that's
attached
to
a
docker
image
right.
It's
attached
to
the
rpm
and
dev,
but
maybe
that
1.0
is
the
one
that
matters
not
the
1.0
attack
potential
1.0
attached
to
our
our
libraries
and
again
I'm
looking
at
the
kubernetes
example
right.
F
F
Configuration
file,
format,
immediate
telemetry,
stuff,
like
that
and
the
second
class,
the
other
class
of
the
users,
is
developers
who
create
components
using
the
apis
that
we
publish,
I
think
both
are
important
here.
The
the
the
discussion
about
the
go
modules
is
for
for
this,
the
other
class
of
the
user,
the
developers,
the
the
the
first
one
is
also
important,
but
I
think
it's
more
or
less
independent
you're
right.
F
We
technically
do
not
necessarily
need
the
go
modules
and
the
internal
apis
to
be
stable,
to
be
able
to
release
something
that
we
call
a
stable
collector.
From
the
perspective
of
end
users,
you
can
build
stable
stuff
from
unstable
components.
That's
that's
fine.
As
long
as
you
don't
lick
the
api
and
don't
don't
click
the
unstable
behavior
in
any
way,.
I
Because
I,
so
I
think
that
the
reason
it
is
important
to
make
that
distinction
is
that,
then
we
can
work
incrementally
to
help
developers.
We
can
say:
okay
developers
really
care
about
the
stability
of
this
interface,
and
that
kind
of,
I
think
the
example
given
was
really
good,
where
there's
always
going
to
be
a
function
called
foo,
but
its
argument
type
will
evolve
over
time.
Go
does
not
know
how
to
capture
that
notion
of
stability
right,
and
so
some
of
these
things
might
be
cases
where
we
have
to
sorry.
I
E
I
do
think
that
so
the
discussion
last
time
that
stemmed
from
our
exporter
is
a
good
example
of
potentially
where
a
stable
module
would
be
useful
only
because
we
know
that
if
there
are
external
dependencies
that
collect
or
contrib
depends
on
that
have
dependencies
on
core
that
that
becomes
enormous
headache
if
one
of
those
dependencies
has
changed
so
and
actually,
I
think
one
useful
thing
about
the
exercise.
The
google
cloud
exporters
gone
through
is
to
demonstrate
that
you
can
have
that.
E
L
J
It's
only
p
data
if
it's
only
p
data,
as
david
pointed
the
problem,
is
very
simple.
We
can
definitely
split
that
because
it's
not
a
huge
amount
of.
I
mean
it's
a
lot
of
work,
but
not
as
much
as
splitting
everything
like
like
I'm
trying
to
to
to
find
balance.
If,
if
we
only
care
about
the
data,
that's
fine,
that's
that's
it's
something
that
we
know
and
we
can
do,
and
we
can
maintain
this
way
and
it's
fine,
but
I
think
I
think
the
problem
is
larger
than
that.
To
be
honest,
like
I.
F
F
Data
we
leak
p
data
in
component
interfaces.
If
p
data
is
part
of
your
component
interface,
then
it
makes
your
component
interface
unstable,
correct.
Formally,
it's
unstable.
You
leak
it
so
yeah.
If
it's
in
your
implementation,
if
it's
encapsulated,
if
it's
hidden
invisible,
then
yes,
but
it's
not
the
case
and
cannot
be
the
case.
It
needs
to
be
part
of
the
component
interfaces.
E
I
agree
I'm
sort
of
saying
I
don't
think
the
component
interfaces
need
to
be
stable,
because
if
there
is
a
component
developed
somewhere
else
and
there's
a
small
change
to
the
function,
signature,
maybe
that's
acceptable.
The
issue
that
we
came
across
was
the
cyclic
dependency
between
collector
core,
an
external,
the
written
thing
and
collector
contrib.
J
The
the
only
problem
is,
if
we
adopt
splitting
p
data,
we
need
to
understand
that
that's
not
scalable
for
the
entire
chord
and
to
split
the
entire
thing,
and
for
good
or
bad
reasons.
We
have
lots
of
interfaces
that
are
common
between
signals
and
splitting.
All
of
them
will
cause
chaos
in
our
environment,
but
we
have
the
service
that
needs
to
build
these
interfaces
at
the
end.
That
has
to
depend
on
these
things.
J
So
so
it's
it's
not
gonna
work
and-
and
I
don't
want
to
do
this
work
unless
we
agree
that
this
is
the
only
place
where
we
need
it,
because
otherwise,
by
president
case,
we
we
can
say
that
hey.
This
is
what
we're
gonna
do
in
core
and
it's
not
something
that
we
should
do.
I.
H
I
disagree
with
that
observation
and
opinion,
and
I
I
think
it's
it's
assuming
that
we
can't
do
things
before
we've
tried,
so
I
I
know
it
will
be
effort.
H
It
will
be
significant
effort,
yes,
but
I
think
it
can
be
done
in
the
same
way
that
we
would,
by
starting
with
p
data
and
working
up
the
dependency
chain,
start
introducing
stability
and
start
separating
off
the
things
that
cannot
be
stable
and
ultimately
will
probably
end
at
one
point
where
either
it
is
impossible
or
very
difficult
to
continue
any
further,
but
to
say
that
we
won't
even
try.
I
don't
think
it's
appropriate.
F
So
anthony
are
you:
are
you
envisioning
a
situation
when
all
of
the
code
that
deals
with
signals
is
split
into
separate
modules?
Is
that
we
will
end
up
with
that
right?
Because
otherwise,
because
you
have
experimental
signals,
the
code
that
we
will
need
to
work
with
the
signals
can
never
be
stable.
It
will
forever
stay
unstable
right.
H
J
It's
not
gonna
work
because,
because
then
components
build
with
v1
will
not
work
with
v2,
so
so
cheap.
So
so
we
have
a
problem
here,
because
it's
it's
not
as
easy
as
just
bumping
the
version.
Then
then
user
would
be
impossible
to
build
a
thing
when
you
need
to
build
bridges.
For
for
that,
you
need
to
because
how?
J
How
how
are
we
gonna
have
if,
if
stackdriver
exporter
stays
with
v1
and
we
switch
to
v2
sorry
david
using
you
as
an
example
and
not
saying
that
you
are
lazy
for
not
changing
to
v2,
but
but
we
if
we
are
bumping
to
v2
and
you
are
implementing
the
v1
interface
or
whatever.
So
we
have
a
big
problem
now,
because
we
don't
know
how
to
still
start
v1
components.
J
So
we
need
to
build
bridges
for
for
these
versions
and
it's
going
to
get
super
complicated
in
our
opinion
to
to
to
to
bump
a
version,
because
we
have
the
problem.
Is
we
have
the
last
one,
the
the
service?
That
knows
how
to
coordinate
all
these
components?
So
it
has
to
know
how
to
coordinate
with
with
v1s,
v2s
and
stuff,
like
that.
H
E
H
H
Sure
yeah,
so
this
is
a
pr
that
was
created
to
restore
a
package
to
external
usability
that
was
moved
to
an
internal
location
as
part
of
a
series
of
changes
to
the
configuration
api.
H
Here,
we've
got
some
breakage
to
the
the
behavior
and
the
the
packages
that
were
available
to
the
developer
user
class,
those
who
are
building
collector
and
collector-like
systems
using
the
collector
core
as
a
library
or
framework,
and
here
now
we
are
in
a
position
where
what
was
possible
before
is
no
longer
possible,
because
this
package
has
been
moved
internally.
H
We
can
work
through
some
of
the
structural
changes,
the
the
the
code.
You
know
that
the
the
patterns
of
usage
that
have
changed
in
configuration,
but
we
are
now
at
a
point
where
there
is
a
default
config
provider
that
cannot
be
reconstructed
through
the
means
that
are
provided
to
developers
to
construct
their
own
config
providers,
and
I
think
that
we
need
to
be
able
to
restore
that
capability.
F
Since
you
you're
working
on
this
line
of
changes,
do
you
plan
that
it
will
be?
It
will
live
in
some
other
form,
or
you
are
thinking
that
it
shouldn't
exist
will
be
replaced
by
something
else.
F
I
guess
the
question
is:
if
we're
reverting
with
a
pointless
reversion,
because
it
has
to
change
one
more
time
and
it
has
to
be
broken
again
in
that
case,
why?
Why
reverse
right.
J
So
it
will
break
again
if
we
want
to
implement
the
the
config
source
idea
that
has
to
be
rewritten
and
re-implemented
in
a
different
way
and
embedded
into
the
default
provider
that
we
do
also
fyi
anthony.
You
can
always
copy-paste
that
code,
if
you,
if
you
really
believe
that
so
so
you
still
have
the
ability,
because
the
interfaces
are
there.
It's
just
not
that
particular
code
written
by
us
that
is
not
available
just
to
clarify,
so
everyone
can
still
do
that.
But
telling
users
to
copy
and
paste
code
is
not
a
good
answer.
J
You
know,
can
you
let
me
finish?
Please,
okay,
so,
but
to
answer
this
one
thing:
tigran
we
haven't
decided
yet
if,
if
we
are
going
to
do
the
expand
functionality
that
that
splunk
proposed
and
with
with
embedding
into
the
config
things
remember
so
if
we
do
that
this
has
to
change,
and
this
has
to
to
know
about
the
sources
the
providers
and
stuff
like
that,
so
it
will
not
be
as
as
it
is
right
now
so
we'll
break
again.
J
That's
why
it
was
the
reason
why
I
hide
it,
because
I
didn't
want
to
break
continuously
break
that
and
better
to
to
hide
and
until
he's
stable.
Now,
arguably
may
not
be
the
right
decision,
but
that
was
my
mind
in
in
this
in
this
process.
So
not
saying
that
is
necessarily
the
best,
but
this
is
the
the
thought
on
that.
H
H
F
So
if,
if
we
decide
to
restore
this,
I
think
it
we
should
still
make
it
clear
that
there
should
not
be
an
expectation
that
a
functionality
cannot
be
removed
at
this
stage.
I
think
that's
that's.
We
shouldn't
be
expecting
that
we
should
shouldn't
the
users,
should
should
be
very
clear
that
stuff
may
be
removed,
because
maybe
it
doesn't
make
sense
to
keep
in
the
core
right
in
this
particular
case.
F
H
Think
there's
a
difference
between
removing
functionality
and
moving
it
to
make
it
inaccessible.
This
functionality
is
still
here
and
still
works
in
the
default
config
provider,
but
the
default
config
provider
can't
be
replicated
by
the
other
means
that
are
provided
to
create
a
config
provider.
That's
one
of
my
concerns
here:
it's
not
that
we
removed
it.
We
said
we
can
use
it,
but
you
can't.
J
J
H
F
Yeah,
that's
true
anthony.
All
I'm
saying
is
that
let's
not
set
the
expectation
that
things
cannot
be
removed
hidden,
I
guess
yeah,
maybe
you're
right,
maybe
I
mean
there's
no
desire
to
make
things
hidden
but
keep
them.
This
was
he
done
because
we
thought
that
it
may
need
to
be
removed
right
so
yeah
breaking
changes.
B
C
Yeah,
but
perhaps
this
is
a
a
signal
taken,
that
we
do
need
to
better
communicate
the
breaking
chains
from
now
on,
because
you
know
we
do
have
a
lot
of
people
using
that
already,
especially
because
we've
been
delaying
one,
that's
here
for
so
long,
so.
C
Yeah,
I
agree,
so
I
guess
it
still
goes
back
to
the
idea
that
putin
had
a
few
moments
ago
in
that
we
should
strive
for
stability
now,
even
even
though
we
still
have
the
capability
or
the
capacity
of
not
being
stable,
but
let's
strive
for
that
and
to
change
breaking
chains
in
in
two
stages.
So
in
one
stage
we
deprecate
in
the
second
stage
we
remove.
C
Well
or
that
I
mean
yeah
I
mean
I
think
we
don't
have
future
gates,
yet
I
think
but
yeah
I
mean
okay,
good,
that's
great!
C
So
either
that
and
but
the
point
is
you
know,
we
should
give
users
whether
they're
end
users
or
api
users,
the
capacity
or
the
capability
of
coming
to
us
and
expressing
their
concerns
once
they
see
a
deprecated
warning
in
their
blogs
or
on
their.
F
J
I
think
keeping
back
or
keeping
deprecated
things
for
one
release
is
the
reasonable
thing
to
do,
and,
and
probably
it's
enough
to
signal
people
I
mean
I
hope
they
enable
linters
and
stuff
that
tell
them
that
you
are
using
deprecated
things.
Otherwise
I
don't
know
how
to
more
than
just
maybe
change
log
another
option.
J
As
a
rule,
let's
say
that
we
we
just
deprecate
things
before
removing
if,
unless,
unless
it's
a
simple
ringing
or
something
like
that,
that
maybe
we
just
are
okay
with
that,
I
don't
know
some
probably
we
should
write
a
2-3
sentence
of
what
is
allowed,
what
is
not
allowed
or
if
anything
is
allowed.
C
H
H
J
J
J
I
don't
think
people
are
supposed
to
depend
on
country
more
than
I
mean
country
should
not
have
public
apis
except
the
components
like
new
factories,
and
but
there
are
some
packages
in
country.
To
be
honest,
I
think,
but
for
those
I
for
the
moment,
I
think
we
should
not.
We
should
not
apply
this
rule
yet
until
we
we
have
more
users
or
so
that's
my
thought.
Jurassic.
J
No,
we
didn't,
but
we
can
add
it
back.
We
deprecated,
since
we
know
that
it's
it's
going
to
be
changed
very
soon.
J
It
changes
more
than
that
david.
So
so
the
problem
is
right:
now
it's
not
only
signature
is
it
has
to
be
embedded
into
another
class,
and
so
it's
gonna
disappear
and
be
embedded
into
another.
Another
high-level
struct.