►
From YouTube: Meshery Development Meeting (April 20th, 2022)
Description
Meshery Development Meeting - April 20th, 2022
Agenda -
- Troubleshooting Toolkit design spec. Spec
- Meshery Adapters spreadsheet - driving to uniformity. Ideally,
- MeshKit + Meshery Adapter Library as a mono repo?
- SMP dashboard design spec [link]
- Meshery extension point custom components
- Implement URL support for pattern delete.#5404
- changed minor bugs on MesheryPattern.js #5406
- Docker Extension for Meshery (Hub)
- Multi-arch support for adapters (Workflow example, Tags on Hub)
Volunteer needed to convert to reusable workflows.
Golang 1.17; GitHub Actions v3
Join the community at https://layer5.io/community
Find Meshery on:
GitHub: https://github.com/meshery
Twitter: https://twitter.com/mesheryio
LinkedIn: https://www.linkedin.com/showcase/meshery/
Docker Hub: https://hub.docker.com/u/layer5/
A
A
A
If
there's
anyone,
that's
on
the
call
that
hasn't
been
here
before
now's
your
chance
to
say
hi,
it
looks
like
everybody
is,
has
been
here
more
than
once,
which
means
that
if
you
any
of
you
have
a
topic,
please
call
it
out
and
let's
go
over
it.
Otherwise
drop
your
name
in
the
minutes
and
we'll
get
rolling.
So
uzeir
has
the
first
topic
user
isn't
on.
A
A
So
I
have
talked
to
uzera
about
this
a
couple
of
times
and
once
this
week,
just
catching
him
off
hours,
so
so
there's
a
design
spec
out
there
for
mashri
it's,
I
guess
the
spec
is
called
the
troubleshooting
toolkit.
I
suppose
it's
an
it's.
Well,
it's
something
of
an
acknowledgement
that
getting
kubernetes
up
getting
service
meshes
up,
getting
all
the
messy
components
up.
Sometimes
that
can
be
a
challenge.
In
the
past,
we've
had
a
connectivity
wizard.
A
So,
as
many
of
you
were
here
as
that
was
being
worked
on
this
connection
wizard,
which
was
when
you
first
pull
up
measuring,
it
would
have
just
this
a
stepper
that
you
would
go
through
to
make
sure
that
measuring
is
connected
to
kubernetes,
that
if
prometheus
and
grafana
were
in
the
environment,
it
was
connected
there,
and
so
it
was
just.
It
was
just
a
simple
wizard
that
would
step
people
step
users
through
making
sure
helping
them
guarantee
that
they
had
a
functional
environment.
A
A
This
is
the
docker
desktop
ui
and
you
know
there's
a
kind
of
a
couple
of
prominent
buttons
at
the
top.
One
of
them
is
this
debug
area.
This
is
the
docker
desktop
troubleshooting
toolkit.
If
you
will,
where
it's
the
the
the
place
where
you
go
to
squash
bugs
or
reset
the
factory
defaults
purge
the
database
reset
your
kubernetes
cluster,
like
it's
pretty
prominent
and-
and
this
is
a
pretty
great
piece
of
software.
A
So
maybe,
if
the
operator
didn't
get
installed
on
a
cluster,
or
maybe
they
don't
want
the
operator
installed
on
a
cluster
that
they
could
turn
it
on
or
off
or
re-provision
it
occasionally,
people
will
the
op
they'll
deploy
the
operator
which
will
in
turn
deploy
mesh
sync
and
mesh
rebroker,
and
it's
not
always
the
case
that
mesh
sync
or
the
broker
is
necessarily
available
over
the
network
between
where
mesh
reservoir
is
deployed
and
how
mesh
sync
and
nats
are
exposed
from
the
kubernetes
cluster.
Those
don't
always
get
exposed.
A
It
depends
upon
the
type
of
cluster
that
you're
running
and
the
type
of
network.
That's
networking
that's
going
on,
and
so
so
some
amount
of
tools
to
help
troubleshoot.
That
setup
can
be
helpful
and
that's
that's.
What
this
spec
is
kind
of
going
over
is
is
different
scenarios
where
people
may
have
challenges,
particularly
in
this
case
it's
around
probably
three
components
that
this
spec
talks
about.
So
it's
the
operator
mesh
sync,
the
broker.
A
A
Necessarily
the
the
crux
of
what
uzera
is
working
on
is
more
or
less
right
here
is
making
sure
that
there
are
switches
to
either
deploy
or
undeploy
the
operator,
the
mesh
sync
and
the
broker,
maybe
independently
the
ability
to
reset
mesh
reserver's
database
from
the
ui.
So
a
button
to
do
that
and
then
to
update
what
the
behavior
behind
these
two
chips,
in
particular
the
one
from
mesh.
A
A
Something
that
would
be
nice
in
time
is
well
is
when
users
are
on
the
dashboard.
If
they've
got
an
adapter
connected
they'll
get
some
amount
of
information
here
about
what
the
adapter
is,
what
port
it's
running
on
and
normally
like
what
version
is
running
so
in
the
parentheses
that
are
blank
right
now,
usually
that
it
would
be
reporting
the
version.
I
think
I
built
and
I'm
running,
that
adapter
locally,
so
it
may
not
be
reporting
it,
but
it's
that
type
of
tooling.
B
A
Yeah,
you
that's
a
great
for
my
part.
I
think
that's
a
great
thing
for
mesri
to
be
able
to
do,
and
it's
already
doing
that
for
any
number
of
other.
You
know
types
of
systems.
Why?
Wouldn't
it
be
capable
of
allowing
users
to
from
the
ui
switch
on
or
off?
You
know,
deploy
or
undeploy
an
adapter
right,
as
opposed
to
just
connecting
to
the
adapter.
A
B
A
A
A
The
underscore,
I
think,
probably
comes
from
the
smp
spec,
not
a
big
deal,
but
but
a
couple
of
the
adapters
are
missing
their
version
numbers.
So
this
is
a
good
note
for
anyone
maintaining
or
working
on
adapters.
There
should
be
uniformity
across
all
of
them
for
how
it
is
that
well,
they're
reporting
their
version
and
how
it
is
that
at
build
time
that
version
number
gets
baked
in,
would
anyone
mind
taking
a
opening
up
an
issue.
A
C
A
I
am
going
to
speak
to
it
from
an
unopinionated
perspective.
Hopefully,
but
the
circular
dependencies
are
something
to
be
avoided
and
they
might,
I
suspect,
part
of
how
those
come
about
might
be
a
lack
of
crisp
delineation
between
what
is
appropriate
to
go
into
the
adapter
library
versus
what
is
appropriate
to
go
into
mesh
kit
and
how
some
of
that
some
of
their
reuse
and
some
of
their
interchange
ends
up
overlapping,
like
yeah.
A
A
Based
on
like
not
just
having
a
single
monorepo,
like
which
I
guess
is
sort
of
obvious
from
the
extent
that
like
that's
what
a
dependency
is,
is
if
you're
reducing
the
number
of
repos,
then
you're
reducing
the
number
of
dependencies
and
some
of
the
complications
that
come
with
them.
So
here's
the
yeah.
A
I
guess
that,
like
here's,
a
big
challenge,
a
couple
of
challenges
around
there's
some
great
stuff
about
monorepos
and
also
not
I
don't
know
one
thing
could
be
that
in
terms
of
mescheri's
distribution
is
like
isn't
that's
another
thing
to
consider
is
as
a
distribution.
What,
if
there's
an
all-in-one
build?
A
And
it's
just
you
know
one
item
well
much
like
any
architectural
conversation
is
just
riddled
with
trade-offs
or
compromises,
or
I
could
see
a
strong
argument
being
made
for
a
distribution
of
one
binary
to
ease
the
burden
of
users
who
either
don't
need
scale
out
or
don't
have
security
or
other
requirements
to
keep
components.
Separate.
D
The
produceable
artifacts
sorry
to
interrupt.
We
could
have
the
workflows
like
independent,
like
it's
a
monorepo,
but
it
doesn't
have
to
be
one
single
distributable,
but
then
the
the
workflows
that
are
like
how
how
they
look
today.
It
would
need
to
be
refactored
so
that
they
could
produce
a
separate
artifact,
but
I'm
not
familiar
with
the
github
releases,
so
that
probably
might
yeah.
I'm
not
sure
if
there's
a
constraint
that
a
single
ripple
cannot
produce
like
separate
like
artifacts
or
releasable
items
like
maybe
that
someone
else
have
more
context.
C
It
should
be
able
to,
because
in
measuring
the
measurement
server
and
mesh
rectil
are
both
in
the
same
repository,
and
so
that's
what
I
was
thinking,
a
similar
structure
for
the
adapters
and
adapter
libraries
and
mesh
kit,
and
I
wasn't
thinking
about
changing
the
way
the
builds
are
created
as
far
as
you
would
have
still
have
the
same
individual
binaries
for
the
adapters.
It
would
just
be
all
in
one
place
but
to
your
point,
I'm
not
sure
how
releases
go
as
far
as
like
versioning.
A
Yeah
yeah,
it's
kind
of
funny.
I
yeah
that
wasn't
my
response,
wasn't
exactly
what
jared
was
what
you
were?
Probably
thinking,
which
was
I
I
didn't
speak
directly
to
what
you'd
said
but
like
jumped
to
oh
actually,
if
we
had
a
mono
distribution,
that
might
be
it's
like,
okay.
Well,
that's
actually
that's
worth
discussing
onto
its
own
merit
and
is
certainly
related,
but
is
almost
a
it's
a
highly
related
discussion,
but
almost
a
separate
topic
as
well.
A
A
Difficult
there,
I
don't
know
that
there
is
a
singularly
correct
answer
rather
there's.
Rather,
what
you
end
up,
leaning
back
on
are
like
what
are
we
trying
to
optimize
for
and
what?
What
are
the
design
principles
of
the
of
the
project
or
or
the
design
principles
of
these
components
or
this
functional
area
and
then
trying
to
formulate
the
best
path
forward
from
there?
A
Because
it's
yeah
yeah,
you
don't
you,
you
can't
arrive
at
a
correct,
a
singularly
correct
one
in
many
of
these
discussions,
because,
because
it's
actually
depending
upon
what
you're
trying
to
optimize
for
one
or
the
other
one
is
much
more,
is
much
better
than
that.
So
so,
some
of
the
trade-offs
that
that
go
around
are
on
the
on
the
first
topic
about
mesh
kit
and
mesh
adapter
library.
It's
like
yeah.
That's
act
like
at
first
blush.
It's
quite
tempting
it's
like.
Are
we
really?
Is
there
really
a
separation
between
these
two?
A
A
What's
the
decision
making
process
there,
for
which
one
goes,
where
that's
not
necessarily
always
clear,
to
the
extent
that
it
isn't
really
clear
that
kind
of
lends
credence
to
an
argument
that
says
putting
them
to
then
just
like,
if
you
can't
tell
the
difference
like
why
aren't
they
just
one
in
the
first
place
or
like?
If
and
here's
part
of
the
the
thing
is
so
there's
the
the
of
mesher's
components?
The
adapters
are,
I
think,
the
most
prominent
individual
components.
A
This
is
like
mesh
reservoir,
which,
most
of
the
time
a
lot
of
us
just
say,
measuring,
and
we
generally
mean
the
server
component.
There's
when
you
break
out
all
the
components
there's
like
there's
a
ui
which
doesn't
really
which
which
at
the
moment,
given
that
it's
non-golang
it's
less
of
a
consideration
in
this
particular
discussion.
But
it
relates
to
like
why?
A
A
A
I
forget:
oh
there's
the
operator
mesh
sync
industry
broker
as
other
components,
so
it's
like
they're
they're
in
lie.
Probably
part
of
the
first
crux
of
the
question
about
what
functions
benefit
adapters
and
what
functions
like
what
unif
like
the
concept
is
that
at
the
highest
level,
if
the,
if
you
can
call
yourself
a
measuring
component,
you
would
have
you'd
have
some
similar
characteristics
between
all
of
them
and
that
you
would
derive
those
in
this
case.
A
The
way
that
we're
structured
today,
like
from
mesh
kit
where
you
you'd
you'd,
be
able
to
register
your
capabilities.
You'll,
be
able
to
report
on
your
version
report
on
your
operations
that
you
support.
Like
do
a
certain
number
of
base
level
things
that
that
make
you
look
like
and
make
you
become
a
measuring
component.
A
If
you're
one
of
the
10
adapters,
then
you
may
have
some
additional
common
functionalities
that
you're
looking
to
do
for
interacting
with
git
or
downloading
that
or
doing
a
helm
thing
or
something
and
to
jared's
point
like
it's
not
like
some
of
that.
Some.
It's
not
like
these
other
components:
mesh
reoperator
measuring
mesh,
sync
measuring
broker
mesh
re
ctl
and
mesh
reserver,
these
other
five
or
so
six
or
whatever.
I
said
it's
not
like.
They
don't
sometimes
have
some
of
the
same
github
or
helm,
chart
or
whatever
something
like
they
don't
have.
A
A
That,
if
psyllium
as
a
service
mesh,
doesn't
have
the
concept
of
side
cars,
it
has
daemon
sets
like
traffic
mesh
that
just
that
doesn't
do
like.
If
some
of
these
are
significantly
different
from
the
next,
then
they
it's
good
that
they're
able
to
move
independently
and
be
versioned
independently
and
but
so
long
as
they're
speaking
that
common
kind
of
mesh
kit
or
there's
they
have
the
they're
speaking
the
common
meshery
component
language.
A
If
you
will
today,
that's
been
or
historically
that's
been
grpc
that
anyway,
that
that's
part
of
the
backdrop
as
to
and
then
there's
these
other
components,
measure
server,
ctl
and
so
on.
That
aren't
adapters.
And
so
the
concept
was
that
they
would
have
a
separate
library.
One
would
be
the
parent
of
the
next.
C
D
A
A
How
much
difference
is.
Okay,
we've
been
doing
this
for
a
while,
like
how
much
difference
really
is
there
between
the
library
and
mesh
kit
like
and
and
what's
the
overhead
involved
in
that,
like
maybe
bringing
those
like
your
initial
suggestion
of
maybe
bringing
those
together
is
there's
merit
to
like
flushing
out
that
discussion
like
there's
merit
to
if
you
take,
if
you
take
it
once
this
is
actually
what
I
was
going
to
do
is
like.
A
Take
it
one
step
forward
and
say
well
hey,
why
do
we
have
any
adapters
that
all
want
to
just
come
together
and
like
yeah?
It
does
come
down
to
some
fundamental.
Like
I
don't
know,
it's
been
tempting
because
it's
a
panda
rum
to
go
around,
especially
with
github,
has
improved
and
improved
and
improved,
but
still
managing
this
many
repos
and
all
of
the
process
and
things
that
goes
behind
them
is
still.
You
know,
there's
a
reason.
You
know,
that's
why
they
have
the
enterprise
edition
yeah
it's.
A
A
Anyway,
it's
a
good
discussion
point
to,
I
think,
continue
to
have
about
mesh
free,
adapter
library
and
mesh
kit,
because
it
may
not
be
that
they're
really
we're
really
benefiting
from
those
being
separate
the
rest
of
the
components
like
mastery
ctl.
Do
you
know
how
many
times
people
have
asked
and
begged
and
pleaded
for,
and
it's
not
it's
not
like
I've
denied
it
like
me,
have
denied
a
former
ctl
to
be
separate
from
mystery
server.
Why
is
measure
ct
on
its
own
repo?
A
And
so
it's
like
there's
a
great
argument
for
doing
that,
and
there's
also
like
to
the
extent
that
you've
already
borne
the
pain
of
having
separate
workflows,
one
for
building
that
one
for
building
that
it's
like
it
becomes
less
compelling
to
move
them
out,
because
it
just
becomes
another
thing
to
manage
another
reason
that
we've
kept
some
of
the.
Why
do
we?
Why
are
we
shoving
the
docks
into
the
same
repo?
Why
isn't
that
a
different
repo?
A
It's
like
well
in
part
because
and
there's
there's
a
bunch
of
things
that
factor
in
one
of
them
you
might
get
a
chuckle
is
like,
because
when
people
start
the
project
or
when
they
contribute
to
the
project,
people
generally
look
at
one
repo,
not
the
other
34
repos.
They
look
at
like
one
and
they
say
how
active
is
the
project.
How
well
liked
is
it?
It's
like
well,
actually
yeah,
the
more
that
we're
doing
in
one
the
the
higher
concentration
that
is.
A
Random
there's
a
bunch
of
there's
a
bunch
of
things
to
think
about
it
might
be-
and
this
is
what
I
was
saying
is
like.
I
think
that
getting
to
a
distribution,
that's
a
singular
binary
to
the
extent
that
that
scales
and
works
for
people
or
just
as
an
initial
deployment
style,
you
know,
might
be
really
helpful.
A
C
Yeah,
well,
I
guess
you
have
to
think
about
what
the
what
their
priorities
right
now
are,
and
this
conversation
seems
like
it
would
mostly
affect
those
working
on
adapters,
probably
to
the
end
user.
I
don't
know
if
it
would
have
any
impact
at
all,
and
so
right
now
we're
developing
for
the
end
user
correct.
So
we
can
put
the
convenience
of
developers
on
on
hold
I'll
focus
on
delivering
features,
which
is
the
the
end
goal
right.
C
A
A
A
If
we
can't,
you
know,
I
think,
between
those
two
things.
If
we,
if
we
can't
show
either
of
those
two
things
that
then
then
maybe
there
isn't
a
strong
argument
for
mash
kit
and
the
library
to
continue
to
be
separate,
because
because
I,
for
my
part,
I
think
that
the
lines
have
been
pretty
muddied
between
which
what's
supposed
to
go
where
and
when
and
the
the
general
decision-making
framework
was
like
hey
is
this
is
the
notion:
is
this
going
to
be
a
library
on
an
adapter,
only
piece
of
functionality
and,
if
so,
put
it
there?
A
C
A
Yeah
yeah
and
it's
not
right,
I
mean
to
the
extent
that
we
are
writing
these.
For
the
end,
users
doesn't
mean
that
we
should
neglect
the
developer.
Experience
like
like
I.
I
do
think
that
this
is
a
good
question
and
it's
like,
I
think,
had
you
asked
this
a
year
ago.
It
would
be
like
well,
probably
the
others.
A
The
other
maintainers
that
were
here
would
probably
stick
to
their
guns
and
say:
well,
you
know,
here's
all
the
reasons
why
and
et
cetera,
and
but
with
this
having
been
there
for
a
year
or,
however
long
it's
appropriate
to
reflect
on
the
the
value
like.
Are
we
getting
the
value
out
of
these
two
things
being
separate,
or
are
we
just
kind
of
getting
the
complication
right
did
this
I
mean
this
has
merit.
A
A
But
ultimately,
if
you
can't
maintain
it
or
it
takes
too
long-
and
you
can't
it
takes
this
long
to
turn
around
a
bug,
it's
like.
Well,
that's
definitely
end
user
impacting
as
well.
So
I
keep
it
I'm
just
yeah
jared.
I
think
you
should
keep
it
alive.
I
think
we
should
start
to.
You
know
note
the
pos,
the.
C
B
Yeah,
so
basically,
my
topic
is
about
smb
text
testing
and
how
we
can
show
the
output
of
our
of
of
the
result
of
the
test
which
we
do
on
our
cncf
labs
and
how
that
can
be
shown
for
the
end
users.
So
so
the
thing
first
thing
to
be
noted
is
that
we
have
this
repository,
which
uses
it
cncf
labs
to
run
this
test
and
it
uses
a
bit
of
actions
so
right
now.
B
The
thing
is
that
we
are
just
doing
the
test
and
we
are
not
say
we
cannot
show
the
output
of
each
of
the
results,
because
there
is
no
api
which
can
fetch
the
results.
So
my
goal
was
to
write
a
design
spec
which
can
enhance
the
current,
which
can
extend
the
current
usage
of
the
remote
providers
so
that
it
can
provide
a
new
api
which
can
be
used
by
the
smp
website
this
one
and
I'm
currently
working
with
aditya
cbd
on
this.
B
E
A
B
E
E
A
B
Okay,
so
so,
as
we
know,
we
have
a
extension
like
messy
extension
and
matchmap
is
one
of
the
mastery
extension.
So
we
have
some
needs
of
our
custom
components
to
be
drawn
from
the
machine
ui
itself
like
extended
from
the
mesh
ui
and
should
be
used
by
the
conferencing
much
you
know,
you
know
in
a
in
a
bit
refined
or
changed
with
based
on
the
what
we
need
to
provide.
So
this
is
what
it
is.
B
B
So
this
is
a
point
where
you
know
how
how
we
can
provide
our
custom
components,
how
we
can
inject
custom
components
from
navigator.
Any
you
know,
any
messy
extension
to
machine
depot
is
what
I
have
written
the
dock
for,
and
I
just
need
to
help
with
you
know
getting
this
talk
on
on
this,
our
talks,
page
so
yeah
and
and
thanks
our
screen.
You
ask
for
your.
A
F
F
Yeah,
so
this
is
again
about
consistency
of
design.
Another
thing
that
I
wanted
to
bring
up
was
currently
we
don't
have
any
way
of
deleting
existing
patterns
with
pattern
name
either
in
machine
machine
patently,
whereas
in
pattern
apply,
we
could
just
supply
the
name
of
the
pattern
and
if
it's
saved,
then
it
will
be
applied.
So
I
was
thinking
if
we
could
also
have
a
way
to
delete
like
that
with
the
pattern
name.
A
F
A
Oh
yeah,
totally
it's
totally
ambiguous
yeah
this
actually,
if
jared
ends
up
looking
or
any
jared
or
anyone
else
ends
up
assisting
or
collaborating
with
jared
on
mystery,
ctl
points
of
clarification
of
like
hey
what
happens?
If
I
take
a
pattern
and
apply
a
pattern,
you
know
it
provisions
your
infrastructure.
What
happens
if
I
delete
a
pattern?
Does
that
mean
that
I'm
deleting
the
pattern
or
like?
F
A
And
the
verbs
make
a
difference
if
I
say
import
a
pattern
for
sure.
You
know
that
the
file
itself
is
going
to
come
inside
you're,
not
quite
sure
it
could
go
either
way,
maybe
if
it
was
going
to
actually
apply
and
deploy
the
infrastructure,
but
if
that's
presented
in
context
of
another
command
called
mastery,
ctl
mesh
apply
or
run,
then
it
becomes
a
lot
more
clear.
A
That
said,
like
giving
a
bunch
of
feedback
to
the
user
on
the
command
line
is
also
helpful,
especially
after
deleting
something
is
to
repeat
back
to
them.
Oh
pattern:
design
file,
this
file
name
deleted
versus,
like
oh
nginx,
service,
mesh
d,
provisioned,
these
four
components
and
listing
them
out,
like
you
know,.
F
A
A
There's
another
yeah
under
deploy
undeploy,
that
was
my
deploy,
definitely
does
not
mean
import
a
file,
it
deploy,
means
yeah,
and
so
that's
a
good
verb.
Yeah
actually
just
actually
like
writing
down
the
verbs
and
and
the
verb
choices,
and
why
is
it's
one
of
those
things
like
what
jared
was
talking
about
it?
You
have
to
write.
We
have
to
write
this
down
to
really
clarify
because
it
it
makes
a
big
difference.
A
C
A
This
this
design,
spec,
doesn't
say
it
explicitly
the
the
main
meshry
cli
design
spec.
Does
it
says
something
obvious
and
kind
of
somewhat
silly
is
like
you
want
it
to
be
intuitive?
Yes,
of
course,
but
it
actually
goes.
It
gets
more
specific
and
it
says
exactly
what
jared
just
says,
which
is
we
need
to.
A
We
should
recognize
that
many
of
the
users
of
mastery
ctl
are
also
concurrently
and
historically
users
of
either
docker
or
cube,
cuddle,
cube,
cto
and
so
yeah
leaning
into
and
as
a
matter
of
fact
like
some
of
them
may
come
back
and
say.
They'd
like
for
measuring,
measuring
ctl's
capability
to
be
a
cube.
Ctl
plug-in,
like
so
leaning
into
being
kubernetes
native
is
we're
going
to
find
is
the
least
amount
of
friction
and
the
most
probably
intuitive
for
the
specific
user
of
mystery.
So
I
was
just
going
to
reinforce
jared's
point.
F
C
There's
a
a
side,
I'm
sorry
side
topic
on
this
one.
I
I
did
notice
that
with
the
coi,
if
an
incorrect
command
is
injured
for
several
of
the
commands,
it
just
links
you
to
the
documents,
which
is
not
something
I
like
to
have
happen.
When
I
misuse
a
cli,
usually
it
says,
use
it'll
display
the
help
for
that
command,
rather
than
redirecting
me
to
go
somewhere
completely
different
in
context.
Switch.
A
Yeah,
there's
there's
a
contributor
who
should
be
on
the
call
alpha
or
aditya
aditya
a
who
is
actively
working
on
godox
for
mastery
ctl
such
that
I
mean
on
a
very
related
note,
he's
making
some
he's
putting
forth
some
significant
effort
to
change
the
way
in
which
mess
we
see.
Tl
docks
are
auto,
documented
and
jared.
Those
he's
he's
got
an
open
pr
on
it.
Actually,
it
may
be
of
interest
to
you
and
yeah
to
your
point.
Sometimes
yeah.
It's
like
it's
it's
nice
when
sometimes
it's
to
take
jared's
comments
even
further.
A
It's
not
only
nice
to
get
the
help
spit
back
to
you
to
let
you
know
give
you
some
examples.
I
think,
but
sometimes
it's.
If
the
help
is
like
a
page
like
a
full,
I
don't
know
100
lines
long,
sometimes
that's
even
that
is
annoying.
It's
like.
Ideally,
you
want
help
shown
to
you
unless
it's
way
too
much
like
and
it
actually
doesn't
take.
A
A
There
could
there
can
be
a
I
I
for
my
part,
I
got
sometimes
sometimes
it's
not
if
it's
a
short
url
like
it
might
be
nice
to
if
you're,
giving
them
the
help
and
then
at
the
bottom,
you're
saying
like
also
for
further
reference
or
future.
You
know
like
here's
the
link
as
long
as
it
doesn't
take
up
a
lot
of
space.
A
A
E
Yeah
so
like,
can
you
open
that
vr,
like
I
have
linked
it
yeah
there
were
some
bugs
regarding
the
design
configurator
not
able
to
create,
create
new
design,
and
when
we
tried
to
update
the
design
through
the
yaml
dialog
box
and
the
table
view,
the
designs
were
not
getting
updated.
So
I
fixed
that-
and
another
thing
I
fixed
was
that
the
application
name
when,
when
we
try
to
edit
anything
in
the
application,
the
name
was
not
being
displayed
like
after
we
edit
anything
in
the
ammo
dialog
box.
So
that
is
also
fixed.
E
A
D
So
I'm
still
working
on
the
a
measure
ui
contributing
updates
for
cyprus
and
end-to-end
tests,
considerations
I'll
be
sending
I'll
be
adding
a
discourse
thread
just
to
get
some
more
feedback
on
pain
points
of
contributors
that
now
already
contribute
there
and
also
newcomers
like
like.
I
don't.
I
know
a
lot
of
things
are
working
with
this
from
my
years
of
experience,
but
it's
just
I.
I
want
to
be
clear,
clear
and
concise
and
just
have
the
right
level
of
you
know.
D
A
D
Okay,
it
sounds
good
what
about
like,
so
we
have
a
readme
for
contributing
to
the
ui
and
then
we
also
have
the
docs
the
docs
website.
So
I
don't
know
where?
Should
the
most
of
the
information
be
like
at
what
point
should
we
say?
Okay,
go
there
like
what
what's
the
ultimate
source
of
through
the
docs
right,
the
website.