►
From YouTube: 2021-01-07 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).
C
C
B
So
actually,
maybe
before
we
get
started
with
real
things,
I
have
sort
of
a
random
question
because
I'm
trying
to
implement
the
exporter
bridge
yeah
go
ahead
and
I'm
I'm
still
getting
used
to
the
like
aggregator
and
checkpoint
and
all
those
those
interfaces
is.
Is
there
a
simple
way
that
you
know
off
the
top
of
your
head?
B
If
I
just
want
to
create
an
aggregator,
that's
got
a
bunch
of
data
to
do
it,
because
it
seems
like
the
interfaces
for
like
last
value
or
whatever
they're
all
designed
to
be
sort
of
accumulated
over
time,
not
really
designed
for
someone
to
say
hey
by
the
way.
Plop.
Here's
a
whole
bunch
of
numbers
that
you
should
act
as
if
you
collect
over
time.
Does
that
make
sense.
A
Yeah,
I
think
so,
there's
josh
has
the
pr
right
now
to
refactor
the
array
type
that
might
be,
I
think
relevant.
He
wanted
to
store
it
as
points
and
those
points
are
just
going
to
be
timestamped
data
points.
Oh.
A
It's
it's
one
of
those
ones.
I've
made
it
through
like
three
quarters
of
it
twice
now,
I'm
trying
to
review
it.
It's
a
it's
a
good
one,
but
it's
just
it's
tough
to
find
the
time.
Sometimes.
Is
this
the.
B
A
Yeah,
oh
actually,
I
didn't
finish
this
review.
A
Yeah,
okay,
yeah
yeah,
if
you
don't
mind,
want
to
take
a
look
at
this
review.
I
think
that'd
probably
be
helpful.
I
think
this
is
probably
what
you're
looking
for
anyway.
So
it'd
be
a
good
thing
to
to
dive
into.
A
Yeah
cool,
okay,
I
guess
with
that
we
can
kind
of
just
kind
of
jump
into
things.
I
don't
know
if
there's
gonna
be
too
much
to
talk
about
this
week.
I've
put
a
few
things
on
anthony
put
something
on,
but
I
think
that
it's
already
been
addressed.
So
if
you
are
on
the
call,
please
make
sure
that
you
sign
in,
and
we
just
start
chugging
through
the
agenda
here
so
anthony.
I
noticed
he
put
on
the
github
ci
stuff.
I
don't
know
if
we
wanted
to
talk
anymore
about
that.
A
Just
kind
of
make
a
general
statement
that
the
ci
for
projects
has
been
switched
over
to
the
github
actions.
Currently,
it's
just
running
github
actions.
It
used
to
also
be
running
circleci,
but
we've
disabled
that
at
this
point,.
A
I
don't
know
if
there's
any
more
cleanup
well,
I
did
find
one
more
cleanup
thing
to
do.
Somebody
posted
a
pr
to
update
the
documentation
badge
that
we
need
to
switch
over,
but
other
than
that.
I
think
that's
probably
about
it.
C
Yeah-
and
I
emerged
that
just
before
this
call
so
yeah-
I
think
this
is
taken
care
of
we've
swapped
over
from
circleci
to
get
up
actions
and
changed
all
the
branch
protection
requirements.
So
everything
should
be
good,
but
as
with
any
change
of
this
or
keep
an
eye
out,
if
you
notice
something
wonky,
let
someone
know
yeah
absolutely
cool.
A
Let's
move
on
to
the
next
thing:
josh
kind
of
talked
about
kind
of.
I
see,
there's
a
josh
on
the
call,
but
I
don't
think
that's
josh
mcdonald.
C
A
Okay,
cool
thanks
yeah.
I
wasn't
paying
attention
we
kind
of
touched
base.
I
think
it
was
in
the
maintainers
meeting,
or
maybe
it
was
the
spec
meeting
this
week
about
maybe
having
a
specialized
sub
team
for
the
metrics
side
of
things,
the
goal
here
being
the
go
implementation
of
the
metrics
sdk
and
I
guess
the
api,
as
well
as
a
reference
implementation
that
is
used
for
building
out
the
specification.
So
it's
useful
to
have
that
move
at
somewhat
of
a
more
rapid
pace.
A
I
guess
and
right
now,
like
there's
a
lot
of
well,
I
I
know
personally,
I'm
more
focused
on
trying
to
get
the
tracing
side
of
the
house
resources
and
other
things
that
are
stable
in
the
specification
to
a
stable
state,
so
we
can
get
to
a
g8
state
and
go
when
when
possible
or
when,
when
we
feel
ready-
and
so
I
think,
there's
a
good
idea
to
try
to
have
some
some
people
more
dedicated
to
the
metric
side
of
things.
A
I
know
people
external
to
the
go
repo
itself
or
have
also
expressed
interest,
mainly
bogdan,
and
probably
some
more
other
people
wanted
to
get
involved
there,
and
so
the
idea
was
to
have
maybe
a
metric
specific
maintainer,
so
they
can
merge
things.
That
being
said,
I
did
notice
that
josh
actually
has
merge
rights,
given
the
fact
he
has,
I
think,
he's
on
the
tc.
I
feel
bad
that
I
don't
know
this
outright.
A
I
know
he
was
proposed
to
be
on
the
tc,
so
I
think
he
has
merge
rights,
so
it
may
not
be
really
too
much
of
an
issue,
but
just
wanted
to
run
it
by
the
group
and
see
if
anybody
had
any
other
thoughts
on
it.
C
D
Hi,
I'm
here
now
sorry
about
that.
I
did
actually
merge
one
pr.
I
have
joined
the
tc
and
I've
been
sitting
on
this
power
for
a
few
months
and
wondered
if
I
should
start
using
it.
I
don't
know
there
seems
to
be
a
kind
of
velocity
problem
and
I
absolutely
understand
putting
priority
on
tracing.
So
I
can't
complain
here,
I
think,
getting
bowden's
reviews
and
counting
like
a.
D
I
think
it
would
help
us
get
done
faster
if
we
could
have
a
separate
sort
of
maintainer
role
and
account
approvers
from
the
from
outside
the
go
approver
ship.
But
I
don't
know,
I'm
not
sure
it
matters
that
much
yeah,
the
pr
that
I
saw.
You
go
go
over
where
I've
clearly
mixed
together,
some
stuff,
but
it's
like
all
kind
of
dead
code
like
shuffling,
and
that
was
one
where
I
just
felt
like.
D
I've
got
this
pr
that
just
shuffles
some
dead
code
around
it's
gonna
take
three
weeks
and
six
approvers
work
to
do
it
and
it
seems
like
we've,
somehow
gotten
into
a
position
where
we
can't
prototype
anymore,
or
at
least
not
rapidly
enough
any
case
that
this
pr.
I
it's
sloppy.
I
I
know,
and
now
now
that
I've
written
it.
D
I
can
go
back
and
write
it
through
three
parts
and
that-
and
I
I
can-
but
I
have
this
feeling-
that
if
open
telemetry's,
metrics
project
is
stalled
a
bit-
and
I
intend
to
talk
about
this-
and
you
know
next
week
and
in
the
next
meeting
hour,
I
feel
that
we
should
have
the
people
who
are
who
have
been
developing
this
project
for
a
year.
Be
writing
specs,
not
code
at
this
point,
so
I
really
just
wanted
to
kind
of
like
erase
that
code.
A
Yeah,
I
think
those
are
all
pretty
valid
concerns
there.
I
definitely
noticed
a
little
bit
of
a
slowdown
as
well.
I
attributed
it
a
little
bit
to
the
end
of
the
year
holidays,
but
yeah.
I
think
that
we
could
probably
try
to
maybe
iteratively
approach
this.
I
like
the
idea
of
maybe
on
a
first
draft.
We
can
try
to
have
anthony
and
myself
merge
things
at
a
little
bit
of
a
faster
clip.
A
Obviously,
it's
going
to
be
a
little
bit
of
a
specialized
thing,
because
we
don't
have
the
metric
spec
approvers
listed
as
approvers
here
for
the
metrics
directory,
which
we
could
also
change.
These
are
some
things
that
we
can
address.
I
think
that
also
as
a
stop
gap,
if
you
know
things
do
get
bogged
down,
having
josh
with
the
rights
to
actually
merge,
this
is
it.
A
In
my
opinion,
it's
a
fine
backup.
I
do
remember
the
days
when
it
was
primarily
just
josh
myself.
Making
things
happen
in
this
repo
and
it
did
go
fast.
There
were
a
lot
of
bugs
that
were
introduced
and
things
that
we
regressed,
but,
like
you
know,
I
also
appreciate
that
we
did
have
some
velocity
then
as
well,
but
yeah.
I
think
that
I
think
we
have
a
very
similar
perspective
on
that.
D
The
other
thing,
though,
is
that
it
seems
like
we're
we're
going
to
have
for
versioning
instability
reasons
we're
going
to
have
to
split
apart
the
metrics
sdk
a
little
bit
more
firmly
from
the
trace
sdk
and
that's
going
to
be
a
lot
of
work
as
well,
and
I
fear
that
it's
just
getting
in
the
way
of
trace
to
have
this
large
metrics
apparatus,
be
you
know
months
behind
at
this
point,
so
I
don't
know,
I
don't
know
how
to
help,
but
it's
becoming
more
urgent.
I
think.
A
Yeah
I
I
kind
of
got
that
sense
that
it's
becoming
more
urgent.
I
think
I'm
a
little
bit
more
optimistic
in
the
fact
that,
like
I'm
hoping
it
should
pick
up
in
the
next
few
weeks
going
forward.
I
know
there's
also
a
lot
of
internal
work
to
a
lot
of
companies,
so
people
are
prioritizing
things
with
the
new
year,
and
so
I
I'm
hoping.
C
A
This
next
month,
we're
going
to
see
a
little
bit
more
of
a
ramp
up
as
of
engagement.
I
I
know
personally,
that's
kind
of
what
I'm
my
goal
is-
is
to
try
to
sink
a
little
bit
more
time
into
hotel
coming
up
in
this
next
month,
but
yeah.
I
think
that
we
should
probably,
like
I
was
saying
like
maybe
each
week,
have
a
status
update
and
see
if
we
need
to
adjust
this.
This
policy,
or
this
approach
here
sounds
good.
C
And
the
the
coupling
of
the
metrics,
sdk
and
trace
sdk
is
kind
of
an
interesting
topic
for
us
in
terms
of
how
we
manage
releases
and
versioning,
because
I
think
right
now,
everything
is
in
lockstep
and
we
don't
really
have
the
tooling
to
move
independently
on
traces
or
metrics.
So
that
might
be
an
area
where
a
little
bit
of
time
tool
sharpening
could
help
us
be
able
to
move
faster
on
metrics,
with
less
fear
that
will
impact
tracing.
E
Could
you
could
you
explain?
This
is
puenya
from
google?
I
don't.
I
don't
think
I've
met
some
of
the
people
here
before
hello,
nice
to
meet.
Everyone
could.
Could
someone
maybe
spend
like
a
minute
educating
me
on
what
such
tooling
could
look
like.
My
impression
was
that,
if
they're
in
the
same
repository
that
they
are
versioned
together,.
C
Not
necessarily
we're
reversing
through
go
modules
and
we've
got
separate
modules
for
the
api,
the
sdk,
I
believe
we
do.
We
have
just
the
sdk
as
a
module.
We
could
split
sdk
trace
and
sdk
metrics
as
separate
modules
as
well,
and
each
of
those
modules
can
be
versioned
independently
right
now,
our
release
tooling
just
bumps
every
module.
In
a
repository
to
the
same
version.
C
A
Yeah,
but
around
the
tooling
side
of
things
anthony,
I
think
that's
a
really
good
idea.
I
think
there's
some
not
glamorous
work.
If
I'm
gonna
be
honest,
that
needs
to
probably
be
done
in
the
repo
that
I
I'm
hoping
to
try
to
address
in
this
interim.
It's
a
little
tough
trying
to
balance
that
and
trying
to
get
some
actual
implementation
in
the
libraries
done
as
well,
but
I
think
that
you're
right,
I
think
some
of
that
tooling
stuff-
could
could
be
a
very
useful
thing.
A
Another
thing
that
came
to
mind
is
some
of
the
documentation
stuff,
some
of
the
proto
stuff.
I
wanted
to
talk
a
little
bit
about
further
down
and
just
generalized
classification
of
certain
bugs
that
kind
of
thing
and
resolution
of
bugs
there's
a
few
handfuls
of
bugs
that
I
really
think
need
to
be
addressed,
hopefully
sooner
rather
than
later,
they're
just
kind
of
things
that
are
in
the
way,
but
yeah.
E
C
A
D
A
A
Okay,
I
think
that
sounds
good
yeah,
like
I
said,
like
let's
check
in
again
next
week
and
see
if
we
can
make
this
even
even
better,
and
if
you
have
time
in
cycles,
please
definitely
take
a
look
at
the
open
pr's
and
you
have
interest
in
the
metric
specification.
Take
a
look
at
the
open
pr's.
I
think
they're
pretty
useful.
A
You
heard,
but
david
has
committed
to
reviewing
that
pr
now
because
he
needs
it.
So
you
have
another
reviewer.
D
D
Like
I
guess
it's
the
whole
end
to
end
thing
basically,
is
that
I
have
this
context,
switch
to
go,
make
a
change
in
the
code
and
then
I'll
send
out
a
review
and
then
a
week
later
I'll
come
back
to
it
because
of
waiting,
and
then
I
can't
remember
what
I
was
doing
and
then
I
have
to
do
it
again.
A
Yeah,
I
think
I
think,
for
what
you
did.
I
would
keep
it
the
way
it
is
especially
with
two
reviewers
already
on
this
pr,
specifically,
I
think
that
that's
I
think
you
said
like
you
could
have
split
it
up.
I
think
that's
fine,
but
I
I
agree.
I
think
where
we're
at
right
now,
since
we
already
have
the
two
reviews
and
it's.
D
A
slippery
slope,
I
I
I
started
out
with
the
I'm
going
to
remove
quantile
and
then
all
the
things
that
fell
out
of
that
were
like
what
you
see
and
if
I
started
it
with
I'm,
going
to
delete
dd,
sketch
first
and
then
I'll
finish
that
operation
and
then
I'm
going
to
add
timestamp
support
and
exact,
because
if
you
don't
have
timestamp
well,
I
guess
they're
sort
of
independent,
but,
like
you
start
having
to
refactor
code
that
you
know
you're
going
to
delete
next
and
that's
that's
why,
anyway,
I
I
don't
know,
I
don't
know,
I
think
it
should
be
done
as
two
deletions
and
then
an
addition
or
whatever
I'll
do
it
I'll.
A
This
one
all
right,
I
think
you
got
it
yeah.
I
I
think
I
think
that
maybe,
if
we're
gonna
redo
this
and
we
had
a
time
machine,
we
could
do
it
differently,
but
I
think
that
the
way
it
is
right
now
is
perfect.
D
Here's
here's
my
only
final
thought:
there
is
there's
no
code
actually
using
the
exact
aggregator,
there's
no
exporter
that
actually
prints
those
points
at
the
moment
and
I
until
otlp
exports
raw
points.
I
don't
think
it
matters
much.
So
I
think
when
the
next
step
will
be
to
add
raw
points
or
something
like
that
and
then
we're
gonna
get
testing
on
it
more
testing
and
more
eyeballs
once
it's
actually
used.
I
guess.
A
So
good
news,
the
reason
david
was
interested
in
this
is
because
of
that
I
think
he's
also
looking
in
the
exporter
bridge
to
be
using
the
raw
points.
D
I
should
also
preview
you
all,
then,
is
that
the
reason
I
was
writing,
like
a
bunch
of
pr's
over
the
break,
was
that
I
had
some
time,
but
also
that
my
goal
was
to
get
to
the
end
of
the
histogram
project,
which
has
been
ongoing
forever
and
then,
but
connected
with
that.
I
was
sort
of
just
reviewing
all
the
items
that
I
think
of
were
sort
of
included
in
scope
for
the
kind
of
1.0
of
the
one
of
the
kind
of
what
was
open
census
trying
to
get
we.
Never.
We
can't
do
it
all.
D
Honestly,
the
views
is
the
one.
That's
like
the
giant
piece,
that's
left,
but
the
thing
that
open
senses
had
for
for
histograms
that
we
don't
yet
in
this
repo
is
exemplars
and
we
got
the
proto
added
over
the
summer
and
it
was
prototyped
in
python.
D
I
I
have
a
draft
pr
that
does
it
and
at
this
point
I'm
like
it
kind
of
depends
on
two
or
three
of
the
pr's
that
are
sitting
in
the
in
the
in
the
repo
right
now.
So
I
don't
want
to
show
it
to
you,
because
it
it'll
look
like
a
mess,
but
it's
pretty
close,
and
so
I
was
that
I
wanted
to
get
exemplars
finished
before
we
like
call
it
like
this
is
this
is
close
to
being
ready.
A
Yeah,
that's
helpful
and
understanding
that.
A
Cool
I'd
like
to
share
my
screen,
I
think
the
only
other
thing
by
the
way
for
people
joining
now
we
have
a
little
bit
of
filler
house.
If
you
had
issues
or
things
you
want
to
talk
about
the
agenda,
please
add
them
after
and
we
can
touch
on
them.
There's
only
a
few
more
I
kind
of
want
to
touch
on.
One
is
just
the
p1
issues
in
the
trace
area.
A
I
there's
this
top
clarified
package
demarcation
between
sdk
trace
and
the
export
trace
thing
that
was
brought
up
when
we
were
talking
about
the
read
only
and
the
root
write
span,
interface
that
we
recently
merged
and
wanted
to
kind
of
follow
up
on
this
I
know,
johannes
johannes,
from
kinvoke.
The
contract
with
new
relic
has
expired,
and
I
don't
know
if
we're
updating
it.
So
I'm
not
too
sure
if
he's
coming
back,
but
I'm
looking
to
pick
this
up.
A
I
think
it's
useful
and
I
think
it's
extremely
important
to
try
to
help
make
sure
this
is
done
before
we
make
the
next
release.
Hopefully
we
can
get
a
release
out
this
week
or
next
week.
Well,
it's
already
thursday.
Probably
next
week
that's
how
time
works,
but
I
wanted
to
kind
of
talk
a
little
bit
of
the
remaining
two
there's
too
many
trace
packages.
I'm
kind
of
feeling
like
we
can
just
close.
A
This
we've
gone
through
a
lot
of
iterations
and
package
restructuring,
and
I
think
that
initially,
when
we
talked
about
this
before
there
was
not
a
really
big
appetite
to
really
make
the
big
differences
I
had
said.
Maybe
we
could
try
to
do
something
similar
to
what
we
did
before
we
moved
the
api
around.
Although
the
api
then
moved
back
into
something
more
structured,
so
maybe
that's
not
the
case.
D
A
Okay,
yeah,
I
think
that's
good,
I'm
going
to
take
a
little
bit
more
of
a
look
at
the
export
trace
and
sdk
trace.
Obviously,
with
this
other
issue
that
I
was
looking
at,
but
otherwise
I
think
that's
probably
I
think
a
done
deal.
I
think
I
think
you're
right
and
what
you
just
said,
anthony.
A
Cool
and
then
there's
this
extremely
old
issue.
That
is
definitely
not
one
of
the
originals
192,
but
it's
still
a
good
one.
I
think
if
this
is
just
needs
somebody
to
own
this,
I
don't.
B
A
I
mean
josh
flashbacks
at
this
point
yeah
I
I
might
pick
this
up
next.
If
nobody
else
has
any
interest
in
it
but
yeah.
This
is
another
one
that
needs
a
he's.
A
Unless
seeing
a
hand
or
come
up
or
not,
I
understand.
D
D
Are
you
sampling
and
are
you
keeping
state
in
memory
straight
and
it's
just
really
hard
when
you
start,
you
start-
and
I
remember
having
to
implement
this
in
detail
back
at
the
google
c
plus
plus
code
base,
which
had
support
for
that
you
could,
you
could
start
attach,
you
could
start
recording
and
not
sample
or
you
could
sample
or
you
could.
It
was
very
flexible,
but
it
was
impossible
to
understand.
A
So
I
think,
if
I
do
pick
this
up
next,
the
goal
here
is
probably
just
to
make
sure,
given
the
fact
that
this
is
the
I
think,
the
related
issue
that
evan
you're
kind
of
talking
about,
and
it's
marked
as
released
after
ga,
there's
essentially
they're
punting
on
the
resolution
here.
So
I
think
we
just
need
to
make
sure
that
we're
in
a
position
that
we
can
also
punt
on
the
resolution,
whether
that
means
removing
the
option
or
whether
that
means
preserving
the
option.
I
think
it
just
needs
to
be
explored.
A
A
That's
yeah,
I
didn't
want
to
say,
because
I
don't
I
don't
know
for
definitively,
but
I
think
you're
right.
That
was
my
understanding.
D
So
until
there's
a
z
page,
I
don't
think
it
matters,
and
I
this
issue
I
will.
I
will
there's
a
hill
here
that
I'd
be
willing
to
like
really
fight
fight
on.
But
I
don't
care
enough,
because
people
are
focused
on
metrics
and
I
don't
need
to
to
fight
to
the
death
about
tracings.
A
Yeah
josh,
how
about
how
about
we
just
kind
of
circle
back
and
if
we
need
you
to
to
get
up
on
that
hill,
we'll
ask
you
then,
but
until
then
we'll
try
to
resolve
this
without
that
cool.
I
think
that
might
actually
be
all
the
issues
that
I
wanted
to
talk
about.
Oh.
A
This
has
opened
a
long
time
ago,
and
I've
had
no
action
on
it
two
months
ago.
This
is
to
resolve
our
generation
of
the
open.
Telemetry
l
doesn't
actually
stand
for
language
otlp
and
into
a
centralized
location.
I
just
wanted
to
like
kind
of
point
this
out.
It's
still
on
my
radar.
Obviously
I
don't
think
I'm
gonna
get
this
done
this
week,
but
this
would
be
really
cool.
I
know
josh
has
expressed
interest
because
we
need
a
centralized
placement,
like
both
the
exporter
and
some
sort
of
downstream
customer
can.
C
A
About
the
same
reference
package,
and
so
there's
not
conflicts
with
the
generated
protobuf,
I
do
think
that,
like
it
probably
should
include
people
from
the
collector
as
well
into
resolving
this
into
working
on
it.
But
I
don't
know
if
anybody
else
had
any
interest
in
this.
I
have
some
thoughts
as
to
how
to
structure
this
it'd
be
really
cool
if
it
contained
all
of
the
versions
of
the
protobuf,
not
just
the
latest,
so
that
people
do
have
some
backwards,
compatible
results
and
and
how
we
actually
want
to
generate.
A
E
Would
the
historical
version
styler
be
be
put
in
the
same
get
tree
or
would
you
imagine
addressing
those
via
via
get
tags,
because
you
know
the
google
module
mechanism
allows
that.
A
So
definitely,
I
think,
ultimately,
would
be
a
tag,
no
matter.
What
how
that
would
look
in
the
get
tree
is
an
interesting
question,
though,
whether
that
be
a
checked
out
branch
or
whether
that'd
be
a
sequential
history
in
like
the
trunk.
A
Like
that,
I
think
is
is
something
I
haven't
thought
through.
This
is
again,
I
think,
where
I'd
love,
to
have
more
discussion
on
it
with
people
that
are
interested
but
yeah.
I
do
think
that,
like
you
know
just
just
putting
the
latest
in
there,
I
was
realizing.
That's
probably
not
going
to
be
useful
for
people
that
are
on
old
versions
of
the
code
that
want
to
try
to
do
some
things
with
the
older
versions,
but
I
don't
know
how
how
useful
it
also
would
help
us
flex
our
muscles.
E
I
mean
since
I,
since
I
signed
up
to
work
on
on,
or
at
least
I
think
about
another
go
modern
versioning
thing:
I'd
love
to
I'd,
love
to
be
involved
in
this
one
too.
Okay,.
F
A
A
There
is,
if
I
remember
correctly,.
A
Issue
that
josh
was
talking
about
as
well,
and
then
this
was
related
to
this
new
repository,
and
this
is
where
this
conversation
stopped,
because
I
have
not
had
the
time
to
address
this.
Unfortunately,
so
yeah.
D
So
it
seems
like
there's
a
point
about
sharing
with
the
collector
there's
a
point
about
not
using
gogo,
because
it's
sort
of
deprecated
and
not
maintained
and
getting
on
to-
I
guess
the
latest
proto
buffs
and
then
having
a
versioning
strategy
on
top
of
it.
I
had,
I
confess
I
am
not
enough
of
an
expert
on
the
go
modules,
plus
the
semantic
versions,
plus
the
like
import
version
based
path,
import
stuff
which
all
is
related
to
each
other.
I
don't.
F
D
Yeah
I've
run
into
this
with
the
prometheus
codebase
which,
which
uses
which
doesn't
follow
the
go
guidelines,
but
it's
a
go
code
base,
since
the
prometheus
server
is
not
really
meant
to
be
used
as
a
library.
D
Most
people
don't
encounter
this
problem,
but
if
you're,
depending
on
the
prometheus
server
code
base,
which
some
of
us
do
you
end
up
like
having
to
like
they've,
broken
things
and
you
have
to
choose
a
sha
instead
of
a
tag
because
of
it,
and
so
I-
and
I
can't
really
explain
that
because
I
don't
understand
the
stuff
very
well,
but
because
they're
on
version
2.0,
they
need
to
put
a
slash
v2
in
their
path,
or
else
you
can't
correctly
go
mod
import
it
without
using
an
a
shot.
Essentially,
it's
it's
annoying.
C
You
don't
have
to
have
a
version,
a
major
version
specified
in
your
path,
but
for
anything
v2
and
beyond
to
satisfy
semantic
import,
versioning
and
ensure
that
you
can
have
v1
and
v2
and
v3
all
imported
in
the
same
package
and
have
different
paths.
You
need
for
the
major
version
somewhere
in
the
import.
C
A
Yep,
I
think
that
that's
correct,
well
cool.
I
don't
have
anything
else
on
the
agenda.
I
guess
I
can
stop
sharing.
If
anybody
else
has
something
they
wanted
to
bring
up.
Otherwise
we
can
break
take
a
half
hour
and
then
regroup
and
talk
in
the
metrics,
because
I
know
you're
all
gonna,
be
there.
A
Yeah,
oh
cool,
I'm
not
seeing
any
hands,
go
up!
Awesome
everyone!
Well
thanks
for
joining!
Also
thanks
for
coming
back
welcome
back
from
the
break,
I
forgot
to
start
off
by
saying
that
good
to
see
you
all
again.
Obviously
I
look
forward
to
collaborating
with
you
and
hopefully
we'll
pick
up
some
progress
in
the
next
next
month.
So
everyone
be
well
and
see
all
four
next
week.