►
From YouTube: 2022-01-05 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
A
A
A
A
B
Why
not
you
mentioned
you
wouldn't
join
today.
C
A
Okay,
so
let's,
let's
start,
I
think
curiosity,
your
pr
is
for
your
comment
is
first.
B
Yeah,
so
we
have
a
couple
of
issues
related
to
tail-based
sampling
and
there
is
a
policy
here
and
an
end
policy,
and
I
think
primack
here
is
also
interested
in
that
one
on
that
one,
and
so
I
I
wanted
to
get
like
five
or
at
most
ten
minutes
to
to
synchronize
on
what
all
the
things
that
we
have
around
tail-based
sampling,
or
especially
around
the
policies
for
tail-basing,
because
some
of
those
features
or
some
of
those
work
streams
they
they
compete
with
each
other
right
so
yeah.
B
C
Yeah
and
actually
maybe
I
will
share
my
screen
and
talk
about
the
differences,
but
maybe
I'm
not
sure
if
now
or
maybe
a
bit
later,
but
just
to
give
a
recap:
we
have
taken
a
tail-based
sampling
processor
from
open,
telemetry,
collector,
contrib
and
built
something
own
based
on
that.
That
I
believe,
is
much
simpler
to
use
and
I
think
because
of
that,
it's
it's
interesting.
B
So
let's
have
your
demo
first
and
then
we
can
discuss.
I
see
that
mochi
is
also
here,
so
you
can.
You
can
start
with
your
demo
and
then
we
can
discuss
based
on
that.
C
Sure
so
I
haven't
prepared
like
a
real
demo,
but
wanted
to
just
quickly
show
the
major
differences.
C
So
the
first
one
is
that
the
intake
sampling
processor,
you
need
to
define
those
policies
and
there's
like
some
level
of
nesting
required
and
and
and
so
on,
and
also
I'm
not
I'm
not
sure
right
now,
but
there
are
some
complexities
with
limiting
the
number
of
traces
or
or
sponsor
per
second
for
each
policy.
C
Well,
maybe
I'm
wrong
here,
but
there's
like
yeah
there's
this
thing,
like
total
spans
per
second,
and
things
like
that
which
make
things
bit
bit
harder
and
what
we
found
is
that
typically,
users
have
two
use
cases
for
having
even
tape
based
sampling
processor,
the
first
one
is:
they
want
to
remove
traces
that
they
don't
want
to
be
have
included
at
all
like,
for
example,
health
checks
are
commonly
falling
in
this
category.
C
C
You
can
specify
what
you
want
to
remove
always
and
don't
do
not
ever
include
that
and
for
that
purpose
you
can
use,
for
example,
name
pattern
which
identifies
traces
with
some
operation
name
in
one
of
the
spans
or
maybe
traces
with
some
attributes
that
have
certain
criteria
met
and
so
on
for
trace,
accept
filters.
It
works
similar
to
how
those
policies
work
right.
Now,
however,
it
simplifies
a
couple
of
things
and
also
all
of
those.
C
There
is
like
no
separate
type
of
policy
for
different
type
of
filter,
but
all
filters
are
always
available
and
you
can
use
a
number
of
them
which
essentially
makes
it
an
end
condition
at
a
given
filter
level,
and
if
you
want
to
have
several
ores,
you
can
just
stack
those
and
several
types
of
filters
together
so
very
quickly.
I'm
not
sure
if
maybe
that
was
too
quick,
but
a
recap
of
the
differences,
but
but
even
visually.
C
You
can
see
that
even
some
complex
cases
are
a
little
simpler
to
express
than
the
current
sampling
processor,
and
if
this
helps
we
will
be
more
than
happy
to
donate
it
to
open
telemetry.
If,
if
you
would
deem
this
helpful,
but
I
understand
that
there
are
like
different
concepts
between
between
taste,
sampling,
processor
and
cascading,
filter
processor,
with
a
group
by
trace,
processor,
etc
and
and
so
on,
being
used,
which
is
not
used
in
the
cascading
filter.
But.
B
So
can
you
go
back
again,
so
you
don't
use
the
group
by
trace
filter
the
group
by
trace
processor
for
the
cascading.
B
Do
you
get
the
view?
Oh,
you
don't
actually
need
the
view
of
the
whole
trace
right.
C
I
do
need
so
actually
this
code
was
based
on
the
code
used
for
taste
sampling
processor.
A
couple.
D
C
Ago-
and
this
was
before
the
split
to
group-
by
trace,
processor
and
and
and
a
sampling
processor,
okay,
would
you
mind
adding
sorry.
A
B
Yeah
so
another
one
that
is
happening
right
now,
so
there
is
apr.
I
also
oh,
that's.
Actually,
the
one
that
mod
opened,
which
is
you
know
the
combined
there's
apr
for
the
combined
policy.
B
I
think
it's
it's
nice,
it's
simple
it
does.
You
know
it
does
solve
the
problem.
I
I'm
just
not
sure
that.
B
You
know
the
naming
itself
is
very
close
to
the
composite
one
that
we
have
right
now
and
I
think
we
need
either
better
names
or
better
documentation
or
both
for
this
one
here
or
for
both
for
the
for
the
combined
and
for
the
composite.
B
But
you
know
there
is
a
conversation
we
had
a
few
months
ago.
I
think,
on
on
refactoring
the
whole
policy
part
into
its
own
processor,
mainly
because
it
could
then
be
used
in
different
scenarios,
and
if
we
end
up
doing
that,
then
we
might
do
different
architectural
choices
than
what
we
have
right
now
in
the
tao
sampling
processor.
A
Okay,
by
the
way
jurassic
have
you
ever
looked
at
the
the
transform
processor
that
we
are
working
on.
A
Transformation
or
something
like
that
and
the
query
language,
maybe
you
should
think
if,
if
we
can
reuse
so
the
query
language
that
anurag
is
proposing
is
based
on
sql
is
not
literally
sql,
but
it's
based
on
sql,
so
you
have
a
do
something
where
condition
and
that
condition
part
is
more
or
less
written
as
a
language
condition.
So
maybe
maybe
that's
something
that
you
can
reuse
and
we
should
reuse
across
across
this.
A
B
Right,
that
is,
for
individual
data
points
right,
so
that's
not
for
for
the
whole
trace.
So
are
you
able
to
combine
saying?
I
want
traces
with
error
conditions
for
the
end
point
x,
y
z
and
then
their
condition
can
be
in
any
span
in
that
trace,
and
so
not
specifically,
I
see
no
reason
to
not
extend
that
language
to
that.
B
Okay,
so
if
that
yeah,
so
I
guess,
is
anarch
here.
A
But
we
we
sometimes
meet
with
him
in
the
evening,
but
I
think
that
doesn't
make
sense
to
you.
Maybe
maybe
you
can
see
differently
on
a
different
european
primary
team.
B
Yeah
all
right,
so
so
how
about
we
proceed
with
the
end
policy,
especially
because
apr
is,
is
relatively
small
and
I
think
it's
straightforward.
We
might
just
need
better
documentation
on
that.
Pr,
perhaps
perhaps
even
consider
a
new
name
for
that
for
policy
instead
of
a
combined
policy,
a
and
policy-
perhaps
I
don't
know,
but
then
move
forward
with
that
one
and
then
for
the
future,
potentially
for
ga,
we
think
about
a
more
generalized
solution
involving
the
transform
processor
and.
B
I
think
so
I,
like
I
like
this
idea.
I,
like
the
cascading
future.
C
Yeah,
I
think
that
this
processor
could
could
work
as
well.
This
cascading
filter
also
does
few
more
things,
but
I
didn't
want
to
make
it
too
complex,
like,
for
example,
it
has
some
adaptive
sampling
capabilities,
so
you
can
say
that
you
can
have
some
express
some
more
complex
rules
using
that
approach,
but
yeah.
I
think
that
we
created
it
because
there
are
like
some
missing
capabilities
in
place:
sampling,
processor,
but
the
one
you're
describing
right
now.
I
think
that
eventually
we
could
migrate
towards
it.
A
It
will
be
hard
to
make
the
the
transform
one
that
anurag
is
proposing
right
now,
because
that
that
doesn't
know
anything
about
sampling.
So
that's
that's
a
blunt.
Like
I
see
a
span,
I
applying
the
rule
and
move
forward,
so
it
doesn't
have
a
state.
We
try
to
not
keep
a
state
in
that
and
and
whatever
we
see,
that's
that's
what
we
we
consume.
C
Yes,
but
you
can
still
compose
like
two
processors
together,
so
we
could
use
the
one
he's
working
for,
let's
say
filtering
data
and
then
have
another
one
for
making
some
sampling
related
operations.
A
Yes,
that's
that's
a
separate
thing.
You
can
still
do
that,
but
but
from
our
one
that
we
will
support
and
call
transform,
at
least
that
one
is
not
gonna.
Do
the
smartest
thing
that
you
want.
B
A
Transform
processor
does
more,
it
does
an
action
plus
a
condition
you.
You
need
just
the
condition
from
that,
because,
because
the
action
that
we
offer
are
like
change,
the
name
or
or
or
for
example,
drop
the
span
or
or
keep
our
attribute.
So
we
we
we
give
these
to
users
to
reshape
the
spans,
for
whatever
reasons,
for
example,
if
they
want
to
drop
some
attributes
because
of
pi
if
they
want
to
rename
a
span,
because
whatever
reasons
and
stuff
like
that,
so
that's
that's
what
we
give
them.
B
Right
and
you
think
that
it's
it's
reasonable
to
adapt
this
processor
to
have
a
notion
of
a
trace
instead
of
just
pens,
because
some
of
the
decisions
so
detail-based
sampling
is
about
making
decisions
on
a
trace,
not
on
expense
right.
So
I
may,
within
a
decision
I
may
take
information
from
two
different
spans
that
belong
to
the
same
trace.
B
So
that's
the
power
of
detail.
Basically,
I
know-
and
you
said,
that
the
transform
processor
doesn't
have
any
state
there
and
that
cannot.
You
know
correct
cause.
The
problem
here.
A
I
think
I
think
so
we
we,
we
decided
to
put
a
query
language
as
a
library,
so
I
think
you
can
use
the
library
that
library
and
do
one
that
works
on
tracy's,
but
I
don't
know
so
so
you
will
be
a
pkg
like
in
the
package.
You
will
have
extracted
the
library,
the
query
language
library
which,
which
can
be
reused,
the
condition
part
if
you
want
or
or
because
the
actions
are
less
likely
that
you
need.
You
need
just
drop
that
we
have.
Besides,
that,
I
don't
think
you
need
other
other
things.
A
B
Okay,
got
it
all
right,
so
let
let's
move
forward
with
the
end
policy
and
I
would
create
an
issue
to
track
the
progress
on
on
deprecating
once
again,
the
database
sampling
in
favor
of
a
new
processor
that
makes
use
of
this
query
language
yep
all
right,
so
multi,
I'm
sorry!
If
I'm
pronouncing
that
incorrectly.
E
He
actually
pronounced
it
well,
so
I
yeah
I
mean
that
pr
was
just
in
a
draft
state
because
we
already
had
the
code
written,
so
I
just
wanted
to
have
it
there.
B
E
Oh
yeah,
so
I
also
added
it
so
we
noticed
we
started
to
use
the
tail
based
sampling
recently
and
I
noticed
that
it
removes
the
instrumentation
library
from
the
traces.
E
I
looked
at
the
code
and
it
looked
like
it
was
done
on
purpose.
I
was
trying
to
understand
if
there
isn't
any
logic
behind
it.
I
couldn't
couldn't
think
of
a
reason,
and
now
I
changed
it
on
on
my
fork
and
I
deployed
it
onto
a
test
environment
and
it
looked
like
it
was
behaving
just
okay,
so
I
was
wondering
if
anyone
knows
anything
about
it
or
I
should
just
submit
the
pr
to
fix
it.
B
Yeah,
I
need
to
take
a
look
at
the
code
and
see
what
might
have
been
the
reason.
I
think
we
might
do
something
similar
on
the
group
by
trace,
but
now
I'm
not
sure
if
we
group
them
per
resource
or
per
ios
for
instrumentation
libraries
pens.
B
One
possible
reason
is
we
group
them,
because
we
want
all
these
pens
yeah.
I
don't
know
I
mean
we
may
group
them
because
they
come
from
different
sources
and
they
might
have
different
instrumentation
libraries
that
generate
them.
So
we
have
one
microservice
with
one
set
of
instrumentation
libraries
go
for
instance
another
one
for
java.
They
will
be
grouped
in
the
same
trace,
the
same
p
data
traces,
but.
A
A
three
form,
so
you
can
still
put
a
node
there,
like
the
the
instrumentation
library,
node.
B
B
Yeah
the
code
there
seems,
like
I
mean
I
think
he
mentioned
a
pen
empty
call,
yeah.
D
B
A
A
Why
that
code,
that
code
can
be
also
improved.
Just
because
I
looked
at
it
now.
One
thing
that
can
be
improved
is
instead
of
using
copy
to
you.
Probably
you
should
use
move
tool,
we
added
operation
to
move
a
span.
So
if
you
don't
need
to
retain
the
the
initial
kind,
I
think
you
don't.
You
can
just
move,
because
we
move
the
pointers
behind
the
memory
and
stuff.
A
So
I
know
we
build
the
p
data
a
bit
more,
like
c
plus
plus
with
moving
and
coping,
but
but
we
had
to
to
do
this
because,
because
there
is
memory
behind
and
if
you
copy
you
have
a
copy,
if
you
move
you,
you
have
just
in
there.
B
Yeah
yeah
I
mean
the
two
base
simply
does
need
some
love,
I
mean
it.
It
has
some
some
leaks
somewhere.
I've
I've
seen
some
some
leaks
during
performance
testing
that
I
still
need
to
find.
Where
exactly
is
happening
that
so
it
does
need
some.
Some
love.
B
Absolutely
yeah,
so
I
think
that
the
point
here
or
the
answer
to
emoji
is
that
I'm
I'm
taking
a
look
probably
next
week,
I'm
off
tomorrow
and
the
day
after,
but
I'll
take
a
look
next
week
and
if
I
don't,
if
I
forget,
feel
free
to
ping
me
why
slack
or
github
whatever.
B
B
So
the
next
one
status
of
dsl
mentioned
in
somebody.
A
A
Responded,
there
is
a
tracking
issue
and
there
is
not
only
a
tracking
issue,
but
there
is
that's
not
a
tracking
issue
that
the
that's
the
documentation
here.
The
design
proposal.
H
Fyi,
it's
design.
A
A
A
C
It's
patrick
but
he's
not
not
here,
but
I
think
that
should
be
a
good
good
response
to
him,
so
he
will
continue
from
there.
So
thank
you.
Okay,.
A
Okay,
okay,
so,
but
the
most
important
one
we
started
the
world,
so
we
have
initial
prs.
We
have
some
benchmarks.
We
are
happy
with
that.
We
we're
moving
forward
with
we
providing
things
good
and
also
if
this
is
not
enough,
bring
it
again.
Next
time.
A
F
A
F
Added
a
comment
like
five-
maybe
20
minutes
ago,
just
before
the
meeting,
but
I
did
think
that
maybe
we
should
talk
about
it
here
in
this
forum
to
get
more
feedback
from
everyone
yeah,
since
it
seems
that
this
is
a
case
of
everybody
has
a
preference
or
an
opinion,
and
we
we
just
need
to
figure
out
what
works
best
for
the
community
here.
So.
A
So
the
current
logic
says:
whenever
you
want
to
add
a
new
component
by
component,
meaning
probably
we
should
clarify
exporter,
receiver,
processor
and
stuff.
These
are
what
we
call
components
inside
the
collector,
but
the
current
proposed
the
current
proposals.
Another
proposed
the
current
rule
says
because
it's
documented
already,
it
says
you
should
have
first
initially
a
pr
with
the
readme
configuration
that
explains
what
you
are
trying
to
do
and
why
and
how
user
is
going
to
use
this.
A
Second
pr
or
second
pr
here
can
be
multiple
pr's,
but
let's
say
sega
pr
is
about
implementation,
and
last
year
is
about
linking
it
to
the
to
the
binary
to
to
be
built.
I
think
everyone
agreed
with
the
last
one,
because
the
last
one,
no
matter
what
you
we
drew,
the
last
one
sooner
than
later-
will
become
a
different
repo
because
we're
releasing
release.
So
there
is
no
way
you
can
do
it
in
a
similar
pr.
A
We
will
have
to
update
this
once
once
we
completely
switch
to
to
release,
but
there
are
a
bunch
of
discussions
about
the
first
and
second
pr
and
people
can
read
the
whole
thing.
I
I
give
my
thoughts
on.
Why
did
we
split
in
three
steps?
There
were
concerns
from
anurag.
Why
the
first
and
second
should
be
similar
alex
you.
A
You
talked
about
small
krs
in
general
in
large
prs,
but
you
had
some
comments
about
the
the
component
in
general,
which
is
the
fact
that
you
like
more
one
one
shot
because
you
and
we
want
to
hear
from
others
what
what
is
their
opinion.
I
can
tell
you
again
my
opinion.
My
opinion
is
very
simple.
I
think
when
I
see
a
when
I
see
somebody
wanting
to
propose
something
to
the
repo,
I
want
them
to
get
a
soon
feedback
that
hey
first
of
all,
do
we
want
this
component
or
not?
A
A
One
of
the
first
prs
here
I'm
seeing
like
couch
base,
like
I
don't
know,
do
I
want
to
have
this:
do
we
want
to
support
it
or
not,
but
this
this
is
like
2
000
lines,
pr
and
I
feel
bad
to
say
no,
sometimes,
and
that's
why
I
want
them
to
to
come
up
with
the
like
the
simplest
thing
that
takes
them.
20
minutes
30
minutes
to
do,
and
I
don't
feel
bad
if
I
say
no,
because
nobody
wants
to
to
support
this.
A
Also
also,
for
me,
is
the
motivation
is
that
I
care
a
lot
about
the
user
interface
and
the
user
interface
for
me
is
the
documentation
in
the
readme
and
the
the
configuration
other
than
that
implementation
can
always
be
improved.
Change
made
it
better.
So
it's
not
that
important.
For
the
I
mean
it
is
very
important
for
the
user,
but
not
as
impactful
for
the
user
as
it
is
the
the
the
first
part
anyway.
These
are
my
thoughts.
That's
why
we
came
up
with
this.
This
proposal.
B
So
one
thing
that
I
have
in
mind
is
we:
we
are
not
talking
about
first
and
second
pr's
we're
talking
about
first
and
plus
subsequent
prs
right,
so
the
second
pr
that
we
have
there
might
not
be
only
the
second
might
be
the
third,
the
fourth,
the
fifth.
So
you
might
be
talking
about.
You
know
I
I
myself
split
some
peers
of
mine
into
four
or
five
before,
so
it's
not
only
one
two
and
a
third
to
just
add
things
to
the
components.go,
it's
typically
four
or
five
prs.
B
Now,
having
done
that,
it
is
painful
for
people
writing
the
code
because
we
have
either
we
have
the
complete
solution
up
front
and
then
we
have
to
split
the
code
into
several
pr's
and
then
rebase,
based
on
on
the
review
comments
and
so
on,
and
and
that's
a
nightmare
right,
because
you
have
merge
conflicts
because
you
know
your
your
third
pr
is
based
on
a
second
which
in
the
meantime
has
changed,
or
I
just
do
the
second
and
then,
whenever
it's
merged,
I
start
with
the
third
and
then
it
might
change
considerably
what
I
thought
that
how
it
would
work
by
the
second
pr
so
that
that
that
involves
more
refactoring
to
get
to
the
final
stage
that
I
want
so
to,
and
but
I
see
your
point
I
see
you
know,
I
do
value
this
idea
of
validating
the
component
before
any
code
is
even
written,
and
for
that
to
solve
that
specific
problem,
I
think
what
we
can
do
is
we
can
require
a
an
issue
to
be
created
before
the
comp.
B
The
first
pr
is
even
created.
So
in
that
issue
we
can
ask
people
to
come
up
with
to
provide
what
is
the
the
configuration
that
they
envisioned,
and
you
know
the
description
that
will
end
up
being
part
of
the
readme
file,
so
not
the
complete
reading
file.
But
you
know
what
is
this
component
for
what
is
target
audience?
Is
it
like
a
vendor
specific
component,
or
is
it
not
a
vendor
specific?
Who
is
the
sponsor
for
that?
B
A
Okay,
besides
discussing
the
one
single
pr
or
not
we,
so
everyone
agrees
that
we
need
somehow
to
have
an
initial
feedback
from
the
from
the
community
and
from
the
author
that
we
we
agree
that
we
want
that
component
in
our
repo
and
that
component
is
not
a
duplicate
of
something
that
already
exists,
because
I
saw
a
couple
of
times.
That
is
not
a
duplicate
effort
with
with
whatever
the
the
author
does
not
know
about.
A
The
community
is
working
on,
like
example,
the
transform
processor,
which
we
all
know,
knew
that
anurag
is
working
on
something,
but
maybe
was
not
that
visible
and
there
were
a
couple
of
proposals
around
that
and-
and
I
want
people
to
not
waste
their
time
as
well
as
I
don't
want
my
time
to
be
wasted.
So
so
I
I
need.
A
A
That
was
all
if,
if
we
want
to
go
with
an
issue
for
this,
I'm
fine,
but
we
need
to
to
have
somewhere
this
initial
step
very
clearly
documented,
because
I
don't
want
to
see
a
3000
pr
and
go
and
say
no
to
the
user
to
to
the
author,
because
because
it
it
makes
me
feel
bad
that
you
are
wasting
probably
two
three
days
to
work
on
that
and
I'm
just
coming
and
say
no.
B
Yeah-
and
I
think
an
issue
works
better
in
that
case,
because
it's
even
more
informal
than
apr-
and
there
is
an
even
even
you
know,
lower
friction
or
for
us
to
say
you
know
what
we
are
not
going
to
accept
this
component
here,
whereas
apr
it
does
imply
that
people
have
worked
on
on
on
the
code.
For
that
already
so
there's
a
bigger
investment
made
already.
A
So
you
know
what
I
saw
with
initial
issues:
they
throw
one
sentence
and
they
think
it's
enough.
So
so,
with
these
at
least
we
force
them
to
think
about
at
least
the
configuration
and
the
the
the
readme
like
the
way
how
you
would
merge
it
because
lots
of
times
I
saw
people.
I
want
a
scraper
for
college
db
without
telling
me
what
that's
easily
solved,
though.
I
I
A
A
I
think
we
will
be
able
to
to
get
that
implementation,
I'm
not
that
worried
that
will
not
be
able
to
get
an
implementation
as
long
as
we
get
the
initial
requirements
of
that
component
like
if
somebody
will
tell
me
that
they
want
to
go
to
the
moon
in
that
component,
probably
I'll
say
no,
because
I
I
know
I
cannot
write
that
code,
but
the
things
that
we
believe
are
possible.
I
think
I
think
it's
rare
the
case.
To
be
honest,
in
my
opinion,
I
think,
is
a
rare
case
where,
where
the
implementation
cannot
be
done,.
I
A
A
B
Yeah
so
going
back
to
the
previous
point,
perhaps
not
as
dramatic
as
not
completing
an
implementation,
but
we
did
have
a
couple
of
instances
very
recently
for
two
components
that
were
not
weared
up
in
the
components.go
and
then
we
just
and
then
users
wanting
to
use
those
components
just
asked
you
know
where
is
it
so
should
I
can?
I
add
those?
Can
I
just
wire
them
up
and
we
were
not
sure
whether
those
components
were
actually
ready.
B
Well
true,
but
I
mean
I
guess
the
point
is
there
might
be
situations
where
people
just
stop
in
the
middle
and
I
don't
know
they
they
miss
one
part.
You
know.
G
A
Unless
the
issue
is
closed.
We
look
at
the
issue
is
the
issue
close.
Then
the
issue
gets
closed.
Whenever
we
hook
the
component
into
the
release,
repo
or
because
release
report
will
be
used
like
in
two
three
weeks.
I
don't
know
the
stat
the
status,
but
I
expect
in
two
three
weeks
to
to
no
longer
have
the
components
and
have
the
release
repo.
So
at
that
point,
what
I'm
trying
to
say
is
you'll
have
that
in
that's.
It.
B
Yeah
yeah,
I
don't
know,
I
think,
given
you
know
the
amount
of
people
that
seem
to
prefer
one
pr
like
one
big
pr
with
the
whole
implementation,
we
can
give
it
a
try.
I
think
alex
just
just
mentioned
here
in
the
chat
that
he
could
be
the
one
doing
this
template
and
see
how
it
goes.
Let's
see,
let's
revisit
this
decision
in
a
month
and
see
you
know
whether
that
was
good.
F
Because
I
I'm
curious
is
anybody
else
on
this
call
have
any
other
opinions
that
haven't
been
discussed
already,
because
there's
there's
a
few
more
people
that
haven't
spoken
up
yet.
J
I'm
happy
to
align
my
anecdotal,
you
know
experience,
which
was
when
we
made
a
datadog
contribution
a
while
ago.
There
was
definitely
this
weird
interim
period
of
like
a
couple
weeks
where
the
repo
like
had
a
datadog
exporter
or
whatever,
like
you,
look
in
the
exporters
directory
and
it's
there
and
but
it
hadn't
yet
been
added
to,
like
you
know,
actually
like
add
it
as
a
component.
It
was
just
like
earlier.
You
know
the
first
second
step
and
users
were
like
trying
to
install
it
and
then
like
hitting
up,
support
and
being
like.
J
What's
going
on,
so
I
don't
know
it
wasn't
the
end
of
the
world,
it
was.
We
just
had
to
be
like
hey
or
work.
You
know
like
we'll,
let
you
know
what
release,
but
it
definitely
was
at
added
some
confusion
if
you
know
so,
that's
my
anecdotal
evidence.
Experience.
I
I
I
I
I
A
No
no
comment:
let's
we,
we
are
moving
towards
that
direction,
so
we
will
see
if
that
gets
more
clear
or
not,
but
to
make
sure
everyone
understands
we
by
by
separating
these,
we
have
to
have
two
prs,
which
will
be
asynchronously
so
hence
hence
and
probably
will
have
to
wait
for
a
release
cycle
or
something
like
that,
because
because
you
need
to
release
first
that
and
then
you
can
include
them.
I
Encourage
the
world
here
and
I
I
think
that,
judging
from
the
comments
on
this
issue,
everybody
is
on
board
with
the
last
step
being
separate
of
actually
enabling
the
component,
and
I
I
don't
think
that
that
is
part
of
the
concern,
at
least
not
as
it's
not
part
of
the
concern
that
I've
had.
My
concern
with
the
fragmented
process
has
always
been
it's
hard
to
review
only
part
of
a
component
and
not
knowing
what's
coming
next
and
not
being
able
to
see
it
as
a
whole.
I
A
But
on
the
other
side,
to
be
honest,
the
the
skeleton
that
you
have
initially
is
always
the
same,
and
you
know
that
is
the
skeleton
that
is
the
structure.
You
need
a
factory,
you
need
a
processor
or
whatever
you
are
building
structure,
and
then
you
need
the
implementation.
I
don't
think
between
the
first
and
the
second.
Pr
is
something
unexpected
like
on
the
other
and
against
your
argument.
I
G
D
G
D
Up
being
any
push
for
like
if,
if
there
was
this
push
of
everyone
saying
okay,
we
want
to
have
one
pr
for
the
implementation.
Could
it
be
strongly
encouraged
potentially
to
have
different
commits
like
the
first
commit?
Is
your
factory
implementation?
The
second
commit
is
a
different
piece
of
like
finding
it
in
between,
if
that
ends
up
being
the
the
way
that
it
goes.
I
I'm
not
usually
a
fan
of
rebasing,
but
that's
a
problem
that
can
be
solved
by
rebasing,
and
I
think
that
the
the
proposal
to
use
commits
instead
of
separate
pr's,
to
allow
people
who
want
to
review
in
independent
chunks
to
do
that
and
a
lot
of
people
who
want
to
review
it
as
a
whole.
To
do.
That
is
the
closest
we're
going
to
get
to
the
best
of
both
worlds
and
a
happy
medium
for
everybody.
D
A
Okay,
so
now
now
after
this,
I
have
a
comment
about
the
first
commit:
okay,
because
I'm
taking
them
one
by
one,
and
I
want
you
to
show
me
how
you
resolve
my
comment.
Okay,
now
now
most
likely,
because
because
it
will
be
extremely
hard
for
you
to
insert
a
commit
as
a
second
commit
and
move
the
others.
So
it's
way
harder
than
rebasing
and
having
different
branches.
B
D
B
A
It's
not
very
common,
as
there
are
different
pr's
like
for
me,
if,
even
if
we
explain
to
a
user
that
has
to
do
this
versus
has
to
do
different
years
and
and
the
whole
and
the
whole
problem
on
them
with
with
having
to
do
this,
they
still
have
to
to
do
the
rebase
of
the
others,
because
things
are
changing
and
and
so
on.
So
it's
just
complicates
things,
but
I'm
happy
to
try,
but
I
don't
know
how
to
explain
to
the
user
that
hey.
A
B
So
I
think
I
don't
know
I
think
in
in
the
day-to-day
it's
not
going
to
be
a
huge
problem.
I
think
we
are
going
to
end
up
reviewing,
perhaps
in
chunks
but
then
releasing
the
review
after
we
review
everything.
So
that's
at
least
how
I
do
I,
when
I'm
reviewing
something.
I
I
leave
comments
and
then
perhaps
I
pick
up
reviewing
the
next
day
and
once
I'm
done,
then
I
submit
the
review.
A
How
can
you
split
that?
Because
I
don't
know,
maybe
you
have
super
power,
but
for
me,
if
I
don't
have
an
hour
to
spend
on
a
three
thousand
prs
to
line
pr
consecutive
like
resetting,
takes
me
20
minutes,
because
I
forget
the
whole
context
like.
B
I
pick
up
from
the
last
comment
that
I've
made,
so
I
just
go
to
the
last
comment
and
and
continue
from
there
and
if
it
helps
I
I
do
review
using
the
the
github
integration
for
visa
should
a
visual
studio
so
that
they
can
review
within
a
code
editor.
So
I
think
it
it
helps.
But
I
don't
know
that's
that's
my
experience.
I
B
I
don't
know,
I
think,
would
you
be
willing
to
try
this
new
policy,
for
I
don't
know
a
month
and
then
we
we
before
we.
A
Before
before
starting
this,
we
need
to
start,
we
need
to
have
a
plan
of
what
we
are
trying
the
next
month
correct.
So
we
say
for
new
components:
we're
gonna
do
an
issue
with
where
we
we
ask
for
enough
details
enough
configuration
details
or
whatever
we
want
to
ask
there
to
feel
confident
that
we
want
to
accept
this
correct.
So
that's
that's
the
first
thing
that
we
we
said
as
an
action
item
before
before
starting
the
experiment.
A
I
mean
not
before
solid
as
part
of
the
experiment.
We
we
have
this
issue
and
and
then
we
let
user,
submit
a
huge
3000
prs,
which
I
will
never
review,
but
I
bet
you
and
alex
can
review
and
give
me
feedback,
and
that's
it.
F
I
I'd
like
to
point
out
that
my
my
comment
on
that
issue
just
talks
about
being
able
to
see
both
sides
of
the
argument.
I
don't
have
a
strong
preference.
One
word
the
other.
I
I
do
want
to
call
out
that
this
this
problem
we
have
with
prs
being
too
large,
often
and
and
not
having
enough
time
to
dedicate
to
it.
It
comes
back
down
to
not
having
enough
approvers
in
my
mind.
F
B
Yeah-
and
you
know
one
of
the
steps
there
with
including
the
checklist
is
people
wanting
to
get
a
component
within
the
contrib.
They
need
to
get
a
sponsor.
So
it's
not
me
or
alex
who's,
we're
going
to
review
it.
It's
a
sponsor
all
right.
So
if
people
cannot
find
even
find
a
sponsor
for
the
component,
then
there
is
no
code.
Gonna
be
written
anyway.
D
And
the
issue
template
is
helpful
for
multiple
reasons.
Right,
like
I
know,
when
we
started
doing
issue
templates,
we
went
from
having
like
what
bogdan's
original
concern
was
of
someone
just
putting
a
one
line
of
this
doesn't
work,
or
this
is
what
I
want
and
having
like
you're
guiding
them
so
that
they
answer
all
the
questions
and
you're
getting
the
information
that
you
need,
you
being
any
of
us
or
anyone
else
looking
at
it,
so
that
others
can
get
involved
in
esdras.
D
A
B
Yeah,
you
know
sorry,
so
you
know
I'm
not
advocating
for
five
thousand
pr's
just
to
exaggerate
a
little
bit
more,
I'm
I
am
advocating
for
the
minimal
amount
of
of
code
that
that
provides
a
solution.
B
If
the
solution
is
three
thousand
lines
of
code,
then
so
be
it
and
one
example
is
like
you
know:
the
load
balancing
exporter,
where
we
have
multiple
implementations
for
reservers
and
multiple
implementations,
for
something
else
that
I
don't
remember,
so
we
can
start
with
one
implementation
of
each
one
of
those
interfaces
and
then
subsequent
prs
can
extend
that.
So,
if
that's
the
case
for
components,
we
can
ask
people,
you
know,
have
one
implementation
of
that
and
then
subsequent
prs
are
going
to
implement
new
are
going
to
provide
new
implementations.
B
A
Okay
sure,
please
document,
if,
if
you
think
you
you
want
to
document
this
during
the
experiment
or
or
how
to
point
people
during
this
month
of
this,
is
the
new
rule
happy
to
to
review
that.
B
All
right,
there
is
a
checklist
issue
that
I
created,
that
might
have
originated
this
one
here.
I
don't
know.
B
Oh
okay,
yeah,
so
I
think
the
first
step
is
then
to
to
agree
on
this
checklist
for
new
components
and
change.
I
changed
yeah.
I
just
added
a
link
to
the
agenda,
so
you
can
you
can
find
the
link
on
the
agenda
under
the
last
time
yeah.
So
I
think
the
first
step
is
then
to
agree
on
the
checklist
and,
of
course,
change
what
I've
have
what
I
have
there.
B
B
A
Argument
by
the
way
for
the
first
pr
to
be
just
the
skeleton
is
like
we
have
lots
of
places
where
you
have
to
update
this,
like
dependable,
make
file
and
stuff
and
and
if,
if
maybe
I
don't
know
you
do
it,
you
said
one
for
pr,
but
you
need
to
make
sure
everything
is
is
enforced.
Like
you
add
it
everywhere,.
B
I
mean
this
checklist
has
to
exist
somewhere
right
so
right
now
it
is
on
on
this
issue
just
for
us
to
understand
what
are
the
items
that
we
require
for
each
component
and
then
they
could
be
part
of
the
template.
Saying
you
know
check
this
box
here.
If
you,
if
you
changed
the
code
owner's
internal
component,
test,
the
go
mod
and
so
on
and
so
forth,
yeah.
H
A
As
I
said
happy
to
give
a
try,
I
don't
know
how
it
will
work,
but
definitely
it
needs
a
lot
of
work
on
the
the
that
issue,
template
that
you
you're
you're,
relying
on
because
that
becomes
the
the
root
of
everything.
G
A
Jurassic,
okay
and
the
last
one
is:
there
was
a
proposal
from
anthony
to
change
the
the
when
apr
is
marked
as
ready
for
review
to
have
a
policy
for
that
there
there
was
a
copy
from
from
whatever
open,
telemetry
goal
has
in
in
their
repo
and
in
the
whole
discussion.
A
You
can
follow
it's
a
lot
of
discussion,
but
the
the
decision
was
to
ask
the
gc
to
come
up
with
the
org
level
policy
that
we
should
adopt
across
all
the
repos
instead
of
having
a
one
time
at
every
level.
Discussion
about
this
is
good.
This
is
not
good.
I
think
this
is
something
that
we
need
to
to
address
at
the
organization
level
and
just
follow
the
rules.
A
Because
the
reason
for
me,
at
least,
the
reason
is
this
is
this-
was
initially,
I
think,
correct
me
from
wrong
anthony
but
was
based
on
what
the
specs
required
with
the
with
regard
to
different
companies,
different
people
whatever
and
then
was
copied
to
go.
But
I
feel
like
for
specs.
I
do
understand
all
these
requirements,
because
that
influence
the
entire
organization
compared
with
at
the
sig
level.
I
A
Maybe
it
was
not
based
on
that,
but
definitely
it's
in
the
specs
as
a
strong
requirement
in
the
spec
and-
and
we
do
have
in
the
spec
configured
to
have
two
approvals
and
a
bunch
of
other
things
in
you
know
tap.
We
have
four
approvals
and
anyway,
rebels
that
are
are
influencing
all
the
other
sigs.
A
We
we
have
very
strict
rules,
but
for
this
one
I
don't
know
if
we
need
to
follow
the
same
three
group
or
not,
and
there
was
a
ask
for
for
having
gc
involved
and
that
I
think
the
decision
right
now
is
to
to
wait
for
gc
to
discuss
this
this
policy
and
provide
the
guidance
on
how
to
to
deal
with
the
with
this
policy
of
how
to
merge
prs
in
this.
B
Now
it
is
somewhat
related
to
to
this
to
the
core
of
this
issue.
As
I
see
it,
but
I
think
having
a
a
better
diversity
of
maintainers
in
terms
of
the
companies
they
belong
is
a
good
thing
for
the
project.
B
I
think
that
no
one
can
dispute
that,
and
in
that
sense
you
know
if
you
are
interested
some
message
to
everyone
here,
if
you
are
interested
in
becoming
a
maintainer
and
approver
and
so
on,
talk
to
other
folks,
so
children,
because
I
think
it
is
in
everyone's
interest
to
have
more
approvers
and
more
maintainers
on
the
contrib
and
on
the
core
as
well.
A
Yeah,
but
I
don't
think
we
should
artificially
increase
that
number.
Unless
it's
meritocracy,
I
mean
I'm
and
I'm
not
arguing
about
anything.
I'm
just
saying
that
that
we
are
representing
in
open
source,
usually
an
individual
represents
himself
in
first
and
then
the
company
and
and
it
should
be
based
on
their
merit
to
become
a
maintainer
or
not
not
just
because
we
need
a
different
company
involved
into
the
the
project.
B
Anybody's
proposing
that
yeah,
that's
not
what
I'm
saying
yeah
I
mean
what
I'm
saying
is.
If
you
are
interested
you
know
we
have
other
like
11
10
people
now
in
the
call.
So
if
you
are
interested
in
becoming
an
approver
or
maintainer
express
your
interests,
so
people
cannot
know
whether
you
want
to
be.
If
you
don't,
if
you
don't
speak
up,
I
think
that's
the
message
that
I'm
trying
to
to
spread.
A
Yeah
and
will
be
happy
to
to
help
everyone
like.
I
think
we
increase
the
numbers
in
contrib
and
we
want
to
increase
even
more
there.
Also
another
option.
If
you
want
you
can
we
can
always
give
a
more
try
to
the
country
repo
as
well
to
us
find
new
new
places
where
we
have
11
or
whatever
number
of
approvals,
so
it
may
be
easier
to
to
do
the
cross
companies
things
there.
A
But
I
again,
I
don't
think
anyone
in
open
source-
or
I
expect
nobody
represents
their
companies
more
than
having
the
like
focus
on
the
the
healthy
of
the
project,
and
I
I
think
like
what
I'm
trying
to
say
is.
I
think
for
me
personally,
the
project
is
the
first.
I
don't
care
too
much
about
splunk,
besides
the
fact
that
they
give
me
a
paycheck,
but
I
can
get
a
paycheck
from
other
companies
as
well.
I
I
agree
with
you
to
to
a
great
extent
there.
I,
I
think,
we'll
continue
this
discussion
with
the
gc,
but
I
also
think
we
have
to
be
pragmatic
and
recognize
that
there
are
companies
that
have
invested
in
this
project
and
for
the
health
of
the
project.
We
need
to
continue
to
have
companies
invest
in
this
project
because
they
provide
the
individuals
that
are
providing
the
contributions.
B
Yeah,
I
think
I
think
we
might
continue
this
discussion
next
week,
so
perhaps
what
we
are
we're
discussing
that
on
the
gc
level
as
well,
but
you
know-
and
you
probably
know
my
opinion
program,
but
I
think
we
could
have
clear,
clear
paths
here
in
the
project
saying
you
know
this
is
how
you
get
to
become
a
maintainer.
So
this
is
how
you
get
to
become
an
approver.
I
know
we
have
some
of
those
guidelines
already
for
the
project,
but
I
think
it
can
be
more
concrete.
It
can
be
more.
B
A
A
B
B
The
last
meeting
that
we
had
we
we
discussed
about
taking
one
or
two
sigs
and
using
as
guinea
pigs
you
know
so
to
speak
and
and
and
see
what
we
can
do
at
the
gc
level
to
help
this
those
six
and
then
show
other
sigs.
You
know
this
is
those
are
the
benefits
that
you
get
from
from
having
a
health
report,
I
think
was
the
name
of
that.