►
From YouTube: 2017 07 06 08 07 36 Apache Mesos Community WG 234540281
Description
First meeting of the Community Working Group
Agenda and Notes:
https://docs.google.com/document/d/1vgi434dYkkZHs49EK4F4eMmM-3JG4f3qg-N5En-4ubg/edit?usp=sharing
B
A
C
A
B
Okay,
so
I
guess
the
first
bit
was:
what
do
we
want
this
community
group
to
tackle?
What
is
our
Charter
at
least
I?
Think
the
mission
as
a
propulsion,
the
email
was.
We
want
this
group
to
kind
of
facilitate
how
we
want
to
grow
the
community.
So
does
everyone
agree
with
that
mission
or
do
we
want
to
change
the
mission
or
something
like
that,
as
it's
unlikely
mission
to
have
yeah.
D
E
B
A
B
There's
a
lot
more
content
in
there
then
I
remember
a
test,
so
does
that
one
sound
good
for
everyone,
because
in
a
reasonable
thing
to
have
not
so
I
guess
not
just
growing
the
side,
but
also
including
the
experience
for
people
in
the
community?
We
don't
want
to
have
a
big
committee
with
values
of
experiences
as
well:
I,
guess,
okay,
so
for
the
Charter.
B
E
E
Yeah
he
recommended
like
this
week
in
Apache
Mesa,
something
like
weekly,
maybe
I,
don't
know
how
often
we
might
want
to
do
it,
but
I
do
think
that
just
some
kind
of
regular
content
being
presented
by
the
community
to
kind
of
advertise
just
what's
been
happening.
The
contributions
that
have
been
occurring
it
could
help
people
just
keep
that
stuff
in
mind
and
remind
people
of
what's
going
on
so
that
they
remember
that.
There's
something
they're
interested
in
checking
out
or
commenting
on
a
design,
doc
Kristin
patches,
yeah.
D
B
Mean
we're
in
charge
of
blogs
for
our
website
for
a
long
time,
and
if
you
have
a
weekly
or
even
bi-weekly,
cadence
of
like
a
newsletter
kind
of
blog
post,
there
I
think
that
would
be
really
cool
like
how
would
we
actually
go
about
I
guess
building
that
newsletter
like
who
would
that
be,
like
one
person
responsible
to
do
it
or
how
would
we
structure
it?
The.
E
Way,
I
was
imagining.
It
was
to
kind
of
try
to
distribute
the
workload
so
that
maybe
all
committers
could
kind
of
report
on
the
work
that
they've
been
shepherding
and
the
things
that
they've
been
collaborating
with
people
on
and
provide
just
like
quick
blurbs
of
a
couple
sentences
to
someone
who'd
like
a
grits
this
into
a
blog
post.
You
know
so
hopefully
it
wouldn't
require
too
much
work
for
any
single
person.
E
E
Them
yeah
I
mean
I,
guess
that's
one
approach.
Another
approach
might
be
to
rotate
it
between
people,
but
having
a
point
person
might
make
it
more.
Reliable
I
was
just
trying
to
imagine
a
way
that
I
would
be
comfortable
with
actually
to
you
know,
because
if
it's
like
a
big
time
commitment,
then
I
don't
think
I
or
anyone
else
would
want
to
commit
to
actually
every
other
week
composing.
Some
like
significant
document.
A
And
wonder
how
much
like
how
much
mean
I
wonder
if
or
envisioning
something
where
we
just
like,
send
out
links
to
a
bunch
of
things,
so
each
commuters
committer
says
like
I
worked
on
this
or
the
link.
If
you
want
more
info,
I
worked
on
that
here's!
The
link,
if
you
want
more
info,
if
we're
thinking
more
of
like
having
descriptive
content,
because
I
think
that,
like
I
depend
how
many
committers
are
there,
we.
A
B
Yeah
I
don't
know
if
every,
if
it's
not
if
it
just
like
links
to
things
that
they're
working
on
I,
don't
think
that
would
be
that
useful,
I
agree.
I
think
we
want
to
call
out
some
I
guess
important
things
that
happened
at
the
end
of
this
tent
or
something
I
mean
yeah.
We
have
a
print
at
least
by
littlest
print.
So
we
could
probably
summarize
what
happened
in
that
sprint.
E
Then
it
could
be
up
to
the
person
bringing
the
content
together
to
select
what
to
report
on
and
not
necessarily
to
include
everything
and
it's
possible
that,
instead
of
just
providing
like
a
link
to
a
G
or
something,
the
people
involved,
could
compose
a
couple
sentences
on
what
they
merged
and
what
it
does.
Or
what
they've
been
designing
and.
B
B
E
E
E
F
F
B
Instead
of
yeah,
but
it
should
be
the
same
group,
people
I
think
so
they
could
feel
ownership
operating
if
it
keeps
yeah
rotating
them
on
different
people.
I
think
it's
going
to
be
inconsistent
for
one
like
the
quality
and
how
they
want
to
do
it
and
no
one
will
see
low
ownership
of
getting
it
done.
Yes,.
E
F
B
C
B
C
B
Content
going
to
be
so,
one
thing
we
talked
about
is
like
project
status
like
what
different
projects
are
being
worked
on
and
we're
having
our
Shepherds
for
status
of
the
projects,
and
then
you
talked
about
Mesa
font
like
what
else
do
we
want
to
see
in
that
newsletter?
It
is
that
enough
to
start
with,
or
do
we
want
other
stuff
like
what
are
other
work
groups
working
on
and
stuff
like
that,
or
is
it
too
much
I.
C
B
Okay
select
the
event
so
there's
thing
about
the
events
and
projects:
ok,
the
projects
and
events
that
should
be
good,
start
yeah.
Let's
see
how
much
effort
it
takes
if
it's
take
make
too
much
of
a
benefit,
how
to
like
minimize
their
foot
and
by
the
editors
and
the
people
involved
to
produce
content
as
well.
We
just
yet
another
thing
that
people
have
to
do
say
to
a
nice
if
it's
less
touch,
yeah
low
touch,
I
guess
so.
E
B
E
B
We
can
use
this
meeting
to
talk
about
that.
If
you
don't
want
on
another
meeting
to
talk
about
it,
it's
totally
up
to
you
guys,
but
because
we
have
one
hour
slot.
So
we
could
use
some
time
in
this
meeting
to
talk
about
like
15
minutes,
10
minutes
or
whatever
it
takes.
Okay,
yeah
I,
don't
want
I
mean
yeah.
We
don't
want
people
have
too
many
meetings.
Yeah.
E
F
F
F
E
B
That's
unreasonable,
yeah,
yeah,
well,
I.
Think
one
thing
that
might
work
is
for
us
for
the
group
to
actively
work
with
the
committers
like
actually
pinging
the
commuters
for
content
and
for
just
contributors,
we'll
just
have
the
link
posted
somewhere
in
the
dev
list,
reminding
them
to
put
stuff
if
they
want
something
to
be
shown
or
showcased.
Basically,
that's
way,
like
kind
of
where
it
is
not
like
actively
you're
not
reaching
out
to
them
person
by
person,
which
is
sending
a
link
and
saying
hey,
put
something
up
here.
B
If
you
want
it
to
be
go
into
a
community
with
committed,
shitcan
working
more
closely
actively
to
get
content
out
of
them,
because
the
other
people
who
are
always
almost
busy,
so
we
want
to
work
with
them
to
get
the
content
out,
yeah
cool.
That
sounds
good.
Let's
see
how
that
goes,
it
sounds
exciting
and
we
have
made
content
for
the
blog
post.
So
so
what
what
else?
So
we
had
a
community
CI
stuff,
but
before
we
go
to
that
specific
one.
What
other
things
should
we
tackle
as
part
of
this?
B
F
There
was
once
a
discussion
in
the
Chinese
which
I
group
there.
People
are
talking
about
using
github
instead
of
review,
board,
uh-huh
and
I
know
it's
something
big
and
just
wonder.
I
just
want
to
collect
some
thoughts
like
what
people
think
about
it,
because,
basically,
before
complaining
that
I'll
patch,
you
way
no
not
populate
that
appache
tool,
schooling
target
low
in
terms
of
contributing
like
yeah
I,
have
a
small
fix.
I,
probably
just
want
to
send
a
PR
on
github.
F
B
A
B
B
B
B
Yeah
I
think
we
should
change
this
to
basically
say
if
you
have
a
small
patch,
you
don't
need
to
go
through
all
of
this
I
think
it
should
be
more
like.
Maybe
if
you
are
like
a
beginner
like
a
newbie
into
the
into
the
community,
just
you'll
get
a
PR,
because
it's
likely
that
you're
going
to
just
send
something
very
small
and
if
you're
sending
something
substantial,
please
create
the
review
board.
A
Content
sandhya.
F
B
F
B
Think
if
we
have
to
work
with
them
to
give
us
the
right,
permissions
and
stuff
but
I
know
it's
Park,
for
example,
I
think
they
use
github
exclusively
for
their
reviews
and
it's
an
Apache
project
as
well,
but
I
think
those
were
for
the
only
one
that
I
know
of
in
SF
that
you
github
for
reviews.
And,
lastly,
and
we
asked
SF,
they
said
it's
like
a
pilot
project
other
they
try,
not,
which
part
to
see
if
they
can
have
them
use.
B
Github
I
mean
that's
that
even
today
we
can
actually
just
use
github
if
you
want
to,
because
all
we
don't
have
is
the
ability
to
directly
merge
PRS
into
the
code
which
you
don't
want
to
anyway
yeah.
So
once
a
peer
is
accepted,
we
can
still
the
computers
could
still
use
our
tooling
apply,
reviews
tooling
to
apply
the
Gator
PR
locally
and
push
it,
and
that
closes
the
PR.
B
So
there's
an
S
of
get
squad
that
goes
intro
disappear.
So
technically
would
still
do
this
because
we
could
today
actually
have
people
submit
tiers.
You
do
all
the
reviews
and
once
it's
in
a
good
state,
we
say
it's
good
and
then
we
use
applied
reviews
to
apply
that
PR
locally
and
push
it
into
a
repo.
So
that
should
still
work.
We
don't
even
have
to
once
potatoes
of.
If
we
really
want
to
do
that,
yeah.
F
B
B
B
What
about
CI
like?
Should
we
be
talking
about
how
I
think
we're
going
to
have
couple
talk
about
the
community
and
stuff,
so
that
kind
of
already
tells
me
that
there
is
some
interest
in
the
people
join
this
group
to
talk
about
how
we
do
CI,
how
we
can
improve
the
CI
infrastructure,
tooling
and
stuff
like
that,
so
see
if
he
has
something
that
we
would
we
should
be
talking
about
in
this?
B
E
Yeah
I
guess
the
extent
to
which
it
improves
community
experience
it's
relevant,
but
I
guess
it
improves.
It
seems
more
like
it
improves.
You
know,
CI
is
critical
for
the
experience
of
like
maintained,
errs
and
committers,
but
as
far
as
people
working
on
contributions,
I
guess
something
like
review
bot
is
their
primary
interaction
with
the
CI
system.
Right
yeah.
B
Yeah
yeah
I
think
when
I
talked
with.
She
is
mostly
about
like
here
the
review
board
and
the
bill,
so
Lewis
winded
when
they
submit
something
and
they
come
to
commits
it
and
if
it
breaks
to
build
a
billboard,
is
the
one
that
tells
them
that
they
broke
it
and
they
kind
of
have
to
know
that
okay,
they
broke
the
build
because
they
didn't
check
this
stuff
for
something
a
test
this
correctly
or
didn't
do
enough
replications
of
the
test,
so
that
can
give
some
feedback
like
CI,
gives
them
feedback
on.
If
they
do.
B
Some
like,
if
contributor
makes
a
mistake,
that's
one
of
the
ways
that
they
they
can
catch
it
it's
through
CI.
Another
thing
that
I
was
more
interested
in
the
CA
was
perspective
that
we
had
a
lot
of
questions
on
the
community
previously
about
having
distribution
packages
like
rpm
steps
and
stuff
like
that
which
the
project
traditionally
shied
away
from
producing.
B
So
as
this
working
group
we
can
talk
about,
should
we
actually
start
producing
this
packages?
Should
we
own
that
part?
Should
we
upload
them
officially
into
bin
tray
or
somewhere
some
other
pilots
do
so
that
it
includes
the
committee
experience
because
I
know
that
a
lot
of
people
have
asked
for
it
for
a
long
time,
but
why
doesn't
a
suspicious
project
itself
own
and
publish
binary
artifacts?
We
only
publish
source
artifacts
should
and
they're
always
asking.
Why?
Don't
we
publish
rpms
and
Deb's
say
that
something
we
should
own
or
not,
I
think
that's!
B
B
I
would
rather
want
them
to
adjust
to
the
brew,
install
my
source
or
apt-get,
install
SS
from
location,
and
that's
like
one
minute
tank
instead
of
making
it
build
for
like
40
minutes
and
then
thankful
all
the
tool
bit
that
need
to
install
to
get
the
build
going.
That's
I
think
it's
a
horrible
experience
for
people
coming
into
a
project.
I
think
that
gives
that
leaves
a
bad
taste
I.
D
B
E
B
E
E
B
Yeah
I
I
think
that
does
make
sense
yeah,
so
we
can
put
package
in
that.
So
the
other
thing
that
I
wanted
to
chat
was:
do
we
want
like
the
release
process,
to
be
tackled
by
this
group,
or
is
it
something
that
we
need
to
be
the
new
type
of
somewhere
else
like,
for
example,
we
have
already
had
questions
about
slipping
release
dates
and
how
do
we
want
to
decide
when
something
is
a
blocker
for
the
release,
and
are
we
really
doing
time?
B
C
B
Good
something
else
really
affects
the
community
at
large,
but
that's
something
that
I
think
commit
in
somewhere,
because
that
kind
of,
besides
the
cadence
of
the
releases
and
stuff
like
that
that
commit
is
when
I
get
from
Apache
mesas
project.
So
we
can
talk
about
how
we
can
improve
our
release
process.
How
can
input
the
live,
cadence
and
pod
and
stuff
like
that?
Do
you
think
that's
like
relevant
or
now?
What
do
you
think
I
think.
A
It's
the
same
as
CI
like.
Is
this
a
point
where
the
community
is
interacting
with
a
release?
If
it's
about
like
how
are
we
gonna,
like
estimate
dates,
so
that
the
community
can
have
a
realistic
idea
of
when
things
are
going
to
come
out
up
like
probably
really
relevant
here,
and
if
it's
more
about
like
how
committers
are
going
to
deal
with
things
or
the
process
of
it,
I
think
it
might
be
better
for
a
more
technical
group,
yeah.
D
A
B
What's
going
to
get
into
a
release
in
upcoming
release
or
whatever
it
is
that
we're
planning
to
work
on
I?
Don't
think,
there's
a
really
good
sense
on
the
community
until
it
happens
like
once
this
one,
the
release
code,
node,
that's
when
they
see
the
change
log
and
see
okay.
This
is
all
the
things
that
are
coming
and
we
have
like
a
JIRA
which
have
some
fixed
versions,
but
we
don't
really
do
like
a
good
job
of
communicating
it
out.
I.
Think
like
like
we
don't
talk
about
head.
These
are
things
that
are.
B
We
are
planning
to
work
in.
This
release
are
expecting
to
come
to
work
in
release.
I
mean
they
might
not
make
it,
but
at
least
we
started
off
with
saying
hey.
These
are
things
that
you
think
we
should
learn
in
this
release
and
if
the
other
things
that
you
want
to
start
having
this
release,
please
add
this
to
the
Giro
or
whatever
is
the
way
kubernetes
does
it.
B
They
have
like
a
dot
like
a
spreadsheet,
with
like
features
that
they
want
to
get
in
upcoming
release
and
the
workgroups
responsible
for
it
and
the
owners
for
that
particular
feature.
So
they
are
when
the
release
time
comes.
They
release
are
working
with
those
folks
to
get
updates
and
do
bundle,
meetings
and
stuff
like
that.
B
I
think
our
it
is
a
little
more
opaque
to
the
community,
as
you
like
so
I,
think
making
it
more
transparent
would
be
nice
and
I
think
we,
as
committee
group,
could
actually
facilitate
that
to
actually
communicate
via
blog
post
or
maybe
just
an
email
or
with
a
running
spreadsheet,
or
we
just
use
JIRA
but
have
a
dashboard
in
the
JIRA
that
tells
hey.
These
are
things
that
we
are
planning
to
work
on,
for
the
delese,
take
a
look
at
it
and
having
since
GRS
or
source
of
Clematis
lj0
I.
B
Don't
know
why
we
have
to
use
spreadsheets
I,
guess
communities
have
to
use
because
they
don't
use
0,
that's
the
way
of
planning
it.
But
since
we
use
JIRA,
we
could
create
a
nice
dashboard
that
shows
based
on
the
target
versions.
What
are
the
big
epics
that
are
coming
in,
and
just
just
basically
communicate
it
little
more
effectively
before
the
release
plan
and
the
release
planning
process,
like
hey,
Mitch,
I,
think
that
you're
thinking
we
should
we
should
tackle
in
this
release
and
then
yeah.
E
I
think
I
see
two
points
like
two
different
efforts.
One
is
to
produce
this
content,
like
maybe
it's
a
JIRA
dashboard
and
the
other
is
to
get
the
word
out
about
that.
So
we
could
do
that.
I
think
we
could
that
in
our
newsletter,
and
we
could
also
send
an
email
and
I
think
that's
a
great
idea
to
let
people
know
ahead
of
the
release
what's
being
worked
on
and
also
get
input
and
then
also
announced
once
a
release
is
out,
you
know
what
ended
up
landing
cool.
B
B
Yeah
yeah
yeah
it's
most
about
yeah
communicating
what
really
this
here
like
this
communication
like
before
and
after,
but
before
it
happens,
and
after
it,
how
do
we
I
mean
I?
Don't
think
we
do
a
good
job
about
talking
about
our
features
in
their
blog
post
manner.
Up
for
release,
we
just
pasted
our
change
log,
pretty
much
into
our
release,
blog,
which
is
okay,
but
it's
like
a
bit
not
that
great.
It's
not
that
exciting.
B
B
To
do
user
dogs
I
get
you
in
about
Lily's
blog
posts,
so
that's
going
to
be
like
a
tall
order
to
try
to
improve
it,
but
I
think
if
you
can
figure
out
a
process
around
that
I
think
that's
something
that
we
could
do
as
well.
Group,
128
or
hey
you
working
on
a
feature.
This
is
something
that
you
should
do.
Let's
just
write
a
blog
post
will
help
you
write
it
or
something
like
that.
B
E
A
B
Percent
community
meetings-
we
are
totally
like
this
work.
Good
committee
meeting
will
have
yeah
I
think,
there's
some
point
rate
in
the
last
day
of
meeting
deaf
sync
meeting
was
you
will
have
mobile
group
face-to-face
workgroup
meetings
at
missus
cons,
I
think
they
said
this
is
one
other
work.
Groups
I
think
totally
makes
sense
that
we
will
have
this
meeting
at
that
point.
Mrs.
Cottam
it'll
be
great.
D
H
H
We
want
to
make
sure
that
it
builds
with
all
these
different
combinations
that
we
want
to
support
like
SSS
support
or
C,
make
or
other
tools
and
verbosity
and
so
on,
and
then
also
do
it
on
the
different
distros
that
we
want
to
support
like
CentOS,
Ubuntu
and
so
on.
So
one
of
the
completing
features
today
in
our
review,
bots
is
the
fact
that
it
cannot
run
route
test.
H
It
has
happened
in
past
where
some
of
the
contributions
were
made.
They
were
reviewed,
accepted
and
merged
into
master,
and
then
we
realized
it
is
perfect,
and
so
this
is.
This
is
basically
the
biggest
change
that
we
are
hoping
to
get
from
from
this
piece
of
work.
So
what
we
want
to
do
is
instead
of
using
containers
as
we
use
today,
for
building
and
building
the
river
requests.
H
We
want
to
use
virtual
keys,
and
these
BMS
will
be
hosted
on
some
of
the
newer
machines
that
we
will
be
donating
to
the
ASF
CI,
which
will
be
missiles
only
or
will
be
used
for
missiles
bills
only
and
that
way
in
those
in
those
virtual
machines.
We
can
basically
then
use
the
root
test.
The
root
tests
also
have
the
problem
where
they
can
actually
leave
some
stale
State.
H
Of
course,
in
order
to
improve
on
those
things,
we
can
use
C
cache
or
things
like
that,
and
that
will
potentially
help
speed
up
the
bills
and
not
actually
hog
down
the
hole
contribution
pipeline
by
working
on
the
requests
being
those
by
the
bottom.
So
on.
So
that's
that's,
basically
more
or
less
the
the
idea
about
around
building
the
request
in
this
in
this
contact.
Is
there
any
particular
question
around.
B
A
H
H
H
Is
considering
donating
of
few
machines
to
the
CI
effort
and
then
it
will
be
like
these
machines
that
we
donate
will
be
basically
reserved
in
some
sense
for
missus
only
bills,
and
this
would
be
like
cloud
med
cloud
instances
or
orders.
So
these
will
be
like
easy
to
or
GC
or
whatever
like
it.
The
details
have
not
been
figured
out
yet,
but
they
will
become
old
machines
which
should
be
deleted,
but.
B
H
Are
like
we
will
bring
them
up
and
set
all
the
infrastructure
on
the
machines
and
then,
like
I,
guess,
get
some
authorization
keys
from
the
ESS
Jenkins
and
let
these
guys
connect
the
single
design.
I,
don't
know
the
exact
details
along
those
front
is
just
something:
I
had
recently
started.
The
other.
H
About
packaging,
so
the
packaging
is
more
I.
Guess
like
a
little
more
towards
the
end
user.
There
people
have
been
complaining
in
past
about
certain
packages,
package
features
not
available,
or
also
in
general,
about
them
being
posted
on
this
query
pose
and
so
on.
So
the
change
the
requested
change
there
is
that
we
would
want
to
do
two
full
things
one
is
for
hosting.
H
So,
instead
of
for
mesosphere
posting
the
packages
we
probably
want
to
move
on
to
using
venturi
Apache
already
has
a
venturi
account,
and
hopefully
we
can
get
an
Apache
like
a
missus
underneath
the
Apache
umbrella
or
there
that's
a
free
of
free
hosting
service
that
we
can
use,
and
basically
they
also
provide
the
repos
so
rpm
and
Debian
repos
for
different
destroyed
and
so
on,
and
people
already
have
been
using
Pinterest
on
BOTS.
So
it's
kind
of
is
an
add-on
for
them
to
just
add
actually
program
they're,
like
the
trusted,
keep
and
so
on.
H
H
Maybe
we
actually
use
the
native
packaging
scripts
like
spec
files
for
CentOS
and
so
on,
or
the
Debian
folders
for
401
to
Debian
packages.
When
we
have
that
the
package
is
more
native
and
at
that
point
you
can
basically
also
have
a
source
game
instead
of
just
having
a
binary
at
VM.
So,
if
want
to
say
target
a
different
of
different
version
of
tentacles
or
a
different
federal
version,
then
you
can
just
use
the
slpm
and
is
the
package
locally
and
so
on.
So
these
are
the
two
major
bits
in
there:
the
the
native
packaging.
H
It's
about
trickier
I,
like
I,
was
working
on
it
in
the
witches
and
at
some
point,
I
had
it
working
for
CentOS
and
with
partial
success
for
Debian
as
well.
But
it
wasn't
in
the
polish
to
us
and
so
I
would
I
think
if
someone
else
is
actually
willing
to
help,
then
we'll
just
publish
it
as
is,
and
then
actually
go
it
and
iterate
it
from
there
yeah.
B
B
I
can
create
tickets
for
the
packaging
part,
and
maybe
even
the
community
see
I
also
so
that
people
could
just
see
that
it's
happening,
and
maybe
we
could
include
it
in
the
newsletter
that
comes
along
and
people
can
see
that
all
this
is
happening
and
these
are
the
tickets
and
they
could
join
that
effort.
And
you
can
also
send
an
email
to
the
devilish
saying,
hey
I'm,
interested
in
helping
me
out
with
packaging,
and
there
might
be
some
people
who
are
already
familiar
with
that
stuff
and
who
can
chip
in
yep.
H
Also
one
of
the
other
things
that
I
should
be
adding
while
we
are
talking
about
the
CI
and
packaging
is
nightly,
or
you
know,
publishing
of
the
daily
jar
files.
Sometimes
we
have
our
photos
changed,
and
then
there
are
other
people
who
are
actually
taking
this
book
off
of
the
trunk.
Uh-Huh
sometimes
would
want
to
actually
not
build
missiles
like
people
who
are
writing.
The
schedulers
saying
like
respond
to
grab
the
latest
jar
which
has
little
photos
and
so
on
so
like
automating.
All
of
that
will
basically
help
quite
a
bit,
but
that.
H
F
So
for
C,
I,
actually
Joe
second
capo
or
both
here
we
talked
about
how
major
module
C
is
as
well.
I
can
put
build
Maysles
against
different
modules
so
that
we
make
sure
the
API
doesn't
break
it.
So
is
that
that's
still
part
of
plan
and
it's
my
first
question.
The
second
one
is
a
couple
of
weeks
ago.
We
had
this
internally
IBM.
They
are
trying
to
figure
out
how
to
run,
makes
its
own
power
machine
and
they
find
out
the
power.
C
is,
is
disabled
and
they
actually
a
message
to
the
are
meaningless.
H
Norris
and
about
the
the
modules
part
I
think
once
this
part
is
done,
we
will
basically
hook
up
the
e.r,
so
I
can
get
a
few
troubles
in
there
before
we
actually
look
it
up.
One
is
that
right
now
we
still
don't
have
the
the
full
enablement
of
like
a
central
repository
for
modules.
That
was
on
the
plan,
but
it
actually
fell
through
the
cracks,
and
so
that
basically
means
that
we
don't
quite
know
what
modules
to
actually
build.
H
So
a
different
approach
would
probably
be
to
have
a
different
or
a
separate
CI
for
modules
we
actually
kicks
in,
say
nightly
or
with
every
missus
bill,
and
then
bill
I
have
some
instructions,
whether
we
actually
catch
and
build
the
modules
and
then
provide
a
descent
failure,
but
basically
leave
the
the
requests
untouched.
For
that
matter.
This
should
be
somewhat
also
gonna
to
eat
few
bills.
I
guess
that
means
yes,
yeah.
B
I
think
maybe
this
topic
is
probably
little
more
outside
cover.
The
community
working
group
I
think
it's
good
that
we
brought
it
up,
but
I
think
we
should
probably
have
a
different
meeting
to
kind
of
go
into
the
details.
The
technical
details
about
the
implementation
of
set,
but
from
the
users
perspective
I
think
what
they
need
to
know
is
this
something
that's
coming,
and
this
is
what
they're
going
to
get
and
like
they're
gonna
get
snapshot
bills,
they're
going
to
get
binary
packages
moving
forward
and
the
pilot
is
going
to
own.
B
It
I
think
that's
the
biggest
piece
that
they
want
to
know
from
the
committee
perspective
that
make
sense
or
cool.
So
we
have
a
two
minutes
left
any
other
things
that
we
should
tackle.
What's
in
our
charter,
so
we
talked
about
reviews.
We
are
covered
about
release
communication.
We
talked
about
newsletter
because
saying
what
else
should
we?
What
about
like
reviews
or
JIRA,
like
JIRA,
Kanban
board,
I,
think
we
said
we
are
going
to
update
it
during
the
deaf
community
thing.
E
B
I,
just
wonder
whether
it
should
be
deaf
coming
to
think
or
should
be
something,
maybe
the
true
beauty
of
coming
to
think.
Maybe
that's
the
one
that
shouldn't
involve
that
yeah.
Just
keep
it
with
that
me
with
that
group
for
now
and
then
we'll
see
if
that
meeting
is
going
to
evolve
in
something
different
in
the
last
1
minute.
B
E
A
D
B
For
me
personally,
Thursday's
are
going
to
be
a
little
difficult
like
this
I
mean
this
time
is
probably
going
to
work.
Makanda
looks
okay,
but
judges
are
usually
pretty
hectic,
but
this
particular
time
card
seems
okay
for
me,
but
it
mostly
means
I'll
be
telling
in
from
home,
which,
which
is
probably
okay,.