►
From YouTube: Antrea Community Meeting 01/22/2020
Description
Antrea Community Meeting, January 22nd 2020
B
B
B
B
B
Okay,
so
the
first
thing
that
I've
done
is
introduced
a
directory
in
Docs.
We
can
decide
if
this
is
the
appropriate
place
to
put
this
or
not,
but
a
directory
that
holds
two
additional
documents.
One
is
called
def
process
and
one
is
called
labels.
Def
process
is
more
of
a
narrative.
That's
going
to
walk
through
a
typical
development
process
and
the
types
of
issues
that
may
be
submitted.
I
would
say
that
these
two
documents
are
probably
85:
90
%
complete.
B
B
The
labels
is
basically
going
to
just
list
a
bunch
of
labels
that
can
be
applied
to
issues
that
will
help
us
to
categorize
them.
My
goal
at
some
point
is
for
some
of
this
to
be
automated
and
to
use
github
actions
as
a
mechanism
for
performing
some
of
this
triage,
so
that
will
be
additional
work.
That
I
will
take
upon
myself.
In
the
end,
the
rest
of
the
team
too,
to
get
that
automated
and
then
the
process
here
is
going
to
describe
the
overall
process.
B
So,
let's
first
off
kind
of
start
off
with
you
know,
what
would
we
mean
by
this
process?
One
of
the
things
that
we
wanted
to
you
know
point
out
here
in
the
overview
is
that
you
know
purpose
of
doing
this
again,
as
a
is
a
lightweight
set
of
processes
that
will
hopefully
allow
us
to
quickly.
You
know
optimize
our
the
way
that
we
triage
issues.
B
Additionally,
as
the
project
goes
forward
and
we
begin
to
get
more
users
we're
going
to
want
to
be
able
to
respond
very
quickly
to
any
type
of
support
requests,
and
so
this
process
will
also
begin
to
address
that
when
an
issue
is
submitted
or
or
a
PR,
but
most
of
the
time
we're
going
to
be
starting
with
an
issue.
I
think
the
first
thing
that
we
need
to
do
is
just
kind
of
label
at
a
high
level.
What
type
of
issue
that
we're
dealing
with?
Is
it
a
you
know
an
API
change?
B
Once
we
have
an
idea
on
what
type
of
change
that
we're
dealing
with,
that
will
actually
dictate
the
type
of
a
workflow,
for
example,
if
it's
a
bug
and
is
in
need
support
from
the
community,
we
may
handle
that
process
differently
to
ensure
that
we
get.
You
know
rapid
response
back
to
the
user
of
the
project,
so
that
we
can
make
sure
that
we're
you
know
addressing
any
type
of
support
needs
that
they
have
in
terms
of
labeling.
B
B
We
can
talk
about
that
if
we
think
that's
necessary
or
not,
but
a
lot
of
the
a
lot
of
the
guidance
that
I've
taken
on
putting
this
together
actually
comes
directly
from
the
kubernetes
project,
obviously
I'm,
not
including
every
single
label
and
and
kind
from
that
project,
but
I'm
I've.
You
know
picked
and
selected
the
ones
that
I
thought
would
be
most
beneficial
to
our
project.
B
The
other
thing
that
we
want
to
do
and
I've
got
some
updates
like,
for
example,
I've
got
design
documentation.
You
know
whether
it's
an
issue,
for
example,
these
types
of
kinds
will
help
us
to
identify.
You
know
who
needs
to
pick
up
the
document,
one
of
the
ways
that
we
know
who
needs
to
pick
that
I'm.
Sorry
who
needs
to
pick
up
that
issue
is
what
area
that
it's
assigned
to
right
now.
The
system
project
is
fairly
small.
B
We
manage
that
internally
kind
of
an
implicit
in
an
in
an
implicit
way,
because
there
is
a
small
core
set
of
developers
as
we
begin
to
grow
our
developer
and
a
number
of
developers
participating
in
contributing
to
the
project.
The
area
assignment
will
help
us
to
begin
to
know
where
to
put
the
were
to
put
the
work
for
the
issuer
where
to
assign
the
work
for
the
issue.
Additionally,
from
a
project
management
perspective
as
we're
tracking
feature
completion.
B
B
The
triage
tags
help
us
to
identify
issues
that
are
submitted
from
the
community.
That
may
not
have
enough
information,
maybe
duplicate
'iv,
you
know,
may
involve
something
where
somebody
needs
immediate
report,
those
types
of
things,
and
so
we
want
to
be
able
to
take
issues
through
triage
before
we
identify
them
as
ready
to
work.
B
Additionally,
we
want
to
keep
our
backlog
clean.
All
of
the
labels
under
lifecycle,
for
the
most
part,
are
meant
to
be
automatically
managed
by
a
github
action.
For
example,
if
we
find
that
there's
the
activity
has
stalled
out
on
any
given
issue
or
PR,
we
want
a
way
to
actively
denote
that
with
a
label
to
say,
hey,
you
know,
nobody's
looked
at
this
issue
in
the
last
90
days
or
the
last
180
days.
You
know
if
an
issue
is
active,
we'll
add
an
additional
30
days
or
60
days,
depending
on
that
work.
B
B
You
know
some
we're
gonna
get
a
lot
of
great
ideas
coming
into
the
project,
but
we
want
to
determine
you
know
what
we
want
to
work
on.
You
know
now
versus
you
know.
What
are
we
reportin
to
the
project,
but
maybe
there's
other
things
that
need
to
be
worked
on
in
the
meantime,
I
picked
these
priority
labels
directly
out
of
the
kubernetes
project.
If
we
want
to
modify
them
or
change
them
and
and
use
wording,
that
is,
you
know
better
for
the
for
the
team
I'm
all
ears
on
this.
B
We've
got
the
kind
labels
and
we've
got
the
lifecycle
labels
that
we've
already
discussed.
Priority
label
size
labels,
triage
labels,
they're
also
some
additional
things.
For
example,
you
know
whether
or
not
this
is
a
good
first
issue
or
help
is
going
to
be
wanted
on
there.
These
are
known
and
just
about
every
open
source
project
hosted
on
github
or
something
equivalent,
and
so
we
also
want
to
you
know,
honor
those
labels
to
help
new
contributors
find
where
they
can
plug
in
and
be
useful
immediately.
B
Additionally,
this
is
a
section
that
probably
needs
some
additional
work,
but
I
wanted
to
you
know.
Currently
we
have
it
set
up
where
approvals
for
PRS
and
such
that
are
going
to
be
merged
in
the
project
are
coming
from
the
set
of
core
maintainer
x'
as
the
project
grows.
We
may
want
to
follow
a
pattern
where
you
know
we.
We
begin
to
put
owners
files
and,
in
various
directories,
that
more
explicitly
states
you
know
which
maintainer
x'
or
which
delegated
owners
are
able
to
approve
changes
going
into
into
that
area.
B
I,
don't
think
the
project
is
large
enough
yet
to
require
something
like
that,
but
that's
a
direction
that
we
definitely
can
go
so
I'm
gonna
pause
here,
I've
gone
through
a
bunch
of
stuff
and
I
just
wanted
to
get
some
initial.
Take
on
this.
What
your
thoughts
are?
You
know
it
at
initial
glance.
It
looks
fairly
heavy,
but
that's
just
because
I
think
there's
a
lot
of
areas
for
categorization
and
that
an
area
categorization
I'm,
primarily
gonna,
be
using
again
for
managing
the
roadmap
and
helping
us
to
get
some.
You
know
forward-looking
visibility.
B
A
Anyone
has
ever
used
JIRA
everything
will
be
light.
My
only
feedback
is
that
it
is
good.
There
is
a
everything
makes
sense
here.
Every
every
label
that
you
have
specified
with
all
the
contacts
may
make
perfect
sense
and
are
useful
the
only
things
that
we
should
strike
the
balance
between
what
are
the
labels
that
make
sense.
Now.
What
are
the
labels
are
to
say
that
we
can
ultimately
the
key
table
actions
because
I
am
a
is
good
to
add
some
process,
but
we
should
not
make
issue.
A
B
Absolutely
so
the
life
cycles
are
the
easiest
ones
right,
because
all
I'm
doing
is
tracking
activity
on
an
issue
right.
So
we
just
set
up
a
github
action
to
make
sure
that
we're
showing
you
know
current
activity
on
an
issue
and
if
we're
not,
then
we
can,
you
know
automatically
apply
life
cycle.
That's
the
easiest
one
for
size,
labels
on
PRS,
that's
fairly
easy!
You
know
we
can.
You
know
anytime,
a
PR
is
submitted.
We
can
do
you
know,
line
count
and
automatically
tab.
B
That
PR
is
how
large
it
is,
will
help
us
to
understand.
You
know
how
much
time
is
gonna
be
required
to
review
that
PR
to
merge
it
in
that's
pretty
easy
in
terms
of
the
triage
labels,
there's
not
a
lot
other
than
possibly
needs
information.
If
we
have,
you
know
templates
that
are
driving,
you
know
PR
and
issue
creation.
If
we're
seeing
things
that
are
missing
in
those
templates,
we
can
do
a
quick
check
with
a
github
action.
Just
to
say
hey,
you
know
you
didn't
provide
a
use
case
or
you
didn't
provide.
B
You
know,
for
example,
for
like
a
bug
you
know
you
didn't
tell
us
the
OS,
that
it
was
on
the
platform
that
you
were
on
the
version
that
we're
using
those
types
of
things.
As
long
as
we
have
a
very
specific
template,
those
would
be
useful
in
helping
us
catch.
You
know
bug
submissions
that
are
not
complete.
The
rest
of
it
is
fairly
manual
from
an
area
perspective.
B
We
we
could
identify
certain
areas
of
the
code.
For
example,
most
of
our
API
is
going
to
be
located
in
a
particular
directory,
and
if
we
see
you
know
PRS
that
are
you
know
modifying
that
area.
Things
like
API,
review
or
whatnot,
you
know,
could
be
automatically
labeled
but
again,
I
think
I
agree
with
you,
that's
probably
not
needed
just
yet,
but
it's
a
direction
that
we're,
probably
you
know,
consider
in
the
future
coming
months
and.
A
B
B
That
is
relying
on
those
labels
right
I,
don't
want
to
break
anything
by
introducing
new
labels
or
changing
labels,
and
so
for
the
most
part,
we
should
be
able
to
take
both
labels
at
the
same
time,
right
until
we
get
the
transition
occur
until
the
transition
is
complete,
but
I
just
need
to
be
aware
of
you
know
any
processes
that
are
relying
on
those
labels.
I
don't
want
to
break
those.
A
B
The
next
step,
then,
is
going
to
be
the
boards
and
the
the
the
boards
that
I
have
currently
in
mind
are
a
and
and
I
haven't
created
these
yet
cuz
I
need
these
labels
to
actually
be
able
to
create
those
boards,
but
the
the
the
boards
that
I
have
in
mind
currently
are
a
board
showing
the
current
well
first
off
before
I
get
to
that.
Do
we
have
as
a
project
a
current
notion
of
a
sprint
or
a
a
scoped
execution
period.
B
A
You
know
when
you
start
seeing
sprint.
My
brain
starts,
thinking,
agile
and
a
place
of
my
brain
says.
No,
no,
no,
please
sure
sure
yeah,
but
so,
basically,
so
far,
our
sprint
is
our
release.
If
you
want
the
thing
that
I,
don't
kind
of
you
know,
no
now
talking
is
seriously
not
joking,
since
we
have
a
fairly
short
release
cycles,
how
do
you
think
Sprint's
to
the
concept
of
a
sprint
cool
work,
because,
in
my
experience
normally
a
sprint
is
something
which
is
a
part
of
a
release
cycle.
D
B
And
we
can-
and
we
can
do
that
intra-
we
can
do
that
intro
release
as
well,
like
you
said
you
know,
or
we
right
now,
I
think
we're
trying
to
move
too.
So
that's
another
interesting
thing:
if
we're
gonna
move
the
community
meeting
to
once
every
two
weeks,
but
our
release
cycles
happening
once
every
three
weeks.
Do
we
want
to
align
that
better?
Do
it?
You
know,
especially
for
doing
backlog,
review
and
and
and
trying
to
reprioritize
issues.
A
Yeah,
why
not
I
mean
yes,
it's
surely
good
to
ever
probably
every
perspective
every
time
we
release
and,
and
then
you
know,
then
I
don't
I.
Do
I
really
don't
know
how
that
will
work
with
the
cadence
of
the
weekly
team
meeting.
But
this
is
something
that
we
can
also
discuss
on
the
mailing
list.
We
don't
have
to
decide
now.
Also
the
release
cycles
so
far
is
being
I'm
saying
three
weeks
because
it
had
printed.
It
happening
the
roughly
every
three
weeks
but
I.
A
A
D
A
D
D
B
A
B
You
know
we're
a
small
enough
project,
write
it
again,
we're
not
dealing
with
all
of
the
merge
pains
coming
in
from
a
bunch
of
different
sub
projects
right
like
what
kubernetes
would
deal
with,
and
so
there
it's
much
much
more
important
to
have
kind
of
this.
This
code,
slash
code,
freeze
period,
I
think
that
if
we
had
you
know
the
last
week
it
was
more
of
a
code
slush
or
you
know-
maybe
not
a
total
freeze,
but
at
least
we
were
we've
already
branched
and
now
we're
marching
towards
that
release.
B
So
we're
trying
to
say
no
new
feature
work
right.
Let's,
let's,
let's
try
to
our
known
feature,
introduction:
let's,
let's
try
to
clean
and
tidy
up.
You
know
the
existing
features
that
we're
working
on
in
preparation
for
that
release.
Again,
I.
We
want
to
make
maintain
agility
here.
You
know
if
we
don't
need
an
entire
week
to
do
that
and
we
come
to
find
out
hey.
We
only
need
two
or
three
days
to
do
that.
Let's
just
take
two
or
three
days
to
do
that:
let's
don't
be
ridged
that
rigid
about
it.
Yet.
A
It
depends
on
what
we
need,
how
much
time
we
need
to
for
assessing
the
stability
of
the
branches
we
are
cutting.
So
far.
Of
course,
we
don't
need
to
run
all
the
amount
of
tests
and
combos
that
kubernetes
is
running
and
for
us
it
will
be
the
time
needed
for
running
a
full
set
of
conformance
tests,
because
that's
what
we
have
at
the
moment
so
technically
one
day
will
be
enough.
Let's
make
it
two.
A
B
So
we
would
a
week
before
release,
we
would
branch
and
say
you
know
this
is
going
to
be
the
release
branch
so
that
any
so
that
their
words
other
longer-term
things
that
were
being
developed
on
master.
Those
are
not
going
to
impact,
ok,
the
release
branch
and
then
we
basically
tidy
up
anything
and
then,
after
the
release,
everything
in
the
release
branch
gets
merged
back
into
master.
D
Let's
say
you
have
a
graph
that
you
also
really
need
your
master,
because
it's
got
some
other
developments
and
you
have
to
like
merge
it
both
in
the
release,
branch
and
the
master
branch
like
right
away
before
the
actual
rees,
and
so
in
my
experience
like
until
we
have
like
automation,
to
actually
mark
those
fixes
that
need
to
go
in
both
branches
and
then
the
other,
but
actually
opening
the
poll
requests
for
you
I'd
rather
not
do
that.
Basically,
that's.
D
B
D
For
example,
I
sure
the
test
we
actually
run
on
the
release
or
actually
the
tests
we
run
I-
guess
part
of
continuous
development
right.
We
just
run
a
subset
of
community
tests
and
network
policy
tests
on
our
own
and
we
don't
do
any
extensive
testing
for
for
a
release
candidate.
So,
okay,
you
that
I
agree
that
having
a
priest
makes
perfect
sense,
but
until
then
yeah.
B
I
think
that
that's
that
sounds
like
a
perfectly
sound
approach
for
now,
and
you
know
we'll
we'll
make
sure
and
monitor
how
easy
it
is
to
track.
You
know
those
changes
as
we're
getting
closer
to
releases
and
if
we
may
need
to
make
more
of
an
automation
change
later
on,
we
certainly
can
do
that.
I
think.
D
As
we
start
introducing
more
automation-
and
we
should
definitely
start
with
labels
and
triage,
then
we
can
become
more
ambitious
and
then
streamline
and
optimize
the
tradies
process.
But
I
think
we
should
start
with
right.
I
mean
make
it
make
it
progressive
and
and
work
going
back
to
to
issue
triage,
and
you
talked
a
lot
about
it.
Aback
shion's
running
projects
like
kubernetes
tend
to
do
that
with
bots
right.
There
is
like
the
fetch
that,
but
for
a
lifecycle
and
I,
think
like
the
Probot
for
assignment
and
triage
yeah.
B
B
You
can
use
github
actions
to
basically
act
as
bots,
so
what
those
bots
are
doing.
I'll
give
you
an
example:
if,
if
we
want
to
have
certain
types
of
actions
occur
in
response
to
comments
that
have
like
a
slash
action
command
in
it
right,
so
in
kubernetes,
for
example,
if
I,
if
I
want
to
assign
something
or
if
I
want
to,
you
know,
perform
some
action
a
lot
of
times
I.
B
Do
it
within
the
comment
of
a
PR
like
like
a
slash,
lgt
M
as
in
because
is
a
really
good
one
right
that
will
then
mark.
You
know
an
issue
as
looks
good
to
me
by
you
know
an
approver
or
a
designated
code
owner.
Those
things
can
be
serviced
by
a
github
action,
because
the
github
action
is
gonna
plug
into
the
event
stream
of
github
and
monitor.
You
know
comments
and
pull
requests
and
issue
submissions,
those
types
of
things
and
then
execute
whatever
custom
code.
B
We
want
to
execute
based
on
on
that
and
that
basically
becomes
our
bot.
The
nice
thing
about
github
actions.
We
don't
have
to
write
a
separate
server
to
sit
here
and
monitor
this
event
stream
right
and
then
respond
back
via
the
you
know.
It's
all
built
right
into
github,
which
makes
it
a
lot
easier.
Is.
B
D
B
Think
there's
anything
that
we're
doing
that
is
requiring
like
a
stateful
monitoring
of
the
project
or
another
thing
is
everything
that
we're
dealing
with
right
now
is
in
one
repo
right:
we're
not
dealing
with.
You
know,
cross
repo,
monitoring
and
and
and
basically
looking
for,
merge
conflicts
and
those
types
of
things
that
are
going
to
occur
as
you
would
get
in
a
larger
project.
I
think
I
think,
since
everything
is
contained
to
one
repo,
github
actions
should
be
sufficient
for
the
time
being.
Yeah.
A
A
It
is
a
way
of
saying
a
Antonin.
This
is
a
for.
You
judge
own,
it
is
for
you
copy.
This
is
for
you
and
you
know
many
patches
about
some
article
areas,
so
it
exactly
II
automating
that
is
possible,
but
we
will
have
a
lot
of
false,
positive
and
false
negatives
problem.
You
know,
in
that
case,
having
the
automated
action
could
be
worse
than
doing
each
manual
review.
I,
agree.
D
A
A
B
What
kubernetes
does
in
there?
The
only
really
automation
they
do
around
PR
assignment,
is
on
reviews
and
they
have
a
fairly
complicated
process
for
looking
at
the
history
of
a
code
change
in
like
who
owned
different
modifications
of
that
of
that
piece
of
code,
and
they
go
back
up
to
the
tree.
Looking
for
that,
I
don't
think
we
need
anything
of
that
nature
and
it
will
just
borrow
the
kubernetes.
B
If
we
miss
some
of
the
labels
at
the
beginning,
that's
okay,
it
looks
like
let's
see,
let's
see
what
the
burden
is
and
also
remember
that
I'm
going
to
be
monitoring
this
repository
much
more
closely
as
well,
and
so
in
my
role.
I
will
try
to
try
to
pick
up.
You
know
some
of
the
burden
that
the
labels
the
labels
provide.
B
B
It's
not
my
day
job
but
I.
This
is
this
is
something
that's
going
to
immensely
helped
me
to
be
able
to
report
out
on
on
our
progress
and
to
give
an
overall.
You
know
management
view
of
how
we're
progressing,
and
so,
if,
if
you
don't
assign
labels,
I'm
gonna
be
I'm,
gonna
be
reviewing
all
the
issues
as
they
come
in
and
if
I
see
that
there's
a
label
missing
or
whatnot
I
can
I
can
definitely
assign
that
label.
Yes,.
B
I
see
what
you're
saying
so
we'll
create
a
shortlist
right
to
say:
hey,
you
know
these
are
the.
What
I
would
consider
the
essential
labels
that
we
need
to
have
on
every
issue
and
then
all
the
others
will
you
know
if
be
optional
for
the
time
being
and
if
you
want
to
take
the
time
to
go,
assign
those
great
if
I
come
along
and
and
review
and
triage
those
issues
coming
in
I
can
add
some
additional
labels,
but
I'll
at
least
try
to
create
a
shortlist
as
great
feedback.
I'll
create
a
short
list
of
the.
C
B
Other
questions,
so
so
what
I
was
alluding
to
earlier?
The
only
thing
I
didn't
cover
yet
are
the
board's
Anton.
You
you'd
mentioned
that
so
again
on
the
boards.
What
I'm
trying
to
accomplish
there
is
I
want
to
show,
within
the
current
release,
what
things
that
we've
scheduled
in
our
in
progress,
so
we
at
least
have
a
an
idea
on
the
completion
of
the
current
release.
B
I
also
want
to
have
a
board
showing
where
we
stand
in
various
functional
areas,
in
terms
of
a
feature
completeness
of
the
product
or
or
or
of
our
roadmap
and
and
then
finally,
I
want
to
have
a
board
showing
how
the
various
contributors
are
loaded.
In
terms
of
you
know,
if,
if
Anton
ins
getting
assigned,
you
know,
80%
of
the
issues
based
on
area
or
whatever
I
want
to
be
able
to
have
at
least
a
board
that
gives
us
some
visual
indication
of
of
the
issue
load
being
carried
by
the
different
contributors
on
the
team.
C
C
C
B
Sounds
good
and
then,
if
we
come
up
with
some
other
boards
that
are
useful
for
us,
you
know,
for
example,
I'll
probably
have
a
board
showing
lifecycle
of
like
like
what
which
issues
have
come
up
a
stale.
You
know
or
rotten.
You
know
those
are
going
to
be
some
really
useful
things
for
us
to
take
a
look
at
a
peek
at
every
so
often
just
so
that
we
we
can
keep
track
of
that.
B
B
E
Related
note,
I
was
wondering
if
you
guys
have
thought
about
any
any
sort
of
way
for
proposals
like
today.
What
we
do
is
that
we
end
up
for
any
feature
proposals
the
end
of
this
grading
of
Google
Docs,
with
some
formal
structure
and
Hanneman
relating
to
the
issue
and
hold
it
standardized
away
for
proposals,
because
I
assume
that
there
will
be
a
lot
of
more
proposals
coming
in
and
in
a
way
for
us
to
be
able
to.
You
know,
review
them.
B
B
I'm
not
opposed
to
creating
a
design
folder
to
hold
those
markdowns
and
then
doing
an
issue
linked
to
those
I
think
that
there
should
always
be
an
issue
associated
with
any
type
of
a
new
proposal
coming
in
or
a
new
design
coming
in.
But
there's
a
there's
a
I
just
want
to
make
sure
that
we
have
a
distinction
between
design
and
feature
right
like
a
feature
is
kind
of
like
a
unit
of
work
that
you
know,
we
can
actually
classify
work
around
where
design
has
to
do
more.
B
B
And
this
is
I
love
feedback
from
the
team
on
this
right,
I'm
not
opposed
to
Google
Docs.
The
the
question
I
have
is:
do
we
want
do
we
want
to
use
Google
Docs
to
actually
develop
those
designs,
or
do
we
want
to?
You
know,
use
markdown
and
put
it
all
on
the
repo
and
kind
of
go
through
the
PR
process.
The
nice
thing
about
the
PR
process
is
we
capture
comments
and
everything
kind
of
all
in
one
place
as
the
design
as
being
developed.
B
A
B
C
A
You
know
I'm
asking
because
we
know
that
we
already
have
contributors
in
China
and
the
China
is
a
very
active
area
generally
in
the
kubernetes
ecosystem.
I
am
afraid
that
using
Google
Docs
might
create
a
barrier,
but
it
we
need
to
start
from
somewhere,
so
we
can
start
with
Google
Docs
and
when
we
figure
out
a
better
solution,
we
can
do
that.
I.
Remember
that
in
the
past
we
have
used
a
gallery
for
that,
just
because
we
will
be
working
on
OpenStack
projects
and
they
were
using
direct
for
everything.
A
It
was
kind
of
ok,
but
writing
a
text
document
review
in
text
documents,
plain
text
documents
for
everything
might
be
a
little
bit
tiring.
So
that
is
another
option
anyway,
but
in
my
opinion,
it's
OK
to
start
with
Google
Docs
and
then,
if
we
want
to
feel
find
an
alternative
which
is
more
accessible.
We'll
do
that
also.
A
The
future-
and
this
means
in
the
future,
when
we
will
have
a
lot
of
feature
proposals
for
Andrea.
We
will
probably
probably
end
up
adopting
the
same
approaches
kubernetes
the
cap,
where
basically,
you
use
Geeta,
Geeta
previews
for
reviewing
design
themselves
and
basically
to
markdown
you,
you
use
the
reviewing
system
for
commenting
and
basically,
you
can
write
fairly
complex
documents
using
markdown.
That.
D
D
B
Why
don't
we?
Why
don't
we
take
this
approach?
I
mean
proposals,
are
not
all
gonna
make
it
through
right,
so
we
may
end
up
rejecting
them,
so
initially
create
it
using
your
favorite
productivity
tool.
If
it's
Google
Docs
that's
great,
once
we
get
to
more
of
a
an
agreement
by
the
by
the
team
that
hey
this
is
this
looks
good.
This
is
a
design
that
we
want
to
go.
Then
we
can
migrate
that
into
a
markdown
or
whatever
we
need
to
do.
That's
not
gonna
be
a
hard
thing
to
do.
A
Okay,
we
can
think
about
it.
Yeah
we
can
I
mean
I,
understand
the
point
understand
you
know.
The
value
in
your
proposal
is
that
this
will
allow
us
to
also
get
the
documentation
for
free.
The
problem
is
that
the
actual
implementation
often
ends
up
being
different
from
the
initial
design,
so
you
need
to
keep
them
in
sync
agreed.
B
D
So
there
are
only
like
five
more
issues:
tagged
with
0.3
dotto
release.
We
remove
the
we
abandon
a
few
already
like
knowing
a
proposal
we
postpone.
It
would
consider
to
the
next
really
so
I
think
we
should
just
go
over
those
and
and
see
what
we're
able
to
make
like
today
to
close
on
today
or
tomorrow.
Basically
and
the
rest,
we
should
send
it
to
the
next
release.
D
C
C
D
D
F
D
B
F
D
D
Okay,
next
is
exposed
logs
publicly
for
Jenkins
CI
job,
so
this
is
not
needed
for
the
release.
I
just
tagged
it
with
this
release
because
to
give
us
like
a
timeline,
basically
at
this
stage,
so
for
the
background
we
we
run
those
Jenkins
CI
jobs
to
run
like
community
tests
and
community
conformance
and
that
whole
policy
test
on
every
TR,
and
at
this
stage
we
report
the
status
back
to
github.
D
If
your
job
fails
at
this
time,
it's
impossible
for
you
to
afford
contributor
to
actually
visualize
the
logs
and
even
see
which
test
exactly
failed
and
that's
because
those
jobs
or
run
on
VMware
servers
which
are
not
like
exposed
publicly.
There
is
no
like
HTTP
public
HTTP
endpoint
for
you
to
visualize
the
logs,
so
some
contributors
in
China
working
on
this
from
some
contributors
from
VMware,
but
we're
still
having
like
issues
like
opening
up
a
port
and
letting
people
visualize
the
logs.
So
it's
not
available
right
now.
I
think
we're
making
progress.
D
D
The
next
two
issues
or
about
entry,
a
CLI,
so
we
have
the
entry
interest
yet
I
emerged
in
already.
So
it's
going
to
be
part
of
the
release.
We
don't
really
have
any
useful
command
at
this
stage
and
I
think
if
we
have
five
minutes
left.
Yes,
I
wanted
to
bring
an
issue
up
here
and
see
what
people
think.
So
the
plan
was
to
start
distributing
like
the
NC
TL
CLI
binaries.
E
D
Cuba
CTL,
so
the
plan,
starting
with
this
release,
was
to
also
upload
like
the
CLI
binaries
for
different
architectures,
so
that
people
can
just
download
it
directly
like
like
they
can
download
cubes
ETL
the
problem
at
this
stage.
Is
we
really
don't
have
any
useful
commands
that
you
see
I
can
run?
There
is
an
open,
TR
I
assure
you.
D
There
is
no
Pantheon
PR
this
one
that
Apple
is
gonna,
be
merged
soon.
That
lets
you
like
collect
information
about
the
else
of
the
agent,
but
one
issue
is
that
at
this
moment
the
only
way
to
run
this
command
is
to
run
the
CLI
directly
from
within
the
agent
pod,
because
it's
using
a
unique
domain
socket
and
there
is
no
like
HTTP
endpoint,
which
is
open
outside
of
clusters.
So.
D
D
B
B
B
B
D
A
D
It's
just
gonna
come
and
it
kind
of
ties
back
to
the
last
issue
years.
That
was
tagged
with
0.3,
which
is
like
there
is
no
user
facing
documentation
of
the
CLI
right
now,
so
the
CLA
azuz.
Basically
things
work
directly.
What
differently?
Based
on
whether
you're
running
the
CLI
from
within
the
agent
pod
or
from
outside
the
cluster?
Not
everything
is
available,
and
so
that
may
be
confusing
to
some
users.
I
think
we
should.
We
should
get
that
documentation
in
place
and
start
distributing
the
binaries
and
advertise
in
Israel.
D
E
The
last
week
we
put
some
package
there
to
open
new
PRS
for
them,
one
on
the
controller
side,
one
on
DG's
inside
so
I,
think
controller
and
channes.
Also
the
city
controller
side
and
is
the
agent
side
is
built
on
top
of
it
and
when
I
last
spoke
to
him
just
tonight,
he
said
that
he
was
going
to
end
to
end
test
today
in
other
regions
in
his
Beijing
time.
To
do
it
end
to
end
just
put
the
punches
and
so
yeah.
They
are
ready
for
review,
so
he
is
free
to
his
comments.
E
A
And
I
don't
have
any
update
on
dual-stack
unfortunate
was
a
busy
weekend
and
no
progress
could
be
made.
The
only
thing
that
I
wanted
to
mention
is
that
there's
been
an
update
on
the
mailing
list
regarding
the
upstream
into
our
stock
exchanges,
and
this
is
a
mean
on
the
kia
test.
Signet
work,
meaning
list.
It
seems
that
the
update
is
criteria.
I
wanted
to
answer
as
well,
so
we
should
probably
all
have
a
look
as
well
and
see
anyone
take
stock
of
the
changes
that
are
happening
upstream.