►
From YouTube: Meshery CI Working Group (May 4th, 2020)
Description
The fourth was with us and we were with the fourth in today's discussion on use of ReleaseDrafter.
B
A
A
A
A
A
J,
alright,
well
I,
guess
enough
of
playing
around
it's
Monday,
the
4th.
May
the
4th
be
with
you
the
measure
ECI
working
group
meeting,
our
second
one.
We
had
quite
the
turnout
for
the
first
ones
that
was
great
and
and
now
we're
gonna
get
into
the
meat
of
the
work
I
suspect.
So
only
the
bravest
of
hearts
are
here
today.
A
A
Getting
confused
on
navigation
cushion
Avena
poor
sign,
you
know,
ok,
very
good
I
think
we
got
everyone
all
right.
A
couple
of
topics
up
for
today,
actually
again
mostly
like
as
we
go
forward,
I
expect
I'll,
probably
end
up
driving
this
conversation
in
this
meeting
a
little
bit
less
and
less,
but
I
had
I
put
up
a
couple
of
topics
that
we
could
chew
through.
A
These
are
things
that
are
mostly
topics
from
below
in
either
they
were
current
last
week
and
still
outstanding
or
they're
backlog
items
that
I
think
we
might
have
time
for
so
this
week.
One
of
the
the
items
from
last
week
is
to
do
a
demo
of
released.
Drafter
is
to
maybe
talk
more
about
the
sort
of
first
step
here
to
versioning
mastery
server,
I
kind
of
talked
about
how
we
think
why
that
needs
to
be
done
and
how
we
think
that
that
might
be
done.
A
By
the
way,
and
it's
quick
health
keeping
everyone
on
the
call
is
aware
that
we
record
the
calls
and
put
them
up
on
YouTube
I'll
try
to
only
call
out
those
housekeeping
items
when
newcomers
are
on
because
it
gets
kind
of
old,
I
think
but
I
had
a
newcomer
last
week.
That
was
surprised.
I
guess
pleasantly
surprised
that
their
smiling
face
was
on
YouTube
itself.
A
C
C
C
C
Used
the
released
after
action,
the
action
uses
a
configuration
file
which
I
have
provided
as
release
draft
of
dot.
Yml
the
configuration
file,
dest,
wouldn't
the
good
dot
get
of
folder.
Is
it's
over
you,
so
the
name
template
or
the
take
template
are
following
the
semantic
versioning
which
we
already
follow
in
misery
and
coming
to
the
categories
there.
C
There
is
a
stamp
'let
where
we
can
thank
contributors,
so
I
just
labeled,
some
three
to
four
peers
of
dependable
according
to
the
according
to
area.
They
were
concerned
so
I
just
made
at
least
so.
This
number
54
PR
I,
had
lived
with
the
PR
as
enhancement
as
you
can
see
over
here,
and
it
was
automatically
categorized
into
the
title
features
I
labeled,
the
number
46
PR,
as
fix
I-
think
yes,
I
labeled
it
as
fixed.
C
And
if
we
don't
want
any
categorization
into
some
into
some
titles
that
and
we
can
just
use
a
DEP
I
reached
after
action
which
I
had
used
earlier.
So
it
will
be
like
this.
All
the
PRS
which
have
been
merged
into
man
will
be
managed
and
there
will
be.
There
will
be
title
in
the
changes
thing.
This
is
the
only
thing
which
we
need
in
the
draft.
One
of
the
major
concern
is
about
the
labeling
of
PRS.
C
A
C
Shiva
was
saying
that
we
should
have
a
change
log
fight
where
we
can
mention
each
and
every
pool
request
with
the
link
will
request.
So
I
just
give
him
a
suggestion
that,
rather
than
having
contributing
about
changed
or
MD
file,
we
can
use
released,
after
which
we'll
do
the
thing
which
you
are
telling
us
to
do
automatically.
C
C
Like
if
any
PR
is
most
or
the
PRS
concerning
with
around
11
to
12,
commits
with
it
so
rather
than
taking
each
and
every
commit
depend
of
the
release,
laughter,
we'll
just
take
the
PR
title,
whatever
the
PR
title
was,
and
it
will
put
it
and
that
as
a
change,
but
it
will
be
consisted
of
single
PR.
Okay,.
A
A
C
A
Good
that
makes
sense
to
me
I.
You
would
send
a
couple
of
words
there
that
are
no
no
yeah
token
in
the
past,
usually
squashing
and
in
the
in
the
primary,
as
a
separate
topic
being
being
ensuring
that
people
were
getting
their
due
credit,
great
okay,
so
this
I
think
that's
a
and
that
kind
of
conforms
a
bit.
A
C
I
was
thinking
about
following
semantic
PR
labeling
for
a
ripple
like
currently.
What
we
do
is
measure
ECT,
el-masri,
UI
and
what's
semantics
we
are
naming
is
like
they
are
around
five
to
six
keywords
like
feed
fix,
core
low
cute
dogs
and
tests,
and
there
are
one
of
two
which
are
missing
so
like
we
can
write
a
bot
which
can
detect
the
semantics
semantics
name
of
the
PR
and
it
can
label
the
PR
accordingly.
C
A
C
Here
are
the
semantic
we
are
labeling
which
we
can
follow.
If
we
start
a
PR
with
feet,
the
PR
will
be
categorized
into
the
feature
column.
If
we
start
with
fixed,
it
will
go
into
bug
fix.
There
are
dog
style,
refactor
perf
test
Bell
CI
from
so
it
depends
upon
us
like
do
we
need
to
follow
some
on
tech
naming
or
do
we
need
to
go
with
some
other
side?
It
is
a
custom
bar.
It
seems
like
we
go.
A
So
but
I
think
we
got
a
couple
of
questions
on
the
table.
The
first
one.
Let
me
try
to
articulate.
Let
me
let
me
maybe
bring
up
the
PR
that
Chris
you
were
sharing
to
try
to
get
a
vote
or
get
some
opinions
on
what
I'm,
what
I'm
asking
what
I'm
talking
about,
if
I
could
figure
out
how
to
share
my
screening,
it.
A
I
switched
to
the
measuring
repository
and
the
way
that
we've
been
doing
it
kind
of
to
date
has
been
well.
It's
been
done
by
hand.
It
may
be
a
kind
of
an
issue
or
trying
to
get
away
from
part
of
this,
but
has
been
done
by
component.
It's
really
just
been
focused
on
features,
and
so
by
components
like
hey
here's,
the
things
that
are
coming
forth
new
in
measure
a
server
new
in
these
adapters
new
in
this
component
seems
like
there's
two
ways:
maybe
of
organizing
those
does
anyone.
A
C
The
same
area
is
no
actually,
we
can
follow
the
other
like
which
we
are
following
in
the
mesh
rewrap.
Oh,
the
only
thing
there
will
come
is
the
labeling
of
the
peers,
which
we
can
write
a
bot
forward.
So,
like
the
the
titles
which
are
which
are
mentioned
here,
these
are
not
some
standard
titles
like
we
edited
from
the
configuration
file,
so
we
can
edit
the
title
and
we
can
also
edit
the
label
which
which
release
raptor
should
observe
under
the
specific
heading.
C
So
we
can
have
adding
like
machinery,
machinery,
CT
and
raptors,
and
we
will
observe
label
like
if
any
PR
is
having
label
mushy
CDM.
It
will
go
into
the
heading.
My
cherie,
CTL
NEP,
obviously,
label
Mishra
it
can
go
under
the
Machine
and
any
PR
with
label
adopt
again
we
want
a
doctor
so
for
this
we
would
need
a
board
which
which
can
detect
the
PR
title
like
for
now,
as
we
are
doing.
If
a
PR
is
concerned
with
machinery
CDL,
we
write
machine
in
and
the
prefix.
C
A
A
A
E
Lina
one
question
that
Oh,
as
we
are
doing
good
previously,
while
maintaining
the
release
drop,
that
we
are
categorizing
the
new
changes
we
have
made
in
the
release
or
in
the
previous
version.
We
are
just
mentioning
the
new
things
that
we
have
provided
and
based
on
three
categories:
adept
or
smash
DCT
and
machinery.
We're
writing
as
the
changes
but
in
the
wave
kosh
is
currently
doing.
E
We
have
mentioned
that
what
are
the
bugs
fixed
water,
the
maintenance
done,
and
what
are
the
new
things
that
have
come
up
so
I
think
whenever
we
release
a
version,
we
should
also
mention
that
the
previous
bugs
have
been
fixed
with
this.
So
are
we
like
trying
to
focus
it
somewhere
in
the
previous
version,
or
should
we
do
it?
So
that
is
one
question.
I
have.
A
My
opinion
is
that
we
should
include
the
bug
fixes
as
well
that
I
guess
my
overall
opinion
is
that
a
couple
of
things
one
is
that
no
one
who
looks
at
these
release
notes
today,
and
hopefully
that
will
change
over
time
that
the
first
people
that
start
to
that.
The
first
few
that
start
to
look
at
them
and
and
want
to
keep
pace
with
the
project
will
mostly
be
interested
in
new
features
and
what
those
are
and,
over
time,
more
and
more.
A
We'll
also
be
very
interested
in,
like
specific
bugs
that
they
have
found
getting
fixed.
So,
hopefully,
we'll
have
people
who
are
very
much
so
into
the
nitty-gritty.
I.
Consider
that
the
bug
fixes
are
kind
of
nitty
gritty,
but
that
they
should
be
included
that
that
using
automation
here
like
release
drafter
is
very
helpful.
A
It
would
be
nice
and
big
liberal
component
type,
but
I
kind
of
think
that
might
be
more
work
than
it's
worth.
Part
of
that
work
is
in
part
what
Chris
was
saying
which
is
today.
You
know
in
order
for
that
to
work
very
well,
we've
got
to
make
sure
that
either
a
we
have
a
practice
of
manually,
assigning
labels
to
pull
requests
so
that
they
get
categorized
correctly
or
be
having
a
triage
bot
that
are
I'm.
Sorry,
a
semantics.
A
Yeah
in
most
respects,
for
me,
the
thing
that
released
drafter
is
doing
right
now
is
probably
just
fine
is
like
we
do
want
to
get
to
that
automation.
If
at
some
point,
we
figure
out
that
no,
we
don't
want
to
group
all
enhancements
under
one
category,
but
we
want
to
begin
to
break
those
out.
It's
something
that
we
can
iterate
on
in
the
future.
I,
don't
think
like
I,
don't
think
it's
a
bad
step
to
sort
of
switch
to
what
release
chapter
is
doing
now.
A
A
A
Sometimes
people
will
put
in
a
PR
that
actually
affects
both
right,
because
if
you're
gonna
build
something
backend
and
you
expose
it
in
the
front-end,
sometimes
that
goes
into
the
same
PR.
So
you
know:
where
does
that
most
appropriately
land?
It's
just
a
judgement
call
and
in
the
end
it
probably
doesn't
really
matter
so.
F
Highly
okay,
enemy,
yep
and
Lee
I
think
the
least
doctor
that's
currently
working
is
I.
Think
is
we
want
to
be
in
need?
Some
more
advancements,
I
think
is
moving
forward
when
we
do
automate
things
and
I
think
is
when
we
move
to
that
process.
This
might
be
some
changes
in
that
some
environments,
I
think
in
the
in
there
in
the
first
place,
I
think
we
should
know
that
I
think
we
should
know
that
we
can't
couple
together
things
so
they're
moving
more
but
can't
be
easily
integrated
to
their
own
components
as
well.
F
So
I
think
it's
moving
I
think
currently
is
doing
a
great
job,
good
job,
so
moving
forward
when
you
activate
that
things
and
also
I
think
some
repositories
are.
The
good
thing
is
that
the
feature
that
enhance
enhances
with
that
is
go
to
the
DOCSIS
realm
that
this
is
a
think,
and
this
is
a
more
detail
into
the
docs
as
well,
and
you
can
grab
that
what
we
are
producing,
but
is
a
moving
I
think
moving
forward.
F
We
could
automate
that
things
I'm
currently
working
on
that
and
planning
out
I
think
which
one
things
I
think
when
we
talk
about
some
things
here,
I
think
it's
easy
for
everyone
else
that
some
diagrams
are
there
so
can
easily
grasp
the
concept.
What
we
are
pointing
to
so
so
actually
I
think
goosh
care.
F
We
have
the
released
off
the
finger
and
it
immersed,
and
it's
a
good
that
we
have
some
drawings
of
that.
So
can
you
delete
everybody
can
easily
become
say
so,
I
think
the
one
good.
My
suggestion
is
that
that
we
can't
things
in
that
couple
together,
though,
things
are
moving
good
in
the
right
now,
but
move
so
bias.
The
good
thing
is
that
we
can't
couple
things
together
for
the
car
to
be
more
gifts
easily,
so
I
think
it's
a
lot
more
solution
to
that
problem.
I'm.
F
Also
the
one
current
position
there
is
a
10100
of
solution
available,
so
right
now,
I'm
figuring
out.
What
is
the
possible
solution?
Is
that
so
I
think
good
ways
that
that's
I'm,
trying
to
the
figure
here,
the
CI
working
group
that
everybody
can
some
doing.
Some
demo
just
pray
for
simple
as
she
loves
small
diagram
is
well
not
a
fancy,
just
just
steps
that
we
are
proper
trying
to
that
is,
and
everybody
Canadians
understand
what
we
are
trying
to
say.
C
A
C
So
the
next
topic
is,
although
related
to
this
one,
like
the
main
major
problem
which
we
were
having
with
released
after
this,
is
about
the
labeling
of
PRS.
So
I
was
looking
at
github
actions
and
to
manipulate
github
actions.
You
can
either
actually
use
pious
metadata
or
you
can
actually
use
PR
title.
C
So
if
we
want
to
trigger
some
specific
PR
actions
for
some
specific
PR
like
I,
think
we
don't
need
to,
we
don't
need
to
trigger
the
release
action
of
mushishi
deal
for
each
and
every
PR,
and
also
we
do
not
want
to
trigger
the
docker
action
for
each
and
every
PR
so
like
if
any
PR
is
having
a
label
release
like
if
any
PR
is
concerned,
with
the
release,
so
only
for
those
PRS,
those
actions
will
be
done.
So
again,
there
will
be
an
issue
of
so
again
there
will
be
a
show
of
labeling.
C
The
PRS
like
currently
coming
to
the
nightly
file
natla
is
observing
the
directory.
So
if
any
directory
is
not
concerned
with
the
document,
if
any
PR,
which
is
not
concerned
with
the
change
in
the
documentation
directory
nettle,
if
I
automatically
cancel
it
cancel-
and
this
feature
is
not
currently
will
bigot
of
actions.
So
you
have
to
go
by
labeling
the
PRS
reading
the
reading
the
levers
of
the
and
then
deciding
which
sections
we
want
to
trigger.
A
C
A
A
C
C
Also
like
having
a
prefix
for
a
PR,
well,
we'll
keep
the
things
more
organized
like.
If
we
give
the
contribute
to
the
right
to
label
their
own
PR,
there
can
be
a
diversity
like
someone
can
label
it
enhancement.
Someone
can
label
it
feature,
so
we
can't
get
a
common
label
extracting
all
of
these
features
or
all
of
all
of
the
PRS
coming
into
a
category.
So
having
some
common
rules
established.
E
A
Sure,
yeah
I
don't
think
no
one
can
I,
don't
think
any
contributors
can
create
labels
I
think
they
can
certainly
type
whatever.
There
were
two
in
the
subject
line
for
a
PR
or
an
issue
which
is
even
more
preformed.
It
seems
like
having
a
lens
for
encouraging
appropriate
prefix
and
then
encouraging
me
appropriately
seems
like
those
are
both
the
right
thing
to
do.
A
A
A
F
Li,
hey
you
hear
me,
leave
one
thing:
that's
that
I'm
trying
to
figure
out
that
a
up
were
part
of
the
mystery
project.
We
are
working
looking
for
hours.
Another
service
mesh
is
to
easily
incorporate
that.
So
if
they
have
one
service
mesh
as
a
control
as
in
ingress
controller,
I
just
say
controller
same
discretion,
one
doesn't
have
that
controllers
in
disk
controller
and
when
they
try
to
adjust
an
hour.
F
So
one
that
the
head
advancement,
if
we
are
done
that
so
might
be
in
a
future,
would
have
recognized
that
we
have
a
link
to
Jericho.
They
are
Doc's
as
well,
so
we
can
exact
this
and
this
with
Marshallese
click
there
to
the
docs
that
we
have
every
impression
and
that
talk
is
well.
You
know
put
up
another
dogs
that
this
is
a
feature
they
have
incorporated
that
data
and
that
we
facilitate
here
in
industry.
So
then
things
not
really
did
change,
but
the
flow
is
kind
of
a
very
change
in
that
map.
F
Leah,
just
just
didn't
know,
that's
the
previous
version
of
that
change
and
we
doesn't
support
just
I
say
that
English
controller
for
that
facade
mismatch
and
that's
a
doctor
for
that,
but
the
next
version
we
can't
integrate,
integrate,
that's
English
controller,
but
that's
English
controller
might
be
that
another
vendor
specific
thing.
So,
who
might
be
we
link?
That's
English
controller
goes
to
our
page
to
go,
find
that
that's
the
thing
that
we
income
per
incorporated
and
that's
the
thing
we
had
enhances
and
that's
the
feature.
That's
we
are
changes
there.
F
Just
leave
the
one
one
working
flow
is
that
that
we
have
merged
the
1.3
Lilly
students
doesn't
support
the
particular
anything
risk
controller
for
that
just
kind
of
assume
that
I
1
/
4
is
that
incorporated
dingus
controller
that
so
in
our
dogs
as
well.
We
have
to
link
the
other
resources
that
we
incorporated
their
changes
in
our
project,
so
people
may
find
a
look
at
what
the
ingress
went
means
for
that.
That's
not
our
thing.
That's
somebody
else
things.
F
So
if
we
incorporated
s
and
then
there
were
talks
that
we
are
creating,
they
have
to
be
able
to
it
as
well,
and
this
thinks
that
we
are
trying
to
awaken
it
change
the
lease
if
they
have
to
some
kind
of
a
manipulating.
Some
change
is
not
a
whole
lot
of
some
menu
changes
as
well.
That's
my
point.
Okay,.
A
Give
a
specific
example
to
to
bring
that
home
so
so
one
example
is
that
we
have
an
adapter
for
network
service
mesh
for
NSM,
even
on
our
documentation.
We
talked
about
the
fact
that
we
support
different
sample
apps
and
what
those
apps
are
come,
how
those
apps
are
defined.
Now
we
don't
define
those
sample
apps
that
those
are
defined
by
the
NSF
project.
We
have
a
little
bit
of
duplicated
if
you
will
a
description
of
the
sample
apps,
because
it
can
just
be
helpful
for
those
that
are
using
referee
to
understand
what
those
are.
A
If
you
go
to
the
network
service
service
mesh
project
and
you
look
at
their
Docs
and
you
go
to
look
at
I-
think
like
these
same
sample
apps
they
may
you
can
see
some
similarities
between
their
documentation
and
ours,
and
that's
intentional
right
where
we're
leveraging
things
that
they're
they're
creating,
and
so,
if
they
later
on,
go
to
add.
You
know
another
component,
another
deployment
to
this
sample
app
that
would
affect
our
documentation
and
it
would
ultimately
affect
the
behavior
of
our
sample
app
for
that
adapter.
D
A
Yep,
so
one
of
the
things,
the
only
way
that
I
really
know
to
come
around
this
is
to
have
is
to
ensure
that
the
adapters
that
we
have
are
for
each
service
mesh
is
maintained
by
a
representative
of
that
service
mash
because
they're,
the
ones
are
gonna
know,
what's
changing
inside
their
service,
mesh,
FEX
measure
e
and
the
measuring
adapter
and
they're
the
ones
that
can
help
us
keep
that
linkage.
Keep
that
those
dependencies
up
to
date.
There's
a
list
of
individuals
who
are
maintaining
adapters.
A
We've
got
about
half
of
the
adapters
covered
by
a
maintainer
of
that
other
service
mesh
and
about
half
of
the
adapters.
Not
so,
we've
got
a
little
bit
of
a
gap
because,
because
I
don't
know
that,
there's
a
way
necessarily
to
automate
this
as
much
as
to
have
someone
who's,
maintaining
an
adapter
who
represents
a
different
service
mesh
help
mesh.
We
keep
pace,
we're
fortunate
that
on
most
of
Friday's
calls
we
generally
have
like
one
or
two
of
those
one
or
two
representatives
of
other
service
meshes
there.
That's
not
enough.
A
F
And
only
I
think
would
it
be
nice
that
we
can
document
their
things.
We
just
maintain
they
rip
the
links
to
their
dogs,
so
if
that
day
it
changes
their
documentation.
Then,
though
they
have,
we
might
have
conflicts
because
we
have
older
documentation
and
they
have
a
newer
one.
So
I
think
it's
kinda
supposed
to
just
link
their
dogs.
A
F
Yes,
Li,
that's
that's
what
I'm
talking
about
so
the
links
to
their
documentation,
so
we
have
to
maintain
that
as
well.
So
I
think
people
just
click
on
our
talks
and
they
have
go
back
to
their
links,
is
better
I.
Think
other
projects
also
doing
the
same
that
we're
trying
to
solve
in
as
well
I've.
Seen
particularly
example
of
that,
and
that's
why
I
trying
to
ask
here:
that's
I
think
that
that's
a
good
approach,
I
think
we
don't
have
to
never
piss
some
invertibility
wrong.
Documentation
does
main
point
here:
ok,.
A
Very
good
yeah
so,
for
example,
on
this
adapter
we
would
describe
the
adapter.
It's
state,
some
of
the
things
that
it
does,
but
for
some
of
this,
but
we
would
make
sure
to
call
out
kind
of
prominently.
A
link
to
that
project.
Documentation
is
great.
Is
that
so
is
that
something
you
can
volunteer
to
go?
Do.
F
Yeah
I'll
check
so
kind
of
a
sub
snow
to
sing
the
how
to
automate
that
things,
because
if
we
automate
that
thing
we
have
to
make
things
standardized.
So
if
you
think
manuals,
so
mental
things
is
kind
to
of
the
some
conflicts
there.
So
I
think
we
said
it's
just
trying
to
figure
out
how
to
standardize
that
sings,
because
we
have
plenty
of
meshes
dogs
that
we
have
to
take
care
for
so
I
think
is.
F
If
we
somehow
manage
the
standard
way
of
that,
and
then
we
move
that
to
the
automated
way
as
well,
because
I
think
is
want
to
automate
something
you
knew
it
don't
know
how
the
manual
strap.
Is
that
so
we
just
figure
out
and
we'll
strap.
Is
that
and
then
we
figure
out
how
to
automate
that
process
and
there's
a
plenty
of
option
available
on
that.
We
can
do
automated
how
to
make
sure
of
that
nice.
A
We
can
just
add
a
new
attribute
that
has
a
link
to
the
docs
for
each
of
those
service
missions,
and
once
that
happens,
we
can
have
the
link
to
those
Doc's
or
show
up
on
this
page
other
than
that
there
isn't
any
other
way
to
automate
it,
because
all
of
those
other
projects
are
published
under
their
own
domain
name
under
the
in
their
own
fashion.
I'm.
A
Ultimately,
at
some
point
in
each
of
those
service
meshes,
we
would
want
to
have
a
description
of
the
integration
with
measure
II
and
and
have
them
pointing
back
to
measure
E
as
well.
So
for
as
a
first
step,
can
you
go
about
augmenting
the
existing
llamo
file
that
we
have
for
the
adaptors,
adding
in
the
links
to
each
of
the
documentation
for
these
projects?.
F
A
Yeah
I
think
it's
just
gonna
be
a
manual
length.
You're
gonna
find
you're
not
gonna,
be
able
to
automate
that
away.
The
automation
will
be
in
having
that
exposed
on
each
of
the
documentation
pages,
but
there's
no
I
mean
even
with
something
like
SMI
as
a
standard
approach
to
writing
as
service
mesh
api's
you're,
never
gonna
get
all
projects
to
like
standardize,
the
way
that
they
publish
their
docks.
A
Mesh
dogs
that'll
be
really
helpful
as
well,
okay,
so
so
trying
to
try
to
wrap
up
for
today.
So
we
got
when
I
try
to
I'm
here
for
Simon
we're
looking
for
a
volunteer
to
assess
the
current
labels
that
we
had
and
suggest
others,
and
then
so
think
about
that.
If
no
one
volunteers
I'll
go
take
care
of
it.
A
B
G
It
is
push
it
is
done.
I
thought
that
what
I
wanted
to
say
is
that
a
change
log
and
the
release
notes
is
not
necessarily
the
same
thing.
They're
saying
the
change
log
you
can
see
if
you
want
all
the
commits
or
the
pr's
and
so
on,
and
so,
but
in
the
same
time,
do
we
have
it?
Do
we
have
a
separate
ticketing,
ABS
or
just
github
issues,
because
there
are
things
that
you
add
you
add
improvements
features
exten.
We
extend
the
things.
G
G
G
A
A
And
then
of
the
conversation
that
we
were
having
about
release
drafter,
I
think
we
were
sort
of
trying
to
figure
out.
Hey,
can
release
drafter
produce
that
that
one
step
higher
that
that
that's
sort
of
more
like
release
notes
not
just
not
just
these
super
nerdy
specific,
like
detailed
logs.
But
could
it
also
summarized
a
little
bit
of?
A
Can
I
do
a
better
job
of
categorizing
and
summarizing,
and
it
sounds
like
with
bots
and
with
PR
labelings
that
that
might
be
possible,
but
that
there's
probably
a
little
bit
of
human
involvement
here
to
to
briefly
summarize
those
mean,
but
that
the
real
real
thing
that
probably
I
shouldn't
say
real
but
like
rather
the
thing
that
most
people
will
get.
The
most
value
out
of
is
probably
like
an
actual
write
up
by
someone
saying
that
these
are
the
new
capabilities
of
mastery
CTL
and.
A
It's
a
good
summer
that
it
sounds
like
a
thumbs-up
from
Edina
and
it
sounds
like
the
the
rest
on
use
of
release.
Drafter
and
trying
to
automate
changelog
seem
like
a
very
specific
listing
of
all
the
PRS
closed.
To
the
extent
that
we
can.
It
sounds
like
I'd.
You
know
that,
yeah,
to
the
extent
that
we
can
use
released,
that
release
drafters
organization
and
our
PR
labeling
gets
us
to
a
point
that
it
can
produce
something.
A
G
A
Okay,
cool
well,
I,
guess
so
kitchen.
If
you're
inclined
to
try
to
take
us
forth
on
release
drafter
in
at
least
a
measure,
you
repo
producing
those
you
know
detailed
logs
to
the
extent,
push
that
that
that
we
go
ahead
and
get
our
labels
and
some
of
maybe
our
contributor,
the
contributor
guide,
that
we
have
to
tell
people
to
make
sure
that
their
labeling
PRS.
A
A
Okay,
we're
a
little
bit
over
I
think
we're
almost
you're
all
on
the
same
page,
certainly
for
not
dude,
let's
catch
up
in
the
slack
channel,
but
this
is
good
I'm
hoping
we
can.
We
can
move
forward
on
this
this
week
at
least
Simon
great
comments
on
trying
to
ensure
that
we're
being
we're
representing
very
well
our
compatibility
and
with
the
service
meshes,
hopefully
we'll
get
them
pointing
some
links
back
to
measure
as
well.