►
From YouTube: Implementations Sync: 2020-08-13
Description
- WCOW exporting issue
- Is HTTP(s) broken?
- Lifecycle patch release
A
A
B
I
can
give
my
update
hello,
everybody
good
to
see
familiar
faces.
I
was
looking
into
the
issue
number
800,
which
is
appears
the
windows
apps
are
not
running.
This
is
the
short
version
of
it.
It
does
look
like
it's
due
to
the
path
environment
variable
being
messed
up
inside
those
inside
those
apps.
It
does
appear,
at
least
at
this
point,
that
it's
only
oh,
it's
it's
from
the
changes
from
platform,
api
version,
4.
B
it's
doing
different
stuff
with
the
environment,
variables
and
yeah,
just
kind
of
digging
through
that
right.
Now,
I'm
trying
to
assess
out
what
the
differences
are
between
linux
and
windows
for
platform
for
to
see,
if
there's
actually
just
some
underlying
architectural
differences
in
windows
that
makes
the
way
that
it
treats
those
environment
variables
be
different
in
a
way
that
we
might
have
missed.
So
it's
very
surprising
that
this
kind
of
snuck,
through
the
radar
in
so
many
different
ways.
So
I'm
hoping
it's
just
something
real
obvious
yeah.
I
guess
that's
about
my
view.
A
C
I
can
just
give
a
quick
update
on
the
life
cycle
patch.
We
discussed
it
in
working
group
yesterday,
but
if
anyone
missed
that
the
change
right
now
is
to
like
preserve
existing
functionality
or
existing
workflows
for
pac
users
when
they're
using
platform
api
0.4
previously
to
default
to
the
web
process
like
as
a
pac
user.
C
I
don't
have
to
do
anything
special,
but
now
that
the
life
cycle
is
creating
a
sim
link
for
every
process
type,
the
workflow
looks
a
little
bit
different,
and
so
what
we
determine
is
that
pac
should
always
tell
the
life
cycle
to
try.
If
no,
if
no
default
process
is
specified
on
the
command
line,
pac
will
ask
the
life
cycle
to
set
web,
and
if
web
isn't
one
of
the
defined
processes,
then
life
cycle
will
just
ignore
it
and
move
on
without
setting
the
default
process.
B
A
Okay,
we
can
then
move
on
to
micah.
If
you
want
to,
I
guess
my
question
on
issue:
800
is
just
to
clarify
where
the
root
cause
is,
I
think
you've
identified
what
what's
causing
it.
I
just
want
to
make
sure
you
know
that
the
statement
is
true,
that
this
would
be
a
life
cycle
bug
and
would
require
a
new
patch
of
the
life
cycle.
Is
that
accurate.
B
Like
as
we
were
as
we
were
speaking,
I
ran
just
kind
of
the
final
test
that
I
wanted
to
confirm.
What
it
suggests
is
that
the
linux
version
for
environment
variables
in
the
config
are
like
get
the
entire
path
that
should
be
given
over
to
the
app
it
like
does
the
right
thing.
Linux
is
obviously
fine,
but
it
behaves
differently
than
windows
is
right
now,
as
far
as
the
life
cycle,
or
what
the
what
the
life
cycle
does
short
answer
to
your
question
short
answer.
B
Long
long
answer
short
is
that
it
does
look
like
it's.
A
life
cycle
bug
appears
it's
something
in
exporter
where
it
converts
the
environment
into
the
image
config,
it's
missing
the
original
path
when
it
writes
it
into
the
final
image
config,
so
the
fix
will
have
to
be
in
lifecycle.
It
appears
unless
I'm
really
misreading
it,
but
that's
my
take.
A
B
Yeah
yeah,
a
common
thing
that
we
saw
was
that
the
windows
isn't
case
sensitive
about
its
environment
variables.
If
you
ask
for
all
caps
path
or
a
lower
case
path,
you'll
get
back
the
the
same
thing,
but
I
suspect
that
golang-
and
we
saw
a
little
bit
of
this
before
golang-
is
case
sensitive
about
the
way
that
it
parses
the
environment
variables
or
it
isn't
in.
B
I
forget
exactly
what
it
was,
but
I
think
that's
that's
kind
of
going
to
be.
The
fix
is
that
we
need
to
find
the
case.
Sensitive
version
of
the
original
path
make
sure
that
it
gets
carried
over
into
the
final
image
as
well
too,
in
addition
to
the
new
pieces
of
the
path
that
we
put
on
there
and
what
it
looks
like.
It's
only
the
only
components
that
get
set
in
the
image.
Config
are
the
life
cycle
path
directories
and
not
the
system
path
ones.
So,
in
terms
of
sizing,
I
don't
feel.
B
It
appears
that
three
isn't
as
broken,
but
I
think
it's
isn't
as
broken
for
the
wrong
reason.
V3
platform
v3
doesn't
appear
to
set
any
environment
variable
at
all
on
the
path
and
yeah.
I
don't
think
that's
I
I
forget
what
the
v3
spec
would
say
about
that,
but
I
don't
think
that's
actually
good
behavior.
I
think
p3
is
working
a
little
bit
better,
but
it's
not
very,
very
good.
B
That
makes
sense,
so
if
I'm
understanding
right
the
the
options
we
have
to
sort
of
avoid
well
options
we
have
overall,
is
we
block
release,
wait
for
the
fix,
whatever
fix
I
come
up
with
before
we
can
release
pack
that
feels
you
know
like
a
like
a
rough
decision,
a
lot
of
people
are
expecting
the
release
to
not
be
blocked.
We
could
do
as
you're
suggesting
we
could
have
windows,
just
use,
v3
and
then
linux
use
before
and
then
the
final
one
is
just
released
with
windows
broken.
B
Let's
fix
the
face:
well,
I
mean
there's
no
one
using
there's,
no
one
using
wcal
right
now.
It
feels
would
feel
great
to
release
it,
but
I
would
also
like
I
feel
like
doing
a
fast
follow-up
patch
wouldn't
be
the
end
of
the
world.
Do
you
get
a
sense
for
if,
if
we
did
do
a
fast
follow-up
patch
to
life
cycle,
oh
good
question
wcal?
Is
the
windows
containers
on
windows,
basically
meaning
like
a
pack
executable
targeting
a
windows
demon?
B
So
if
we
were
to
release
without
supporting
that
new
scenario
with
the
dotto,
I
think
it's
a
dotto
array
release
and
then
come
up
with
a
dot
one
to
fix
it.
I'm
maybe
maybe
I'm
shouldn't
speak
for
everybody,
but
I
think
I
might
be
okay
with
that.
If
it's
important
enough
to
get
the
release
out
and
if
we
didn't
want
to
fork
the
behavior
of
having
w
cast
a
on
v3
and
linux
containers
on
p4.
A
Yeah,
I
think
my
only
reservation
is
that
we're
probably
going
to
tilt
the
window
support
very
heavily
as
soon
as
we
make
the
release,
and
so
I
would
hate
for
people
to
go,
try
it
and
immediately
not
work
right.
So
the
fix
of
supplying
platform
api
03
for
wcal
seems
like
a
relatively
small
change.
That
would,
you
know,
satisfy
all
the
checkboxes
up
until
we
get
the
proper
fix
for
supporting
platform.
Api
o4.
A
B
I
I
think
I'd
have
to
dig
in
a
little
more
to
see
how
I
mean
I
probably
undersold
it
of
how
broken
it
was
probably
maybe
exaggerated
how
broken
it
was
yeah.
I
think
you're
right
javier.
It
does
functionally
work
well
yeah,
and
if
we
did
get
reported
issues
we
could
just
say
wait
until
the
patch
version
that
comes
out,
I
suppose,
rather
than
doing
any
any
non-useful
work
on
the
v3.
B
A
Maybe
really
small,
at
least
the
implementation
for
supporting
platform.
O4
was
just
detecting
because
we
ultimately
still
support
platform
api
o3,
because
you
could
still
be
using
an
old
version
of
the
life
cycle
right
and
so
our
support's
there.
It's
just
ultimately
specifying
a
variable
to
our
lifecycle,
execution
that
tells
it
hey.
Are
we
using
o3
or
o4?
And
so
again
it
seems
really
relatively
like
well
targeted
and
easy
to
implement.
A
A
A
C
C
What's
the
right
call,
maybe
just
right
before
this
meeting
stephen
also
brought
up
another
like
surfaced,
a
new
bug
which
appears
to
be
older
than
lifecycle
version
0.90.
So
maybe
it's
not
as
urgent,
but
it
has
to
do
with
https
proxy,
which
I
believe
we
currently
like.
Pac
will
currently
set
an
environment
variable
in
the
container,
if
there's
a
proxy
and
then
we're
like
stripping
it
out
of
the
environment
that
we
give
to
the
build
packs,
because
it's
not
in
the
include
list,
and
so
you
know
too
bad.
A
Yeah,
like
I
added
it
to
the
agenda,
because
I
have
more
questions
than
answers
about
this
right
now
like
it
was
brought
up
right
before
this
meeting,
and
I
didn't
know
if
anybody
else
had
more
context
on
you
know
when
this
changed.
What
is
that
really
impact?
And
you
know
from
my
perspective,
I'm
surprised
if
it
is
older
that
nobody's
actually
brought
it
up
yet
right.
So
it's
this
just
a
very
small
subset
of
users
that
are
using
this
feature.
A
C
A
Cool
so
we'll
have
those
we'll
continue
having
those
conversations
in
the
implementation
channel
for
everybody's
sake,
if
you're
interested-
and
I
think
right
now-
we
have
a
pretty
good
idea
on
what
we
want
to
do.
We're
still
unsure
about
the
life
cycle,
release
that's
still
up
in
the
air,
but
we
do
have
a
fix
for
pac
going
out.
Essentially,
I
think
pack
is
still
going
to
be
on
schedule
whether
or
not
the
new
life
cycle
is
released.
Actually
I
say
that
I
say
that,
but
I
guess
the
other
issue.
A
C
C
Well,
so
my
thinking
is:
it'll
probably
take
a
little
bit
of
time
to
get
a
handle
on
this
https
proxy
thing,
and
then
maybe
we
can
check
in
in
the
afternoon
and
micah.
Maybe
you'll
have
a
sense
by
then
whether
this
is
like.
Oh
hey.
This
is
a
one-line
change.
You
know,
let's
just
merge
it
in
and
ship
it
with
the
patch.
B
Yeah
right,
I
feel,
like
the
mitigation
that
javier
is
going
to
introduce,
will
make
it
less
important
whatever
I
how
far
I
get,
I
guess
it's
just
the
if
it,
if
it
you
know,
makes
sense
to
try
and
sneak
into
a
life
cycle,
merge
or
not
yeah.
I
think
I'm
fine
either
way.
I
think
that
that
sounds
good
to
me.
Natalie.