►
From YouTube: 2022-08-10 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
A
B
So
we
are
10
minutes
already
in
the
hour.
I
think
we
can
get
started.
People
are
going
to
join
the
next
few
minutes
and.
B
Do
you
want
to
start
with
your
topic
item,
or
should
we
talk
about
versioning
for
field
releases?
First,.
C
Yeah
we
can
start
with
the
metrics
so
yeah
I
posted.
I
just
like
created
an
issue
with
the
metrics
discrepancy,
metric
name.
This
discrepancy
between
what
was
reported
by
open
sessions
at
1.113
and
open
sentences.
We
use
the
names
namespace
configuration
for
premises,
exporter
that
which
automatically
adds
like
hotel
call
prefix
to
all
the
metrics
exported
with
open
sensors,
but
we
don't
have
that
an
open,
telemetry
and
open
telemetry
doesn't
support
that.
As
far
as
I
know,
so,
the
question
is
like
just.
C
C
Actually,
if
we
want
to
keep
that
prefix,
we
would
probably
need
to
move
it
from
previous
export
as
a
namespace
and
put
it
like
as
a
prefix
for
all
the
metric
exporters
or
if
we
want
to
remove
it,
it's
going
to
be
a
breaking
change
for
all
the
collector
users
and
it's
going
to
be
pretty
much
complicated.
We
probably
need
to
like
run
this
through
fisher
gate
for
for
extended
period
of
time
yeah.
I
just
wanted
to
think
what
you
folks
think
about
it.
A
A
Sure
so,
actually
I'm
working
on
an
open,
telemetry
equivalent
for
the
prometheus
namespace.
It's
currently
a
what
is
it?
It's
a
spec
pr,
a
couple
spec
prs
and
it's
going
to
be
part
of
the
prometheus
spec
and
also
related
I'm
working
on
a
migration
guide
for
open
census
to
open
telemetry.
It's
currently
an
otep.
So
ideally,
this
case
is
actually
really
easy,
but
I
understand
that
it's
not
right
now.
A
Yes,
it
would
be
a
an
attribute
on
the
scope
that
specifies
a
short
name
for
the
scope
name,
and
that
would
be
appended
as
a
prefix
in
prometheus
export.
C
I
said
okay,
another
thing
I
was
this.
This
is
just
like
this,
not
an
issue
or
something
to
just
my
my
store.
C
We
have
permissions
exporter
as
a
default
way
to
expose
open,
telemetry
metric
than
itself
right,
but
I'm
like
first
at
least
one
drawback
I
see
is
that
prometheus.
Like
replaces
all
the
dots
and
the
slashes
with
the
underscores,
and
it's
not
really
doesn't
look
like
open
telemetry,
specific
specification
compatible
names.
C
So
I
was
thinking
if
we
have
to
stick
to
open
dilemma
prometheus
to
export
the
metric,
or
we
can
have
an
option
to
export
them
in
no
glp
format
and
send
to
collector
itself
instead.
So
it's
like
just
as
another
option.
In
that
case,
we
can
have
like
more
standardized
like
metric
names,
as
as
other
metric
in
the
specification.
C
A
B
C
Yeah,
I'm
not
saying
we
should
we
we
remove
promises,
export.
We
I'm
saying
that
we
have
like
for
configuration
additional
configuration
to
send
to
glp
metric
to
the
collector
itself,
and
potentially
we
can
also
have
an
option
to
disable
open,
telemetry
and
use
support.
Glp
otlp
exporter
is
the
only
way
to
export
the
metric,
but
this
is
like
optional
way.
I
I
agree
that
default
configuration
should
be
prometheus
anyway
and
now
only
one,
but
I'm
thinking
if
it's
if
it
makes
sense
to
have
another
option
to
support
atlp.
B
Did
discuss
that
in
the
past?
When
did
we
talk
about
that?
B
B
Perhaps
a
collector
can
report
its
data
to
an
external
process
to
an
external
collector
instead
of
exporting
to
itself
or
it
can
export
to
itself
to
a
specific
pipeline
and
so
on
so
forth.
I
think
there
was
a
discussion
about
that.
So
perhaps
I
don't
know.
B
C
Okay,
yeah
by
another
option
for
a
jlpx
exporter,
I
mean
that
is
not
only
like
open
telemetry
collector
itself,
so
it
will
be
like
agility.
Endpoint
configuration
something
like
that
when
you
specify
like
localhost
and
the
glp
port-
and
that
case
it
reports
to
itself,
but
you
can
specify
anything
else
as
well
right
so
yeah,
I'm
just
I'm
bringing
this
up
just
to,
because
it's
related
to
this
issue
right.
If
we
standardize
on
namespace
with
the
permissions
export,
it's
not
gonna
work
for
any
any
other
exporters
right.
A
C
Yeah,
that's
instead
of
underscores
is
fine,
because
that's
probably
better
so
we
it
will
be
like
underscores
and
prometheus
and
dots
and
hotel
p,
and
it's
pretty
clear
right,
but
prefix
will
need
to
be
at
least
somehow
configured
another
exporter
which
I
don't
think
possible
right.
C
C
Okay,
see
so
yeah,
it
will
be
a
bit
more
a
little
bit
more
different
than
promisius
exporter
currently
has
right,
and
I'm
not
sure
if
we
I
would
personally,
I
would
prefer,
have
the
same
name
so
also
like
if
we
stick
with
the
ideal
call
as
a
prefix
or
namespace
for
prometheus
call,
it
like
why.
Why
can't
we
have
like
a
name
jlp,
the
same
similar
format
at
lp.
A
It
just
doesn't
look
very
open
telemetry-esque.
Does
it
okay,
yeah
but
yeah?
I
don't.
I
don't
think,
there's
a
right
answer.
C
Yeah,
we'll
probably
need
to
think
about
it
more
and
maybe
submit
this
back
for
up
in
telemetry
collector
metric
themselves
before
doing
something
like
that
right
and
we
ignore
wherever
we
have
no
promises.
I
don't
know
it
would
be
nice
to
have
them
at
least
like
similar.
Somehow.
C
By
the
way,
it's
called
a
scope
attribute
that
doesn't
mean
that
it's
like
instrumentation
library
or
something
like
that.
So
it's
not
really
something
that
metrics
are
coming
from,
and
in
this
case
I
believe,
if
we
are
reported
from
collector,
it's
more
like
a
resource
attribute,
because
it's
not
like
collector
doing
some
scraping
as
an
instrumentation
library
or
as
a
scope.
It's
more
like
collector
as
a
resource
report
measuring
about
itself.
A
A
C
B
C
Yeah
there
are
some
blockers,
I
believe
it's
not
possible.
Actually,
the
first
fall
is
broken.
If
you
just
enable
the
feature
gate
for
open
telemetry,
it
doesn't
work
like
no
matrix
report.
There
is
a
buffer
issue
for
that.
C
C
Yeah
and
I
believe
we
cannot
report
both
to
the
same
promises
exporter.
This
is
an
issue
and
goes
decade
that
david
submitted
while
ago,
so
that
probably
is
a
blocker.
B
C
B
Okay,
yeah,
there
was,
let
me
take
a
look
here.
I
think
that
a
keyword,
so
it's
the
4198.
B
Anyway,
yeah,
so
what
I
wanted
to
when
I,
when
I
started
converting
from
open
sensors
to
open
telemetry
for
some
of
my
components,
that's
one
of
the
problems
that
I
came
across
is
that
open
time
to
sdk
would
not
allow
would
allow
us
to
specify
different
boundaries
for
histograms,
for
different
metrics
or
for
different
yeah
metric
names.
B
They
are
very
different
than
the
ones
for
I
don't
know
for
for
things
that
take
0
to
100,
for
instance,.
B
And
that
was
the
blocker
that
I
had
as
part
of
the
41.98.
Let
me
copy
the
link
here.
C
B
All
right,
so
then
we
have
this
question
on
so
anything
else
for
on
this
topic
here,
david
any
one,
two
three.
B
All
right,
so
we
had
last
week
we
had
a
new
release,
057
and
I
messed
up
twice
so
not
only
not
once
but
twice,
and
which
means
that
I
I
had
to
make
a
057.2
for
the
core.
B
0-570-
and
we
have
two
different
opinions
here,
so
the
first
one
is
everything
should
follow
core
or
if
core
fails
and
everything
coming
after.
That
should
follow
that,
so
that
we
have
less
confusion
on
users
when
they
look
for
a
binary
for
the
core
0572
all
right.
So
we
we've
had
this
case
before
where
we
had.
B
B
So
that's
that
was
my
reasoning
on
provide
on
on
producing
a
dot
too,
for
contributing
for
for
the
binaries,
for
the
images
and
so
on,
but
that
confused
other
maintainers
and
other
maintenance
would
have
preferred
a
dot,
zero
contrib
and
a
dot,
zero
binary
and
images.
B
So
I
guess
the
first
question
is:
what
do
we
think
is
best
as
a
group,
so
not
not
only
my
opinion
or
individual
maintaining
opinions,
but
what
are
your
opinions
on
on?
What
is
the
best
approach
for
that?
I
guess
that's.
The
first
question:
that's
a
good
question.
We
can
ask
later.
C
I
would
personally
prefer
zero,
like
do
not
don't
have
this
strict
dependency
on
the
patch
version.
First,
I
believe
that
I'm
I
can
run,
but
I
believe
it
caused
issues
with
the
goal.
Dependency
like
go
go
itself
looks
for
dependency
on
the
the
mind,
major
minor
version
and
so
on,
and
I
believe
recently
we
had
some
plutocrats
from
bogdan
and
was
like
he
tried
to
update
core
and
then
screw
up
everything.
So
I'm
not
sure
about
that.
C
But
it
looks
like
this
is
pretty
valid
concern
and
by
my
personal
opinion,
doesn't
rely
on.
That,
doesn't
depend
on
that.
I
just
think
that
it
doesn't
make
sense
to
align
on
the
patch
version,
because
we
can
always
have
some
problems
here
and
there
we
might
have
like
core
stable,
like
zero,
757
zero.
We
rule
this
country,
but
and
at
some
point
we've
we've
found
a
pretty
like
significant
issue
in
countries
right,
one
of
the
companies
we
need
to.
C
We
need
to
release
a
patch
version,
but
it
doesn't
mean
that
we
have
to
do
the
same
punch
on
the
core
we
can.
We
can
rely,
we
can
still
depend
on
the
same
zero
patch
version
of
the
core
yeah.
That's
probably
my
my
opinion
also.
I
I
just
want
to
add
here
that
currently
we
have,
we
depend
on
the
git
tags
and
the
releases
which
I
don't
think
is
the
best
approach.
Maybe
we
can
just
have
a
like
completely
separated.
C
Git
tags
will
be
like
the
will
be
only
applicable
for
releases
repo
itself,
so
it
doesn't
do
anything
about
coral
and
trip
releases
and
we
will
have
automated
process
for
releasing
based
on
like
the
this.
Like
goal,
this
git
like
both
or
whatever
it
is
just
look
for
yaml
file
and
if
you
have
a
file
for
core
or
contrib,
is
updated
with
the
new
version
it
just
released
based
on
that,
and
it
will
be
like
separate
releases
completely
separate
from
google
tax.
C
D
I
kind
of
half
agree
with
you
and
half
disagree
with
you.
I'm
really
not
a
fan
of
a
release
file
as
opposed
to
git
tags.
That's
what
git
tags
are
for
and
when
you
like,
having
an
identified
like
hash,
which
you
then
have
to
change
in
order
to
at
you
know,
update
the
file
which
has
the
new
release
number
in
it,
which
changes
the
hash
which,
like
it,
there
are
many
more
opportunities
for
error.
D
In
my
view,
when
your
dependency
is
on
a
file
in
the
release,
rather
than
a
git
tag
which
exists
kind
of
outside
the
contents
of
the
repository.
So
I'm
not
in
favor
of
that,
but
I
am
kind
of
in
favor
of
the
allow
the
streams
to
diverge
and
just
make
sure
it's
reasonably
well
documented.
If
the
problem
is
that
people
are
saying
hey,
I
don't
see
the
release
for
this
thing.
D
B
I
guess
part
of
the
confusion
is
that
we
have
a
repository
that
we
call
core
and
there
is
a
distribution
called
core,
and
then
we
have
a
repository
called
contrib,
and
then
we
have
a
distribution
called
control
and
those
are
independent
things,
so
the
the
distribution
called
contrib
just
happens
to
have
all
of
the
or
most
of
the
components.
From
the
contrib
repository.
B
I
was
looking
at
the
history
of
our
calls
here
and
and
in
july
last
year
I
made
a
proposal
to
have
the
core
be
renamed
to
his
dash
api
and
contrib,
be
renamed
to
dash
components
so
that
we
so
that
the
api,
the
core
that
we
have
today,
would
be
only
the
api
for
people
to
build
distributions
of
the
open
entry,
collector
components
of
the
open,
telemetry
collector,
and
then
the
components
would
be
what
we
have
today,
plus
the
components
that
we
have
on
the
core
repository
like
the
hlp
receiver
and
an
exporter,
and
I
think
a
health
check
might
be
on
the
core,
the
pages
and
a
few
others.
B
B
No
yeah
just
wrapping
up,
you
know
it's
it's
just
that
making
this
distinction,
this
naming
distinction
and
making
it
clear
what
their
purposes
are,
would
make
it
clearer
to
users
that
the
core
distribution
is
not
the
api.
An
api
could
have
could
be
tagged
view
one
right
now
or
whenever
we
think
it's
it's
reasonable
and
have
contrib
follow,
is
zero
dot,
x
stream
for
a
longer
time
until
we
until
we
tag
it
to
a
view
one.
If
you
want
some
day.
C
I
I
think
we
still
can
have
in
religious
korean
country
right.
We
will
still
have
that
one,
but
what
if
they?
We
found
an
issue
in
one
of
the
companies
that
only
applicable
to
country
we
release
new
version
of
the
country
repository
right.
We
don't
touch
api
in
that
case
correct,
because
there
is
nothing.
A
B
A
C
Eight
twelve
and
the
core
has
zero
twelve,
that
one
as
a
patch
version
for
now
until
we
reach
out
one
something,
but
it
doesn't
mean
that
we
need
to
release
two
binaries
for
core
income
trip.
In
my
view,
it
doesn't
make
sense
to
release
patch
version
for
core
is
if
there
is
a
problem
in
the
component
from
contrib.
Only.
B
So
with
that
with
this
idea
in
mind
that
api
does
not
have
any
components
and
the
new
contrib,
so
this
the
dash
component
would
have
all
of
the
components
touching
the
the
old
contrib
would
mean
that
every
distribution
will
be
changed,
because
all
of
the
components
are
coming
from
the
the
contrib
from
the
current
entry
repository.
B
If
there
is
a
change
on
api
and
like
a
security
issue
that
we
need
to
to
provide
a,
we
need
to
rebuild
binaries
right
now.
The
same
I
mean
that
base
layer
affects
everything
that
we
built
on
top
of.
So
we
have
to
rebuild
everything.
C
C
I
believe
it's
pretty
standard
idea
like
this
is
what
patch
versions
for
right.
They
are
intended
to
patch
something
patch
some
fixes.
So
if
we
have
like
critical
political
back
and
one
of
the
companies
from
countries
only
should
we
release
korean
country,
my
idea
is,
is
that
we
shouldn't,
and
in
that
case
releases
based
on
git
tags,
doesn't
work,
because
that's
supposed
to
make
really
not
supposed
to
release
binary
for
all
distributions.
B
Not
well
if
we
have
those
three
repositories
that
is
independent
from
each
other,
so
dash
api,
dash
components
and
dash
releases,
then
releases
can
be
at
the
I
don't
know:
v57
contrib
can
be
at
the
87
and
api
can
be
at
view
1.0
right.
So
if
we
change
so,
if
we
have
a
problem
with
the
jager
exporter,
we
fix
it
there
and
we
release
08,
and
then
we
can
have
a
new
contrib
distribution
on
version
0.58.
B
C
So
you
suggested
that
we
diverge
on
the
country
preview
and
then
releases
as
well.
I
don't
believe
that
it's
best
for
users
because
they
like
to
look
for
first
question:
they
look
as
git
and
country
as
far
as
I
believe
I
think
that's
the
idea
and
they
go
to
releases
only
once
they
see
a
new
version
in
the
country.
C
B
Yeah
yeah,
so
we
can,
we
don't
have
to
so
we
can.
We
can
stay
on
the
same
versions
for
components
or
for
contrib
and
for
releases,
but
we
don't
actually
have
to
because
the
versions
they
are
set
on
the
manifest
files
so
on
the
yellow
files
within
those
within
the
distributions
within
the
releases.
C
Yeah
last
time
I
did
the
release,
it
was
actually
the
problem,
because
it's
like
it's
mixed,
you
cannot
have
it's
like
currently
as
far
as
as
I
understood
the
code
base,
it's
currently
not
supported
that
you
have
different
versions
for
current
contrib
and
different
git
tank,
and
seoul
has
to
be
aligned.
Guitar
has
to
be
aligned
with
core
and
with
country.
C
B
C
Go
ahead,
it's
just
like.
I
checked
that
it's
it
seems
like
git
ducks
are
not
being
used,
but
they're
actually
being
used
in
the
mag
file
a
lot
and
propagated
down
down
through
all
the
drop
down
through
the
whole
like
release
process
and
whatever
you
set
to
the
tag.
It
will
be
it
so
manifest
will
define
which
version
you
are
taking
from
from
quan
triple
from
core
but
actual
releases
that
are
built
by
releases
pro
really
from
in
releases
repo
by
the
process,
they're
all
based
on
git
tags.
C
C
A
B
Yeah,
but
I
don't
think
that's
how
it
works.
I
mean
it
is
at
least
from
from
the
distribution
perspective.
It
is
possible
to
have
a
release,
a
distribution
on
version
x
and
consuming
components
from
version
y.
C
C
I'm
starting
drop
you
it's
just
not
like
collector
video.
It's
just
github
actions
that
to
create
the
correlates
releases.
That
thing
that
thing
purely
relies
on
git
text.
B
Okay,
but
then
then
it's
probably
based
on
assumptions
that
I've
made
when
doing
that,
because
things
were
aligned
back
then,
and
if
that's
not
the
case
we
can
fix,
we
can
change
it.
I'm
I
mean.
C
Understand
your
idea:
how
how
would
it
should
work?
B
C
Actually,
to
be
honest,
I
don't
I
don't
see
any
problem
with
that
because,
like
all
the
helm
community,
you
uses
hell
manifest
to
create
the
releases
and
never
see
any
problems
with
that.
So
if
you
update
the
chart
for
a
chart,
the
ammo
file
you'll
get
the
release
right
after
that,
even
if
it's
like
not
tagged
or
whatever,
and
I
I
don't
know,
I
didn't
see
any
problems
with
that.
B
C
C
It's
just
a
github
action
that
targeted
towards
a
file
right
and
it
checks
like
file
version
written
in
that
file,
and
that's
it
so
this
says
so.
You
can
have
gita
github
action
attach
it
to
attack.
If
new
text
releases
do
something
you
can
do
the
same
investment
file,
if
that
file
change,
it
do
something.
C
B
A
B
You
get
okay,
I
see
now
I
see
I
I
I
don't
have.
I
don't
oppose
to
this
idea,
not
right
now.
At
least
I
mean
I
would
have
to
think
about
it.
C
Yeah,
at
least
it
will
solve
the
problem
that
we
don't
have
to
have
always
the
same
versions
released
at
the
same
time,
for
both
countries
and
code
and
we'll
might
have
other
versions
as
well
going
forward.
We
might
have
versions
that
are
like
released
on
the
like
different
schedule,
right,
something.
B
All
right,
so
I
guess
now
we
have
an
agreement
that
the
releases
or
versions
can
can
diverge
all
right,
any
any
opposing
voice
to
that
anyone
thinks
that
versions
should
remain
consistent.
B
And
what
up
so,
I
think
for
for
my
next
question.
It
would
have
been
nice
to
have
bulk
done,
just
pull
it
in
here.
B
No
oh
yeah,
booked
on
this
here.
So,
but
I'm
not
sure
if
you
got
the
part
where
we
discussed
again
this
idea
of
renaming
the
reports
to
api
and
components
so
core
becoming
api
contrib
becoming
components.
B
This
is
something
that
we
talked
last
year
in
july
and
now,
with
this
discussion
on
on
having
different
versions
of
of
the
repositories
and
so
on,
it
might
make
sense
to
revisit
that
topic.
B
E
A
E
B
Yeah,
I
think
yeah
for
the
core.
I
think
it's
fine
contrib,
as
far
as
I
remember
github
setup
sets
up
redirect
rules
for
renamed
ripples
automatically,
so
things
should
not
break
and
shoot
here
being
the
keyword
they
should
not
break
when
we
rename
repositories.
It
is
going
to
cause
us
headaches
at
first,
because
we
would
have
to
change
all
the
ci
scripts
and
everything
that
depends
that
uses
contrib
in
the
name
on
the
name
and
replace
that
with
components.
B
Yes,
if,
if
we
do
that,
if
we
name
one
as
api
or
or
make
it
clear
that
it's
only
an
api
and
if
we
rename
contrib
to
components,
then
I
as
a
user,
I
would
expect
all
of
the
components
reside
on
the
components
repository
including
otlp
exporter
and
receiver,
including
the
pages
including
extensions
in
general.
Yeah.
E
A
B
A
E
But
we
can't,
we
cannot
see
the
the
I
cannot
at
least
for
me.
I
cannot
see
the
changes,
how
that
will
affect
the
user
of
that
or
it's
much
easier
to
see
it
this
way.
Let's
put
this,
I
mean
yeah,
we
we,
we
harden
a
bit
our
job,
maybe
maybe
worth
it,
but
I
don't
know,
that's
I'm
trying
to
balance
the
things
here.
B
B
All
right,
so,
let's
I
guess
the
next
question
is:
when
are
we
planning
on
reducing
core
as
a
ga
core
view,
one,
because
that
sort
of
decision
would
have
to
happen
before
ga.
E
E
Only
if
we
change
the
import
path
right,
we
can
still
play
with
the
with
the
import
path
to
be
in
a
different
level.
If,
if
that's
what
you
want,
it's
the
import
path,
that
is
mattered
the
most,
I
think
that's
what.
E
Talking
talking
about
the
import,
the
otp
exporter
importer-
and
this
is
this-
may
be
a
good
exercise
to
start
with,
jurassic
is
maybe
the
artifacts
that
we
produce
as
part
of
the
api
or
whatever
the
api
artifacts
should
not
have
these
receivers
in
them,
so
we
should
split
by
module,
even
though
we
have
them
in
the
same
repo.
Let's
split
the
modules
separately,
first
extract
or
tlp
exporter
and
stuff.
E
If
you
want
into
a
separate
module
as
a
first
step
to
do
this,
it's
it's
no
matter
what,
even
if
we
move
it
or
not,
it's
you
need
to
extract
them
as
separate
modules,
because
you
in
the
new
components,
will
be
separated
modules.
So,
let's
start
with
separating
them
as
separate
modules,
all
these
components
that
we
still
have
in
core
for
whatever
reason
and
then
and
then
even
if
we
mark
some
of
the
things
1.0,
we
still
have
time
until
we
mark
these
components
1.0
to
decide
where
to
put
them.
E
A
E
Think
that
was
an
agreement
like
four
months
ago
back
when
dimitri
was
still
working
on
these.
So
I
think
I
think
we
should
start
with
that,
have
a
story
for
for
for
because
no
matter
what
we
want,
we're
not
going
to
be
able
to
1-0
the
entire
report.
So
we
have
to
have
more
granular
things
and
it's
a
good
start
of
doing
this.
E
Also,
I
think,
unfortunately,
alex
is
on
vacation,
but
he
mentions
something
about
the
goal:
workspaces
that
may
help
with
multiple
modules
and
stuff.
If
somebody
can
teach
me-
or
somebody
can
look
into
that
as
part
of
splitting
the
core
to
set
up
the
goal.
Workspaces
to
help
us
with
the
with
multiple
modules
would
be
amazing.
E
E
Somebody
should
own
that,
and
as
part
of
that,
that
look
into
the
workspaces
to
see
if
we
can
set
up
that
or
not.
B
All
right
after
after
so
besides
splitting,
how
far
are
we
from
from
ga
right
now.
E
P
data
we
have
like
six
or
seven
things.
It
was
last
year
when
I
checked
we're
very
close
on
the
p
data
stuff
and
the
configuration
wise
we
have
only
one.
So
I
think
I
cannot
give
you
for
the
entire
thing.
That's
why
splitting
I
think
it's
the
first
thing.
We
should
do
splitting
the
repo
and
then
track
one
by
one,
every
component
and
their
dependencies
and
stuff,
because
otherwise
we
will
fail.
B
E
That's
that's
those
are
first
and
then
we
should
also
split,
I
think,
from
the
main
directory.
Let
me
present,
but
somebody
should
own
this.
These
are
just
me
speaking
loud,
so
not
necessarily
be
the
right
thing,
but
I
was
thinking
we
should
have
a
package
for
consumer.
We
should
have
a
module
for
what
we
have
called
component:
the
model
module
for
config
module
for
conf
map
and
almost
a
module
for
everything
here.
Accession
doesn't
need
to
be
a
module,
because
everything
else
would
be
a
module
inside
and
stuff,
but
things
like
that.
B
What
is
the
added
complexity
that
we
are
going
to
have
here
besides
the
workspace
itself,
so
are
we
going
to
have
multiple
tags
for
them?
Each
one
of
those
would
have
their
own
versions.
E
B
This
is
a
go
repository
right
so
and
sorry
this
is
a
git
repository.
So
what
it
means
is
we
have
a
one
tag
and
it
applies
to
everything
in
that
repository.
We
just.
E
Selectively,
no,
no!
No!
No!
Look!
We
can
do
that
so
the
tags,
so
we
actually
already
do
this
so
see,
based
on
the
name
based
on
the
name
that
you
use
of
the
tag.
God
knows
that
this
tag
applies
to
the
same
code
directory.
E
It's
already
there,
so
we
do
that
in
contrib.
We
do
that
the
open
telemetry
go.
Does
that
thing?
So
so
you
you,
we
have
the
tools,
so
we
can
have
multiple
modules
in
the
same
report.
Very
easily
workspace
will
help
with
building.
So
the
problem
we
don't
have
very
good
thing
is
right.
Now
we
have
to
have
this
replace
statement
everywhere
because
of
the
the
fact
that
we
are
building
from
head,
but
the
goal
workspace
should
help
with
that
and
we
should
not
have
to
have
this
replacement.
E
That's
that's
the
part
that
we
are
missing
a
tool.
We,
we
have
a
small
tool
that
actually
adds
all
the
possible
replacements.
Just
it's
very
exhaustive
like
it
just
like
adds
with
no
smartness
adds
all
the
the
replacement
statements
just
to
be
safe,
but
I
don't
think
we
should
use
that
tool.
I
think
we
should
use
your
workspace
for
that
for
this
one.
B
Yeah
replaces
are
still
going
to
exist
on
go
workspace,
but
it's
centralized
in
one
file.
E
Something
like
that
yeah
and
you
don't
have
if
you
depend
on
depend
on
the
specific
dependency
in
the
same
repo.
You
don't
have
to
have
replacements
yes,
anyway,
yeah
whatever
it
is,
it
is
but
yeah.
So
I
think
we
should
do
this
and
I
think
we
should
have
more
granular
up
to
what
level
we
can
decide,
but
I
think
we
should
have
more
granular.
Okay,.
D
A
E
So
brian
thanks
so
much
maybe
we
should,
as
part
of
this
exercise,
whoever
is
going
to
be
the
owner
of
this.
Splitting
should
also
work
with
brian
to
set
up
the
new
the
tool
for
for
core
as
well
and
make
sure
that
everything
works
so
yeah.
E
What
I'm
proposing
first
is:
let's
start
with
having
all
these
tools
set
up,
because
that's
that's
critical
for
help.
We
already
have
four
modules,
so
the
tools
will
already
prove
themselves
that
we
are
working
and
everything
and
then
and
then
after
you,
after
you
are
done
with
the
tools,
come
up
with
a
proposal
that
these
are
the
modules
that
I
want
to
split.
We
agree
on
that
and
then
we
start
working
like
we
shouldn't
have
too
many
blocking
and
stuff
so.
E
Immediately,
you
have
a
lot
of
other
work.
Let's,
let's
jurassic
lead
this
I
I
can
give
you
tons
of
other
ones,
no
worries,
okay,.
A
C
A
Which
is
the
tooling
like
just
in
general,
the
makefile
runs
a
lot
of
different
targets
that
are
sort
of
module-aware
so
like.
If
you
run
go
test,
you
have
to
take.
E
E
A
E
Yeah
besides
that,
then
everything
else
is
set
up,
so
not
too
much
work
to
set
up
awesome
sounds
good,
so
yeah
so
yeah.
I
think
I
think,
dimitri
on
your
side.
I
think
you
should
focus
on
on
the
mo
the
milestone
to
get
the
model
1-0.
I
think
we
have
only
few
very
few
items.
So
if
you
have
three
cycles,
focus
on
that
so
limited
data
whatever
mod,
I
think
the
the
milestone
is
called
model,
because
that
was
the.
E
C
E
Also,
I
want
to
show
to
you
guys
a
couple
of
things
that
I'm
working
on
and
maybe
I'm
not
very
good
on
telling
you
what
we
are
doing
so
one
one.
One
main
issue
that
I'm
working
on
and
you
may
want
to
pay
attention.
Pablo
is
very
well
aware
about
this.
I'm
having
a
discussion
with
him,
but
here
is
I
shared
it
in
link
the
link
here
about
the
the.