►
From YouTube: Node.js Foundation Build WG meeting 2016-06-07
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
B
We
lowered
the
the
history
of
how
long
we
keep
job
history
around
from
30
days
to
20
days
and
rodas
also
done
some
other
tweaks
with
memory
and
garbage
collection,
but
we'll
still
seeing
a
lot
of
intermittent
timeout,
no
timeouts,
so
Jenkins
is
still
a
headache
for
us.
I've
been
playing
around
with
billboard
on
the
side,
but
I
have
nothing
to
report
really.
I
also
think
I
did
I'm,
not
sure
if
that
was
part
of
the
last
meeting.
But
I
did
some
work
on
you
bunch
of
16
as
well.
A
C
Hello,
I'm
I've
changed
the
test,
binary
arm
job
to
not
use
the
Jenkins
get
in
to
go
on
git
commands
directly
instead
and
it
fetches
just
the
references
that
I
wanted
to
fetch
and
so
far
I
think
it
has
been
working.
Ok,
I
also
created
the
fan
job
to
stress
for
the
stress
test,
a
fan,
john
forearm
that
should
run
much
faster
than
the
the
other
stress
test
job
and
the
last
week.
I
want
to
cut
work
to
your
attention
that
I
have
noticed
the
strange
behavior
in
jenkins.
C
I
don't
know
if
it's
a
while
or
if
there
is
any
justification
to
it,
but
the
test
test
arm
fan
job
instead
of
launching
a
new
compile
job
with
an
oath
compel
job
marked
it
as
then
right
away
and
executed
the
test
job.
So
it
felt
this
is
a
problem,
because,
if
Jenkins
pics
test
the
in
the
test
job
stage,
if
it
picks
a
job
that
has
already
run
and
as
succeeded,
it
can
show
a
false
positive.
So
please
keep
an
eye
open
for
this.
D
C
D
I
think
since
last
time
spent
a
little
bit
of
time,
just
on
PCP
into
the
release
is
mostly
like
testing
builds
and
stuff
like
that,
we're
recently
trying
to
investigate
and
trying
to
resolve
BBC
machine
issues
which
is
still
ongoing,
and
finally,
there
was
a
few
tweets
I
needed
to
make
to
the
beat
test
job.
There
were
some
cases.
D
It
seemed
to
be
having
problems,
checking
out
or
getting
the
right,
the
right
resources,
depending
on
how
the
previous
job
and
run
so
I
added
an
extra
couple
lines
to
try
and
do
some
cleanup
to
make
those
run
more
lively,
I
guess
next
is
miles,
is
not
here,
so
would
be,
I,
don't
know
if
riches
on
the
line
I
don't
think
so
either
you.
D
B
D
B
D
B
D
B
D
A
Okay,
the
first
one,
is
a
issue
number
35
for
access
to
build
resources.
This
is
a
pure
white
section,
asses
to
be
a
resource
for
people
outside
of
Bill
group
straumann
for
discussion.
This
is
a
proposal
by
my
cousin
to
try
and
formalize
the
process
by
which
the
criteria
by
which
we
grant
access
to
infrastructure
machines.
A
B
D
A
B
So
this
is
more
of
an
update
of
what's
been
going
on.
B
A
B
Right,
yeah,
so
so
that
they
were
kind
of
going
back
to
their.
You
know,
network,
guys
and
and
and
DevOps
and
sorption-
and
we
were
kind
of
you
know,
trying
to
summarize
what
we
needed
and-
and
you
know
a
few
solutions
to
how
we
could
you
know
be
more
clear
with
with
who
will
have
access
and
how
so
that's
kind
of.
What's
what
we're
working
on
right
now
right
also.
A
B
B
Yeah,
I
think
it
was
2012
2012,
mostly
but
8
to
16
gigs
of
ram,
so
I
mean
it's
perfect
for
us
if
we
just
run
1
I've
built,
so
I
wonÃt
even
we
could
probably
even
squeeze
two
if
we
had
to
so
so.
Obviously,
there's
questions
like
how
to
manage
operating
system
and
stuff
like
that,
but
I
think
just
at
the
moment.
It's
the
best
thing
we
can
do
is
figure
out.
If
you
know
we
can
come
to
a
solution
where
they
host.
A
B
I
wouldn't
know
who
I
think
the
problem
with
people
that
I
mean
look
at
all
the
colo
stuff
for
Mac.
It's
mostly
Mac,
minis
and
mac
pros
so
like
hooking
into
a
daughter,
centered
and
just
you're,
getting
sponsored
hosting
or
Colo
would
be
tricky.
So
I
think
you
know
someone
that
has
a
lot
of
space.
I
can
have
10
to
15
or
whatever
it
was
macbooks
running
sure
that'd
be
great
I,
don't
know
anyone
the
of
hoover
country
working
with.
A
Sounds
good,
okay,
I
think
we
can.
The
next
issue
are
the
next
one
is
icing
endpoint
to
mirror
going
to
be
this
issue
number
55,
but
some
discussion
about
this.
The
last
meeting
there
was
some
concerns
about
our
the
rsync
and
point
not
being
encrypted
and
since
then,
rather
than
the
new
proposal,
but
I
know
well,
it
doesn't
solve
the
fact
that
is
unencrypted,
but
making
an
endpoint
specifically
named
insecure
or
unencrypted.
B
You
know
I
I
mean
if
this
is
so
I,
don't
think
we're
it's
aged
where
we
vote
just
yet,
but
I
think
this
is
a
good
idea.
If
we're
doing
this,
and
the
only
comment
I
have
is
pretty
much
that
we
end
and
expiry
to
it
as
well.
So
we
just
don't
create
a
service
where
we
have
to.
You
know,
keep
this
open
forever.
B
If
our
plan
is
to
to
work
towards
on
a
full
encryption
to
client
in
time,
I
think
you
know
adding
three
four
years
of
expiry
time
to
this
would
be
a
good
idea,
and
hopefully
something
else
might
pop
up
during
that
time.
I
can
replace
this
I
guess
that
the
other
comment
that
came
up
was
a
naming
comment
from
Michael,
suggesting
that
we
could
use
unencrypted
instead
of
insecure
yeah.
B
B
A
B
Guess,
just
if
anyone
wasn't,
you
know
up
to
date
with
the
issue
and-
and
there
was
any
things
we
wanted
to
had
to
elaborate
in
I
guess
I
I.
Would
how
would
wonder
if
anyone
else
think
it's
a
good
idea
to
add
an
expiration
date
to
it?
I'm,
not
gonna,
you
know
fight
for
it,
but
I
think
it
would
be
a
good
idea.
I.
D
Think
if
you
put
an
X
ray,
you
know
if
you're
talking
three
or
four
years,
it's
far
enough
out
that
it's
not
going
to
cause
anybody
fortune
but
you're
right
that
it
would
be
nice
to
send
a
message
says
we're
doing
this,
because
this
is
expedient
now
but
really
longer
term.
We
rather
do
something
else.
I
guess
is
they're
like
is.
It
would
be
even
better
if
we
said
and
we're
going
to
try
and
move
something,
but
I
guess
that's
our
problem
is
there
is
no
obvious
alternative
right,
not.
B
B
I
mean
it's
up
to
us
how
how
far
we
want
to
go
with
that.
But
it's
it's
it's
an
option.
Yes,
I
think
I
mean
most
people
are
used
for
backup
uses
our
sink
over
ssh,
but
for
public
mirroring,
which
is
you
know
how
most
muslim
linux
works
for
tar,
balls
or
distributions.
It's
just
plain
plain,
but
I
guess
like
the
next
up
here
would
be.
We
could
try
and
have
a
vote
or
something
at
least
we
we
get
all
all
opinions
out
there
before
we
implement
it.
B
Know,
that's
true.
It's
just
odd.
You
know
once
we
put
this
online
or
peoples
are
using
it.
It's
just
another
thing
we
we
can
ever.
We
can't
just
remove
easily
you're
free
to
offer
it
as
a
service.
B
Ya
and
having
an
unsecured
unencrypted
endpoint
for
our
content
and
I
guess
what
what
rod
mentioned
as
well.
Last
time
we
spoke
of
it,
which
was
you
know,
there
might
be
security
vectors
for
our
sink
as
well.
Who
knows
I'm
not
saying
it's?
It's!
You
know
a
key
factor
in
the
seeing
how
it's
almost
older
than
HTTP
but
yeah,
it's
still
another
type
of
endpoint.
We
need
to
maintain.
A
Thanks
good
sounds
good
to
me.
Yes,
yeah
especially,
would
like
to
understand
what
the
benefit
is.
You
know
what
scenarios
are
there?
The
absolutely
need
is
that
cannot
be
fulfilled
by
other
tools
or
protocol.
Okay,
okay.
So
the
next
issue
in
issue
number
423
access
to
X
power
linux,
one
machine
for
I
was
here
who
is
in
run
on
this
call,
so
a
man
has
already
been
working
on
the
AIX
and
Power
PC
builds.
A
A
B
Yeah
IRC
yeah
I'm
happy
to
do
it.
I
mean
we
got
to
figure
out
what
what
I
mean.
What
will
happen
is,
first
of
all
will
grant
you
access
and
all
that
you
will
get
a
shared
public,
sh
Keys.
You
get
access
to
a
certain
amount
of
hosts,
but
I
guess
we
can
figure
out
through
Ric
and
we
can,
like
you
know,
do
a
few
q
and
A's
and
then,
as
you
move
forward,
I'll
try
and
formalize
it
into
some
kind
of
onboarding
Q&A.
We
can
reuse
for
note
for
the
building
now.
B
And
I
guess
like
just
tools
we
use
and
I
mean
the
Kiwi.
We
will
grant
access
to
will
give
you
access
to
all
test
machines,
not
just
the
IBM
stuff.
So
you
know
if
you
notice
that
anything
might
be
down,
feel
free
to
help
out
there
as
well.
Obviously,
but
anyway,
let's
figure
out
over
RC
and
I'll
get
it
get
it
going.
A
B
Oh
yeah,
I
guess
it's
it's
a
bit
of
a
man
I
wish
Phillip
was
around
to
kind
of
give
us
an
intro,
but
what's
been
going
on
on
the
side
is
that
our
team
has
formed
around
infrastructure
and
software
to
build,
to
have
a
boat
that
you
know
integrates
between
or
like
integrates
the
gap
between
Jenkins
github
and
automation,
on
github
in
general,
so,
for
instance,
about
that
it
sets
tags
to
issues
and
PRS
and
in
time
also
will
update
PRS
with
build
information
from
Jenkins
runs
and
ask
this
gross.
B
We
need
to
formalize
the
structure
and
access
to
these
as
well,
seeing
how
they
will
have
Jenkins
keys
and
a
github
account
that
it
gets
the
mouth
access
to
go,
see,
I
and
and
perhaps
in
time
another
one
that
runs
against
release
too.
So
I
think
at
this
stage,
there's
nothing
really
we
can.
That
is
actionable
enough.
I'm.
Just
trying
to
read
this
as
we
move
forward.
I
guess.
B
One
thing
that
I
raised
with
with
the
suggested
plan
was
that
I
wanted
to
kind
of
formalize
how
we
merge
commits
at
the
github
repo,
seeing
how
similar
to
how
people
can
abuse
access
to
Jenkins
by
pushing
malicious
code
to
a
PR
and
running
it.
This
could
act
in
a
similar
way.
You
have
full
access
to
all
jobs
and
a
lot
of
Jenkins
infrastructure
through
the
boat.
So
one
thing
I
suggested
was
that
we
would
do
a
sign
off
ouran
reviewed
by
merge,
similars
workflow
that
we
have
in
in
the
node
repo.
B
B
B
I
guess
and
just
to
summer
up,
but
that's
a
few
things.
First
of
all,
I
mean,
since
we
are
the
building
for
structure
team,
we
should
obviously
host
this.
The
second
thing
is:
how
do
we
order
the
poor?
How
do
we
handle
deployments
and
the
third
thing
is
obviously
access
and
access
control
in
general,
so
yeah
give
it
a
good
read.
A
Okay,
so
that
I
guess
that
means
we
can
be
very
buddy
half
an
hour
back.
So
thank
you
for
joining
us.
The
next
meeting
will
be
on
jun
28,
a
p.m.
UTC,
okay.