►
From YouTube: 2022-02-02 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
B
Yeah,
you
have
the
second
item,
yeah
so
a
little
outside
my
wheelhouse,
but
I
noticed
that
ci
is
failing
on
the
contrib
repo
and
it
appears
to
be
due
to
centos
8
being
end
of
life.
B
I'm
not
very
familiar
with
the
release
process.
What
the
implications
would
be
for
switching
switching
the
the
linux
distro
we
use,
but
I
was
curious
if
the
community
had
thoughts
on
how
we
go
about
making
the
decision
to
use
something
else
here.
B
I
believe
it
is
it's
used
in
ci,
as
I
think
a
test.
It
generates
a
test
artifact.
I
couldn't
quite
figure
out
where,
in
the
release
process
it's
generating
the
same
artifact
and
if
it's
using
exactly
the
same
distro
there.
B
But
it's
it's
basically
the
rpm
package
that's
being
built
and
it
fails
because
it's
not
finding
the
distro.
B
Anyways,
if
anyone
has
thoughts,
please
comment.
B
Apparently
there
is
sent
a
centos
stream,
but
it's
based
on
a
it's
basically
a
rebasing
of
the
entire
distro.
So
it's
a
bit
more
different
rocky
linux
is
apparently
sort
of
the
spiritual
successor
to
sent
to
us.
B
A
C
A
A
B
E
David
yep,
sorry
emily.
I
just
wanted
to
call
this
out.
This
is
one
of
the
items
that
came
up
as
I'm
working
on
the
prometheus
specification,
as
pointed
out
by
one
of
the
prometheus
maintainers
that
it's
not
a
good
idea
to
use
the
process
start
time
metric
as
the
start
time
for
cumulative
metrics.
When
we
scrape
a
prometheus
endpoint,
we
should
follow
josh
mcdonald's,
the
spec
that
he
put
together
for
how
to
handle
those
metrics
instead,
which
is
what
we
already
do.
E
So
I
believe
this
amounts
to
just
removing
or
deprecating
removing
behind
a
feature
flag.
The
prometheus
receiver
configuration
that
allows
you
to
use
the
process
start
time
metric.
E
E
C
If
we
added
a
feature
flag
for
this,
the
feature
flag
would
control
whether
that
configuration
option
did
anything.
So
we
would,
by
default,
allow
it
still
to
be
useful
and
then
eventually
change
the
flag
so
that,
even
if
someone
set
that
config
option,
it
wouldn't
have
any
effect,
but
the
feature
flag
could
cause
it
to
have
effect
again
and
then
totally
remove
it.
Would
that
be
the
progression.
E
Yeah,
I
would
probably
actually
say
that
the
feature
flag
would
control
validation
of
the
config
so
that,
if
the
feature
flag
was
enabled-
and
you
tried
to
set
the
config
option,
your
collector
would
err
on
startup
and
then
users
that
are
on
that
version.
E
As
long
as
it's
in
beta,
they
still
have
the
option
to
disable
the
feature
flag
and
continue
using
the
option.
But
it's
a
way
to
let
them
know
so
that
if
they
need,
if
they
need
to
come
comment
on
the
issue
or
otherwise
that
they
have
a
period
of
time
where
they're
not
broken.
D
Should
we
always
at
least
log.
D
D
D
It's
it's
already
enabled
that
feature
flag
correct.
So
when
you
add
it
you
add
it
directly
enable
you
don't
go
through
the
whole
process
of
you
added
disabled
and
test
enabled.
D
C
C
Yeah,
I
I
think,
that's
probably
fine
too.
It
has
largely
the
same
effect
as
a
warning.
Right
it'll
give
the
users
some
indication
that
that
a
change
is
coming,
but
it's
actually
more
aggressive.
It
says:
okay,
you're
not
going
to
be
able
to
use
this
without
some
intervention.
So
we
know
that
you've
noticed
that
this
change
is
coming,
whereas
emitting
a
log
to
warning
to
the
logs
might
get
totally
missed.
D
So
another
option
is
we
make
it
three
step.
First,
we
add
an
ordering.
Second,
we
do
the
feature
flag,
disabling
and
third,
we
remove
it
completely
and
that's
it
so
three
step.
I
think
it's
the
best
of
the
both
worlds,
where
you
have
a
chance
to
to
see
this
in
the
first
version
in
the
second
version,
you
have
to
do
something
in
the
third
version.
No,
no
luck
for
you.
C
E
I'm
just
gonna
say
that,
like
there
are
many
people
at
google
who
use
this
sort
of
thing
and
do
all
sorts
of
things
I
wish
they
didn't,
but
this
is
to
cover
my
butt
half,
but
I
also
think
there's
plenty
of
community
members
doing
it
as
well.
Okay,
okay.
E
C
I
will
I
I
think,
probably
in,
for
the
most
part,
we
should
stick
to
the
three-phase
process
for
feature
gates,
but
there
are
possibly
situations
where
it
makes
sense
to
jump
straight
to
phase
two.
This
could
be
one
of
them
where
phase
one
would
simply
be
a
warning
and
the
feature
gate
wouldn't
do
anything
because
nobody's
ever
going
to
choose
to
turn
it
on.
D
F
Yeah,
I
just
added
another
item
not
not
for
discussion,
but
just
to
call
out
that
we
are
planning.
F
There
really
is
a
1.0
for
model
p
data
sooner
and
we
have
a
milestone
for
that
and
there
are
several
issues
identified
if
you,
if
you
think
about
some
any
issues
that
needs
to
be
addressed
before
that,
please
add
them
to
the
milestone.
Also,
I
had
two
small
issues
that
kind
of
need
discussion
before
proceeding,
because
it
requires
some
breaking
changes
and
that's
mostly
from
my
side.
A
F
I
added
them
to
the
agenda.
A
Think
we
have
a
decision
to
be
made
also
for
for
the.
How
do
we
handle
experimental
types?
Four
segments.
F
F
This
was
still
pending.
Yes,
so
until
we
agree
on
whether
we
want
to
proceed
with
splitting
all
the
telemetry
data
through
the
whole
collector.
Are
we
okay
with
splitting
p
data,
at
least
to.
F
Solve
the
like
requirements
for
for
the
clients
that
use
only
data,
at
least
for
them,
and
then
we
decide
whether
we
go
splitting
other
companies
or
not.
I
think
bogdan,
we.
What
do
you
think?
It's
mostly
your
concerned
that
we
cannot.
We
shouldn't
split
it
right
away.
D
I
mean
there
were
multiple
arguments
and
discussions
related
to
this
one
was
like
p.
Data
is
very
important
and
we
may
do
this
split
only
for
p
data
and
module
and
not
for
everything
else,
because
that
will
create
a
chaos
and
it
will
be
very
hard.
D
D
D
F
Yeah
and
one
for
the
common
make
sense.
Okay,
if
anyone
agrees,
I
I
think
we
can
make
that
issue
actionable
and
proceed
with
the
split
in
a
backward
compatible
way.
Well
I
mean
you
will
not
be
that
backwards
compatible.
D
Within
the
issue,
yeah,
is
it
like
if
I
have
a
package
in
a
module,
and
I
separate
that
in
a
separate
module,
is
that
a
breaking
change.
C
Sorry,
if
you
don't
change
the
import
path,
it
shouldn't
be
a
breaking
change
right
because.
A
D
C
It
seems
like
what
dimitri
was
suggesting,
though,
was
creating
new
modules
and
new
packages,
with
the
signal,
major
structure
that
would
live
alongside
the
current
unified
structure
and
that
unified
structure
would
be
deprecated
and
replaced
with
usage
of
the
new
signal
major
structure
over
time.
I.
D
C
A
So,
what's
the
plan,
we,
we
add
four
new
modules.
I
think
I
think
I
think
in
common
yeah
per
signal,
and
these
are
new
net
new
modules,
with
new
paths,
new
import
paths
as
well.
That's
what
the
the
existing
implementation
becomes,
an
alias
for
that
the
existing
p
data
imports,
those
modules
all
four
and
the
types
and
then
all
the
declarations
become
aliases
for
for
the
new
ones,
yeah.
D
We
should
allow
us
if
we
have
to
split
or
or
to
to
to
do
a
okay
if
we
have
to
do
a
split
of
a
module,
a
package
to
a
module.
I
think
at
this
point
we
should
allow
us
to
do
that
and
don't
consider
that
a
breaking
change
at
this
moment,
I'm
not
sure
if
we
need
it
or
not,
but
I
think
we
should
agree
that
that's
acceptable.
D
D
Yeah,
that's
that's
exactly
what
we
we
agreed
to
do
right.
What
I'm
trying
to
say
is
if
we
have
to
split
a
module
at
this
point,
do
we
all
agree
that
it's
acceptable
and
not
have
to
follow
any
other
process?
No
follow
the
existing
process
right.
What
we,
what
we
already
have
again,
not
for
this
case,
I'm
asking
a
separate
question:
if
we
have
to
separate
a
package
into
its
own
module
without
changing
support.
C
Oh
yeah,
yes,
if
we're
not
changing
import
pass,
if
everything
is
staying
in
the
same
locations,
yes,
okay,
I
I
don't.
I
don't
think
that
that's
a
breaking
change,
that's
something
that
the
go
tooling
should
automatically
pick
up
when
you
run
tidy
or
go
get
and
and
will
not
break
things
around.
Yes,
that's.
D
C
Sorry,
what
I
was
saying
no
to
was
moving
modules,
which
is
what
it
sounded
like.
You
were
saying,
if
I'm
understanding
you
correctly
now
that
you
are
saying
we
should
consider
taking
what
was
one
module
with
multiple
packages
and
splitting
that
into
multiple
modules,
with
the
same
package,
import
paths
that
I
don't
believe
is
a
breaking
change.
F
A
A
F
C
A
D
D
I
don't
know
that's
what
I
was
asking
if
we
name
them,
tracy's,
metrics,
logs
or
trace
metric
log
also
go
is
against
using
the
plural,
so
you
have
to
name
them
trace
metric
log.
Probably
to
follow
the
go
rules
you
may
have
lots
of.
As
I
said,
linter
errors,
because
you
you
don't,
you
are
not
allowed
to
start
with
the
the
same
prefix.
C
I
think
there's
also
some
consideration
to
be
had
for
whether
trace
metric
and
log
would
be
the
best
names,
given
that
it's
likely
that
those
package
names
are
in
use
elsewhere.
We
ran
into
this
with
the
the
go
sdk
and
api
where
we
had.
You
know
api
trace
and
sdk
trace,
and
occasionally
they
have
to
be
pulled
into
the
same
file,
and
one
of
them
then
requires
a
name
conflict
like
I
just
saw
someone
put
in
chat
like
p,
trace,
p
metric,
p
log.
That
could
be
a
way
around
that.
C
D
D
D
The
plural,
first
of
all
p
trace
is
not
p.
Traces
is
not
plural.
The
the
right.
The
reason
why
I
like
traces
is
because
it
matches
with
the
paths
for
for
like
v1,
traces
and
v1
metrics,
that
we
have
for
http
and
for
for
all
the
things
kind
of
like
p
traces
is
the
data
associated
with
the
slash
traces
path
of
the
the
endpoint,
because
that's
how
we
call
it
v1,
we
don't
call
v1
trace.
We
call
v1
traces
in
the
in
the
http
protocols,
for
example,.
F
Yeah,
I
I
I'll
I'll,
try
it
out
and
we'll
see.
A
We
want
to
discuss
the
two
piers,
the
two
issues
that
dimitri
had.