►
From YouTube: 2020-12-14 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).
B
C
A
In
my
parents
basement
doing
medical
quarantine,
oh
such
fun,
yep!
What
an
interesting
year
it's
been.
D
Well,
I
get
the
extra
fun
that
my
18
year
old
is
having
emergency
wisdom
tooth
extraction
today,
so
emergency
wisdom
teeth
yeah.
Well,
she
I
mean
it's
not
like
life
and
death,
but
she's
got
a
lot
of
pain
from
it
banging
into
another
one,
her
other
molar,
so
ouch
that
sucks.
D
A
E
A
A
A
Would
be
better
yeah
because
it's
going
to
take
me
about
two
minutes
to
get
my
work
laptop
booted
up
and
it's
not
in
my
personal
drive
history
there
we
go
perfect
thanks
andrew.
A
F
Yeah
I
can
go
down.
The
agenda
items
was.
F
F
So
sorry,
sorry,
not
that
one
there's
a
service
name,
one
that
merged
that.
That
closed
a
bunch
closed.
At
least
one
of
the
p1
issues
correct.
A
We
got
that
tigran
got
that
one
closed
out.
I
think
last
week.
F
Yeah
five
days
ago,
so
that's
where
we
are
with
that.
Let
me
see
the
I've
got
a
couple
other
items,
I've
added,
but
we
can
go
in
whatever
order.
I
added
an
item
about.
I
noticed,
there's
github
discussions
feature
that's
now
usable
across
it's
like
public
beta
or
something
like
that.
You
can
enable
it
in
github
settings
and
we
have
austin
who
opened
up
this
issue
in
order
to
discuss
it,
which
may
be
relevant
to
all
maintainers.
G
G
I
think
it's
under
settings
and
you
might
have
to
be
paying
a
gc
person
if
it
isn't
available,
but
you
know,
run
those
as
you
will
try
to
maybe
get
stuff
out
of
getter
kind
of
end
user
q
a
and
put
it
into
discussions
just
because
they're
a
lot
easier.
I
feel
like
for
people
to
search
and
reference.
A
Yeah,
I
agree,
I'm
actually
super
excited
for
this.
Like
I,
you
know,
I
imagine,
we'll
still
use
gitter
a
bit
and
eventually
move
to
the
cncf
slack,
but
I
think
for
most
discussions
I
see
on
gitter
these.
This
github
forms
are
probably
a
lot
better.
G
And
we'll
start
driving
people
there
from
the
website
here,
probably
this
week,
perfect.
G
Problem
yeah,
I
just
there's
a
lot
of
discover.
I
mean
I
think
everyone
knows
about
the
discoverability
problems
with
with
getter,
and
I
I
don't
think
those
are
going
to
change.
You
know
those
aren't
going
to
change
even
when
we
move
to
slack.
So
I
I
like
this
as
something
that
is
a
bit
easier
for
us
to
deal
with
compared
to
just
I
don't.
H
Yeah-
and
I
think
that
the
good
thing
is
that
you
know
specifically
when
there
are
pr
issue
driven
discussions,
you
can
link
them
and
you
know,
that's
all
cross-referenced.
So
that's
useful.
G
H
So
I
have
a
question
still
so
for
the
language
specific
discussions.
We
do
that
on
the
language
reapers,
and
is
it
just
reaper
by
reaper
that
we
should
focus
the
discussions
on
and
what
about
cross
project
discussions?
Where
would
that
would
those
happen.
G
I
I
think,
cross
so
yeah
for
specific
language
things.
I
think
that
should
be
in
the
specific
discussion
for
that
language.
So
javascript
go
to
javascript
c-sharp
go
to
c-sharp
java
to
java
for
cross-cutting
things.
I
think
that
can
go
in
community
or
if
it's
you
know,
so
it
depends
on
how
cross-cutting
it
is
right.
H
G
G
Just
because
there's
a
pretty
established
process
for
those
and
I
it
doesn't
feel
like
a
good
fit,
there's
already
enough
stuff
going
on
in
spec,
because
in
some
ways
the
issues
in
the
spec
repo
are.
D
G
G
Like
end
user
q,
a
you
know,
bug
rep,
not
necessarily
bug
reports,
but
you
know
how
do
I
use
this?
How
do
I
use
this
with
a
specific
thing
patterns
for
instrumentation
whatever,
so
I
I
view
this
mostly
language,
repos,
collector,
repo
and
community
as
being
kind
of
the
big
places
where
this
happens.
A
One
one
small
add-on
question
for
discussions
that
are
rather
for
for
languages
where
you
have
multiple
repos
in
particular,
I'm
thinking
of
the
contrib
repos.
Do
we
want
to
have
discussion
forums
on
the
contributory
post
as
well
like?
Would
we
have
it
on
like
open,
telemetry,
go
and
open
some
free
go
contrib
or
just
on
open
telemetry
go,
I
suspect,
we'd
want
it
just
on
the
main
one.
Just.
H
D
I
actually
think
that's
definitely
not
the
correct
answer
for
auto
instrumentation.
It's
a
very
large,
distinct
project
that
I
think
has
very
distinct
concerns
from
the
api
and
sdk.
So
I
think
that
I
think
those
two
should
be
separate.
They
have
their
own
getter
channels
and
they
definitely
have
different
purposes.
D
G
No,
that's
a
good
point.
I
was
going
to
suggest
that,
like
I
think,
that's
a
good
place
for
categories
right,
like
you
could
have
if
you
did
want
to-
and
maybe
we
can
say
like
go-
gets
to
decide
differently
than
javascript
right,
like
that's
fine,
but
I
would
suggest
in
that
case
like
saying
like.
Okay,
there's
a
category
specifically
for
auto
instrumentation
stuff
and
there's
a
category
for
api
in
a
category
for
sdk,
so
things
can
be
grouped,
but.
G
B
H
Yeah,
so
then,
why
don't
we
make
it
simple?
And
just
because
I
mean
my
concern
is
that
as
maintainers,
we
know
where
to
go
and
look
for
the
right
discussion
and
we
can
figure
that
out.
You
know,
as
each
each
group
of
maintainers
decides
what
to
do,
but
on
the
other
hand,
inconsistency
also
makes
it
very
hard
for
new
developers
to
get
involved,
because
they've
got
to
figure
out
where
the
right
discussion
is
and
where
the
you
know
and
and
where
to
go
and
find
what
they're
looking
for.
C
G
That
said
I
I
don't
want
to
tell
anyone.
I
don't
want
to
tell
anyone
how
to
do
it.
I
think
part
of
me
thinks
that,
like
john
is
probably
more
right
than
I
am
here,
and
that
most
people
that
are
using
this
are
going
to
be
most
end.
Users
are
going
to
be
pretty
narrowly
scoped
they're
going
to
care
about,
like
java,
auto
instrumentation
or
they're,
going
to
care
about
like
go
contrib
and
they're,
probably
not
gonna
care
about
a
lot
of
other
things
and.
G
H
H
H
F
B
Yeah
sure
we
can
go
ahead
with
that,
so
it
feels
like
this
otep
has
sufficient
approvals
to
get
merged.
So
my
request
at
this
point
is
that
it
get
merged.
Unless
there's
any
last
minute
outstanding
discussion,
we
want
to
do
there,
I'm
starting
to
draft
a
pull
request
against
the
spec,
so
we
can
continue
to
have
discussion
there.
B
I
think
one
area
that
we
need
to
think
about
here
will
probably
maybe
there
are
two
areas
but
they're
related.
One
is
a
data
stability.
B
Is
like
something
that
seems
important,
but
it's
maybe
a
little
bit
more
vague,
especially
in
the
realm
of
metrics,
getting
some
feedback
that
from
josh
for
sereth,
for
example,
that
you
know
what
what
counts
is
like
a
breaking
change
to
dashboards.
You
know
how
do
we
manage
changing
the
data
that
we're
offering
and
I
think
there
will
be
another
question
around
adding
experimental
apis
into
the
contrib
experimental
signals
being
in
the
the
contrib
instrumentation
that
we're
presenting
to
people?
B
How
do
we
manage
that?
I
assume
we
want
to
have
experimental
signals
in
there.
Otherwise,
it'll
be
hard
to
tell
people
to
go
beta
test
things,
but
that's
a
maybe
something
that
deserves
a
little
more
thought
than
I've
been
able
to
give
it
so
far.
So
I
think
we
can
take
those
things
in
stride
and
continue
to
improve
this
stuff,
but
those
were
some
of
the
more
maybe
signal
specific
stuff,
especially
around
metrics,
for
languages
that
are
going
to
produce
stable
tracing.
B
So
that's
food
for
thought,
but
I
think
we
can
go
ahead
and
I
think
what
we
have
here
is
like
pretty
solid
as
far
as
a
non-signal
specific
proposal
for
how
we
do
versioning
instability.
So
I
think
we
should
just
keep
moving
with
this.
G
G
B
Yeah
yeah,
so
that's
no
longer
1.0.
So
one
of
the
things
here
that
I
put
a
note
at
the
bottom
but
didn't
get
too
detailed
into
we've
kind
of
tied
1.0
together
with
open,
telemetry,
ga
and
I'm
seeking
to
decouple
these
terms
here.
Part
of
the
problem
is
it's
just
actually
when,
in
fact
very
difficult
to
say,
open
telemetry
has
hit
1.0
because
yeah.
B
G
B
To
my
mind,
ga
is
is
when
we
have
offered
tracing
and
metrics
in
a
sufficient
number
of
languages
to
say
that
we
can
sunset
officially
sunset,
open
census
and
open
tracing.
So
I
think
that
I'd
like
that
term,
ga
to
like
specifically
be
that
moment
when
we're
turning
off
I'll,
try
to
add
some
more
clarity
on
that
front.
B
G
B
H
Now
think
ted
I
mean
the
approach
to
just
publish.
What
we
have
right
now
is
a
good
good
one,
and
then
we
can
iterate.
On
any
nuances,
I
mean
I'm
still
again
torn
between
the
project,
calling
things
ga
when
when
when
we
don't
have
full
functionality,
but
I
mean
stable,
would
be
perhaps
better,
but
that's
just
terminology.
B
Yeah,
well,
I
think
ga
would
be
for
when
we
have
tracing
and
metrics
stable
in
at
least
three
or
four
major
languages
right.
So
that's
one
thing
is
generally
available.
We're
not
saying
like
tracing
spec
is
1.0,
but
you
know
you
can't
use
it
anything
like
that.
So
that's
part
of
the
reason
I
want
to
decouple.
B
So
that
we
can
have
a
a
I'm
hoping
to
have
a
net,
you
know
1.0
announcement
eek
out
right
at
the
very
end
of
this
along.
You
know,
perhaps
in
the
same
announcement
or
right
next
to
it
with
a
a
description
of
all
of
this
stuff
and
how
we're
1.00,
but
we'll
be
nuanced
there
to
to
emphasize
this
is
this
is
like
tracing
and
metrics
is
going
to
come
and
then
we're
going
to
have
gta
so
I'll.
Try
it
and.
H
B
Yeah,
that's
a
good
point
and
I
did
not
actually
mention
anything
in
here
about
stability
being
tied
to
ci
cd
and
test
suites
of
any
particular
kind.
That's
actually
a
good
point,
so.
B
Yeah,
which
makes
sense
yeah
I'll,
try
to
emphasize
that.
I
think
I
did
have
one
question
kind
of
minor
question
we
do
need
to
have.
Do
you
think
it's
important
to
have
language
specific
versions
of
this
document
that
can
get
into
details
about
what
it
means
in
that
language
specifically
to
be
stable
in
versioning?
B
Since
you
know
there
are
nuances
across
languages
about
what
this
stuff
means,
and
that's
also
where
I
think
nuance
is
around
like
the
specific
stability
of
the
different
signals
in
that
language
and,
what's
going
on,
there
can
also
reside
because
I'm
trying
to
keep
this
stock
at
least
currently,
it
doesn't
specifically
get
into
anything
around
tracing
or
metrics
or
whatnot.
It's
just
trying
to
be
a
higher
level
guide.
B
I
don't
know
if
we
want
to
what
degree
we
want
any
kind
of
self-similarity
between
these
language
specific
documents,
I'm
gonna
go
in.
I
thank
you.
Everyone
who's
been
writing
them
by
the
way
I've
started
to
review
them
I'll.
Try
to
help
on
that
front,
but
yeah,
I'm
not
sure.
If
there's
like
a
standard
file
name
to
keep
this
stuff
in
or
or
anything
like
that
that
we
might
want
to
to
have
the
across
the
languages,
so
that's
sort
of
an
open
question.
H
I
think
ted
you
had,
I
mean
the
discussion
last
time
had
been
that
we'd
keep
the
overall
guideline
and
spec
in
the
spec
repo
and
then
the
language,
specific
versions
in
the
language,
reaper
core
language,
repos
and
then
just
interlink
all
of
them.
You
know
from
community
and
any
other
place
that
we
needed
to
I
mean
I,
I
thought
that
was
our
starting
point.
B
H
B
This
kind
of
thing-
okay,
great,
maybe
we
can
standardize
that
okay,
not
not
a
huge
issue
like
it's,
not
you
know
we
can
always
move
these
things
around.
What's
most
important
is
that
maintainers?
You
know
think
about
this
right
now
and
and
write
their
thoughts
down
to
make
sure
that
it's
there's
clarity
in
each
language
working
group
about
what
what
this
means.
I
think
that's
the
most
important
thing
really.
B
Is
that
we're
communicating
to
our
you
know
various
cigs
about
this
stuff,
just
so
that
everyone
is
clear
what
our
intentions
are
around
all
of
this,
so
that
we
don't?
We
don't
have
you
know
approvers
and
community
members,
not
getting
the
the
message,
and
you
know
we
make
blog
posts
and
stuff
too.
I
think
that's
probably
the
most
important
thing
just
make
sure
in
within
the
project,
we're
all
on
the
same
page
about
this
so
cool.
That's
all
I
got
thank
you.
Everyone
who's
contributed.
This
really.
F
I
saw
like
a
lot
of
activity
on
the
oteps
pr
143
like
this
thing.
Is
this
one
beat
out
60
otep
66
in
terms
of
number
of
comments
and
number
of
approved
approvers
on
the
thing
so
like
this
one
was
huge
and
all
within
was
it
within
two
weeks
or
something
so
this
is
by
far
one
of
the
hottest
hottest
topics
for
this
community.
F
So,
following
on
to
that,
I'm
also
trying
to
figure
out
like
how
we
should
structure
for
the
changes
that
come
in
after
otep
merges,
whether
we
need
to
track
things
differently,
update
it.
And
I
just
noticed
a
later,
you
put
in
an
item
about
the
gaa
spec
burndown
list
and
also
the
github
project
for
tracking
ga
high
level
items.
F
I
B
Yeah
I
mean
I
don't
want
to
destabilize
that
right
away.
I
think
I
think
required
for
ga
is
like
a
fine
label,
because
what
we've
meant
with
that
is
like
everything
we
need
to
do
to
get
tracing
and
metrics,
stable
and
and
deprecate
open
census
and
open
tracing.
So
so
I
think
that's
still
like
the
goal
we're
aiming
for
if
it
ends
up
being
the
case
that
we
want
to
have
more
nuanced
labels
around
like
trace
stability
and
metric
stability.
B
F
Well,
we've
been
keeping
like
party
one
as
for
the
spec
repo,
at
least
as
top
priority,
for
anything
related
that
if
it
were
to
be
labeled
like
trace
a
spec
trace
that
kind
of
signifies
like
hey.
This
has
to
be
taken
care
of
in
order
to
make
sure
that
the
other
languages
can
implement
properly,
and
it
stability
implicitly
comes
out
of
like
how
many
p1s
do
we
have
to
handle.
Do
they
come
up
that
often
are
only
p2s
and
p3s
coming
up
and
that
kind
of
implies
the
stability.
F
F
Okay,
so
I
perhaps
we
just
keep
tracking
the
way
we
have
it
then
yeah
I
mean,
I
think.
B
Ga
we're
saying
you
know
we're,
I
think
we
as
long
as
we
know
what
we
mean
here.
I
think
it's
okay.
If
it
starts
to
become
confusing
within
the
project.
What
what
we're
talking
about
then
yeah
we
should.
We
should
change
this
up,
but
yeah
I
don't
want
to
I
I
want
to.
Ideally
I
also
want
this
the
the
way
we
label
this
stuff
to
remain
consistent
as
well
right
for
people
who
are
trying
to
follow
along
on
this
stuff.
I
I
A
F
B
F
B
Gonna
say
that
ga
specifically
means
tracing
and
metrics
are
stable,
along
with
cicd
performance
and
whatever
other
testing
we
need
to
have
in
place
and
that
it
is
all
of
that
is
released
and
available,
and
I
was
saying
in
the
doc
at
least
three
languages
to
me:
that's
general
availability.
B
B
I
don't
I
if
we
also
have
like
spec
work
around
requirements
around
like
performance,
testing
and
stuff,
I
think
we
have
some
of
that.
Respect
to
you
know
all
of
that.
This
that's
collection
of
work
needs
to
be
done,
but
that's
what
we're
currently
saying
required
for
ga
means.
So
I
don't
think
we've
changed
the
definition
there.
H
B
We
could
change
that
definition
to
to
mean
specific
languages
or
or
say
four
languages,
yeah
that
that
part
I
felt
was
just
a
little
subjective.
We,
I
don't
think
we've
like
necessarily
tied
it.
B
I
think
we've
always
in
our
heads
had
the
four
languages
that
would
be
gadfirst
where
java
go
javascript
and
python,
just
because
those
were
the
four
that
were
kind
of
started
first
and
they're
important
languages,
but
you
know
nets
an
important
way.
Everyone's.
The
language
that
someone
uses
is
the
most
important
language
to
them.
So
if.
B
Ideas
about
yeah
how
we
want
it
maybe
more
tightly
to
find
that
before
ga.
But
you
know
maybe
another
question
is
if,
if
the
four
languages
that
got
there
were
where
java
go
erlang
and
net,
is
that
fine
to
say
we're
now
at
ga
yeah.
H
I
mean
again
going
back
to
the
point
that
you
know
some
of
the
languages
are
more
mature
just
because
of
the
work
that
has
been
done
in
them.
That
said,
you
know
again,
there
are
other
requirements
for
ga
per
se,
like
performance
tests
or
benchmarking,
as
well
as
other
types
of,
and
also
releases
right,
because
that
that's
all
tied
into
what
we
provide
as
artifacts
and
and
so
maybe
it
is
good
to
have
certain
languages
meet
the
bar
first.
H
In
order
for
the
project
to
be
saying
these
that
we
are
at
ga
again,
we
can,
we
can
discuss
it
either
way,
but
so
far
at
least
we've
had
the
four
languages
that
you
mentioned
tracking
ahead,
but
at
this
point,
even.net
has
actually
completed
significant
amount
of
functionality,
see
how
c
plus
plus
has
and-
and
some
of
the
other
languages
are
also
starting
to
pick
up
momentum.
B
B
If
we
want
to
have
some
kind
of
ga
announcement
we
have
to,
we
have
to
pick
a
point
where
it's
sufficiently
available,
that
a
lot
of
people
can
use
it
and
yeah.
I
I
just
put
a
number
in
there,
mainly
because
I
didn't
want
to
call
out
specific
languages,
because
I
don't
think
we've
officially
tied
it
to
like
some
specific
languages.
It
was
more
a
presumption
because
at
the
time
we
were
talking
about
it
earlier,
some
languages
were
just
farther
ahead
than
other
ones.
So
yeah,
I
think
we
can.
H
H
Sounds
good
and.
F
But
am
I
correct
in
assuming
that,
like
as
a
result
of
this
otep
143,
the
significance
of
at
least
the
versioning
numbers,
what
we're
trying
to
arrive
at
is
when
open
telemetry
declares
ga
the
version
number
may
not
be
1.0.
B
It's
just
that
for
some
languages,
there's
there's
enough
interest
in
the
tracing
portion
and
the
tracing
portion
is
stable
enough,
that
it
is
worth
it
to
those
languages
to
to
do
the
work
today
or
you
know,
do
the
work
now
to
ensure
to
fork
out
tracing
as
stable
and
metrics
is
experimental
and
ensure
that
that
is
battened
down
so
that
they
can
go
1.0
and
give
people
access
to
stable
tracing.
B
So
that's
that's
like
the
main
difference
from
what
we
were
talking
about.
Ga
before
we
were
talking
about
before
you
had
to
the
presumption
was
we'd,
be
releasing
tracing
and
metrics
at
the
same
time,
and
just
in
practice
that
turns
out
not
to
be
true
for
languages
that
are
are
not
at
the
point
where
people
are
are
really
pushing
for
this.
I
don't
you
know,
I
think
it
might
be
feasible
in
those
languages
to
to
you
know,
maybe
1.0
tracing
and
metrics.
B
At
the
same
time,
it's
just
the
question
of
when
that
language
wants
to
attach
a
stability
guarantee
to
one
of
the
signals
at
that
point.
As
soon
as
one
of
those
signals
you
want
to
be
stable
happens,
you
have
to
go
1.0,
but
you
don't
have
to
have
both
tracing
and
metrics
stable
in
order
to
1.0.
You
just
have
to
make
sure
that
metrics
has
been
successfully
boxed
off
from
tracing
in
such
a
way
that
the
tracing
packages
can
stay
stable.
According
to
the
rules
we
defined
in
this
document.
F
Okay
right,
I
think
that
helps
clarify
the
changes
in
expectation.
B
F
Okay,
I
think
these
other
item
sub
items
have
have
resolved
as
a
result
of
the
conversations,
and
at
least
for
what
I
want
to
bring
up
on
this
topic.
Alolita
is
this
related?
Is
there
anything
else?
I
need.
H
To
discuss,
I
think
I
think,
andrew
this
is
related
to
even
the
items
that
you
brought
up
and
you
know
again.
I
was
looking
at
not
so
much.
You
know
the
compatibility
matrix
and
the
items
that
are
already
you
know
clearly
defined
required
for
ga,
but
also
the
larger
assumptions
that
the
project
is
making
in
terms
of
guaranteeing.
H
You
know
prometheus
interoperability
or
zipkin
and
jaeger
interoperability.
You
know,
and
and
and
you
know
how
that
factors
in
into
ga,
because
we
definitely-
and
I
like
to
I'd
like
to
see
more
activity
and
and
momentum
maintained
on,
for
example,
ensuring
that
the
prometheus
you
know,
interface
with
open
telemetry,
is
built
out
and
fully
operational
and
compatible
and
again
the
discussion
being
that
you
know,
does
it
make
sense
to
have
a
work
group
specifically
spun
off
for
each
of
these
specialized
areas?
H
That
needs
you
know
deeper
expertise
and
and
focused
expertise
for
the
from
specific
maintainers
who
are
involved
in
this
right,
because
not
all
maintainers
are
deeply
involved
in
these
specialized
areas.
So
how
do
we
do
that?
And
is
that
still
considered
required
for
ga
or
or
is
it
something?
That's
not
for
metrics,
especially.
B
Yeah,
I
think,
all
of
that's
required
for
g
in
order
to
say
that
a
signal
is
is
stable.
To
my
mind,
that
includes
the
the
thing
we've
identified
as
core
plug-ins
have
to
be
stable
as
well.
It
has
to
be
stable
from
the
perspective
of
the
the
end
users
right.
B
So
I'm
also
as
part
of
this
trying
to
more
concretely
define
these
different
types
of
end
users
or
roles
right
because
we
say
end
user,
but
it's
actually
application
owners,
plug-in
authors,
instrumentation,
authors,
library,
authors,
there's
actually,
four
groups
that
you
need
so
but
yeah
for,
certainly
you
can't
say
tracing
is
stable
if
you
can't
connect
it
to
jager
or
otlp
or.
H
H
Yep,
so
I
mean,
would
it
make
sense
to
have
more
specialized
discussions
around
these
topics
in
in
more
specialized
forum
for
free,
and
these
are
again,
I
envisioned
them
as
short-term
forums
in
the
sense
that
until
metric
stabilizes
again
there's
an
focused
push
to
make
this
happen.
We
target
you
know
three
months
of
work
or
two
months
of
you
know
focused
work
and
commitment
from
you
know
various
core
maintainers.
B
So
I
would
look
at
that
from
the
perspective
of
cross-language
work
right.
If,
yes,
let's
use
prometheus
as
an
example,
we
want
to
have
the
algorithm
for
talking
to
prometheus
to
be
the
same
across
languages.
I
presume
that
you
know
maybe
language
specific
squiggles,
but
from
the
perspective
of
these
should
all
be
black
boxes.
B
B
That
should
be
that's
a
cross-language
concern
and
for
once
that
isn't
obvious,
like
jager,
for
example,
is
maybe
obvious
enough
that
it's
not
necessary,
but
for
prometheus,
that's
actually
a
tricky
wicket
right
yep.
It
makes
sense
to
me
that
we
get
a
a
special
interest
group,
prometheus
special
interest
group
together
to
define
what
those
things
are.
B
There
is,
I
think,
a
separate
question.
I
know
you
were
asking
about
around
like
the
ability
to
directly
manage
some
of
those
things
and
whether
or
not
we
want
to
have
more
specialized
maintainer
roles
per
language.
Do
right
now
we
have
language
maintainers.
B
B
B
You
know
with
like
directory
specific
code
owners
to
allow
maintainers
and
from
to
allow
a
prometheus
group
to
maintain
all
the
prometheus
stuff
yeah,
and
the
question
there
to
me
is
mostly
like.
Is
that
helpful
to
the
core
maintainers?
Does
this
relieve
a
bottleneck
or
does
this?
H
And
also
ted
to
your
point
again
also
I'm
interested
in
getting
the
prometheus
upstream
core
team,
also
more
involved
and
committed
to
supporting
the
algorithm
in
the
project.
So
it's
a
win-win.
B
Would
be
what,
if,
what,
if
the
core
prometheus
people
want
to
take
on?
You
know
the
to
some
some
degree
of
like
the
maintenance
and
ownership
of
the
pre-atheist
stuff
within
open,
telemetry
and
start
to
look
at
open.
Telemetry
is
like
a
primary
prometheus
client.
I
think
that
would
be
great,
but
obviously
those
people
don't
need
to
have,
like
you
know,
approval
access
to
things
outside
of
prometheus.
So
right.
H
Right
exactly
exactly
ted
and-
and
you
know
that,
hence
I
mean
it's
an
it's
a
more
complex
discussion
and
hence
the
need
for
an
a
more
specialized.
You
know,
meeting
point
and
and
discussion
point.
D
I
would
think
if
we
wanted
to
go
down
that
route
road,
we
would
pull
the
prometheus
integration
into
its
own
repo,
rather
than
trying
to
maintain
it
in
the
main
repo
yeah.
H
Yeah
john,
I
mean
that
was
the
concern
that
I
had
because
there's
enough
work
there
that
needs
to
be
done
in
different
parts,
different
components
both
in
the
languages
as
well
as
the
collector
and
there's
related
testing.
There's
related
impact
to
the
any
you
know
refinements
that
need
to
be
done
to
the
spec
today.
The
many
aspects
right.
B
There's
also
things
like
for
the
course
stuff
if
it
can't
get
pulled
out,
if
we're
going
to
say
this
is
a
core
part
of
the
sdk
and
the
sdk
is
going
to
include
things
like
environment
variables,
for
enabling
and
disabling
this
stuff,
yeah
flip
side
of
that.
If
these
things
require
pull
in
dependencies,
that
people
don't
always
want,
you
know
that
are
going
to
create
conflicts
and
people
want
to
drop.
B
I
I
think
we
have
there's
some
issues
related
to
these
core
plug-ins
that
we
haven't
thought
through
very
well.
I
agree
that
in
the
ideal
world
these
would
be
in
separate
repos,
or
these
would
be
in
contrib.
B
You
know,
but
one
of
the
reasons
that's
been
difficult
so
far
is
a
lack
of
the
kind
of
ci
cd.
That
would
make
that
helpful
right
like
when
you
decouple
these
things,
then
now
you've
you've
got
a
distributed.
Build
right.
You've
got
a
release,
train,
not
everything,
bundled
up
in
one
spot,
so
you
need
or
ci
cd
to
make
that
work.
So
part
of
the
back
and
forth
different
language
groups
have
been
having
around
everything's
in
core
no
way
we
want
to
shovel
some
stuff
out
into
another
repo
called
contrib.
B
B
H
B
You
know
I.
I
would
love
to
see
this
stuff
work
as
like,
distros
to
some
degree.
If
we
could
package
this
up
as
distros,
so
that
you
could
have
a
distro
that
had
just
core
stuff
but
didn't
include,
you
know
any
plugins
except
otlp
and
trace
context,
or
maybe
not
even
that
versus
a
a
distro
that
had
you
know,
a
larger
subset
and
then
a
distro
that
had
contrib
and
everything
in
it.
But
I
don't.
I
don't
have
like
a
concrete
proposal
there.
B
So
if
other
people
have
ideas
about
a
great
way
to
to
carve
this
up
good
time
to
to
write
it
up,
but
I
think
that's
got
to
be
a
separate,
separate
hotep
from
all
this.
H
Yeah
I
mean
that's
a
separate,
hotep
and
actually
ted
I'm
interested
in
that
so
I'll.
Definitely
in
a
little
bit
of
time,
I
may
have,
in
the
last
week
of
december
take
a
crack
at
drafting
a
proposal.
That's.
H
Yeah
no
worries
I
mean
I'll
I'll,
take
a
look
at
that
because
we've
already
been
looking
at
it
from
an
distro
point
of
view
for
the
aws
distro
that
that's
there
downstream.
So
again
we
have
some
ideas.
B
Okay,
we're
at
the
last
10
minutes
here.
Andrew,
do
you,
you
have
other
items.
Carlos
you've
got
two
more
related
to.
E
This
is
this
is
just
for
your
information
maintainers
just
be
aware
that
there's
a
new
item
that
we
added
we
merged
it
today,
basically,
service
name
for
resources
is
now
requires
a
default
value
and
it
has
also
its
own
role
in
the
spec
compliance
matrix.
E
So
just
for
your
information,
the
second
one
is
about
something
we
talked
about
last
week.
I
don't
remember
whether
that
happened
here
or
in
the
specification
one
yeah.
I
would
like
to
get
attention.
I
posted
my
my
opinion
on
that
one.
I
was
planning
to
spend
some
time
briefly
discussing
it
here,
but
I
don't
know.
Do
we
have
something
more
important
to
talk
about
or
not
because
I
have.
E
F
Sure
I
just
had
a
quick
admin
item
about
like
specsic
is
canceling
the
december
29th
tuesday
meeting
curious
to
know.
Would
we
be
interested
in
cancelling
this
december
28th
maintainers
meeting
on
the
monday.
C
F
F
Okay,
yeah
yeah,
then
yeah
I
mean
we
ought
to
just
circulate
it
then
like
on
gear
and
all
that
stuff.
It's
like
that
week.
F
Last
week
of
2020.,
okay,
lolita
sorry
was
this
a
follow-up
or
is
it
another.
H
Issue
about
no,
this
is
just
an
update.
This
is
just
an
update
just
wanted
to
let
all
the
maintainers
know
that
you
know
that
we
had
had
a
target
of
migrating
all
the
ci
cd
workflows
that
exist
on
the
reapers
to
github
actions,
and
this
was
primarily
because
cncf
had
asked
us
to
kind
of
migrate
off
the
circle
ci
dependencies
to
get
her
actions.
H
So
my
team
has
been
working
on
the
last
of
the
three
repos
that
were
on
github
actions
and
just
to
let
you
know,
we
have
completed
the
go
and
js
migrations
thanks
to
the
go
and
js
maintainers,
you
know
reviewing
and
integrating
that
and
just
to
the
collector
maintainers
again
bogdantegrin.
H
You
know
we
will
be
fighting
prs
this
week
on
the
migration
of
the
collector.
You
know,
workflows
would
be
great
to
have
your
reviews
and
you
know
iterate
on
anything
that
you
would
like
to
modify
there.
So
that
will
complete
the
updates.
You
know
to
actions
at
least
for
the
existing
workflows
and
then
yeah.
H
C
H
Right
right,
right
and
and
bogdan
again,
that
was
you
know
what
we
kind
of
assumed.
C
C
H
Yep
good
good
point
and
the
other
aspect
which
I'd
like
to
just
suggest,
in
addition,
is
that
I'd
like
to
actually
see
another
workflow
being
added
to
all
the
reapers
for
code
scanning
security
vulnerabilities,
and
I
will
be
introducing
an
issue
on
that
and
a
pr
for
that.
Workflow.
Specifically.
So
just
a
heads
up.
C
Talking
about
prometheus
for
one
second,
there
is
a
pr
that
is
pretty
all
pretty
old
about
re-implementing
one
of
the
prometheus
exporters
in
in
collector
a
lolita.
Does
anyone
from
your
side
has
cycles
to
review
that
other
or.
H
Yes,
we
do,
we
do
bogdan,
we
were
just
actually
we
are
backlogged
this
week,
but
we
will
definitely
pick
it
up
end
of
this
week.
C
C
H
Have
cycles,
in
fact,
if
you
have
a
little
bit,
I
mean
we
can
take
a
look
at
that
pr.
I've
been
looking
at
it
and
can
definitely
work
on
it.