►
From YouTube: OMR Compiler Architecture 20191024
Description
Agenda:
* OMR release discussion (content, cadence, milestones, etc.) [ @mstoodle ]
B
D
Right
so
I
confess
I
haven't
done
as
much
forward.
Thinking
like
this
meeting,
so
I've
kind
of
been
thinking
about
this
since
I
started
walking
down
or
if
I
were
to
come
to
this
room
so
Sarah
there
are
a
number
of
areas
and
I
forgive
forgive
me
for
being
disorganized
as
I'm
just
gonna
kind
of
start.
Talking
and
people
stop
interject
ask
questions,
make
suggestions
as
we
go,
because
that
will
make
this
way
more
effective
than
just
meet
dialogue,
art,
monologuing,.
D
Right
so
we've
done
one
relief,
which
I've
kind
of
used
the
phrase
as
a
line
in
the
sand
for
releases
going
forward.
We've
done
one
now
we
have
to
make
some
decisions
around
what
kinds
of
release.
What
do
we
want
to
do
going
forward
for
releases?
Do
we
want
to
plan
a
bunch
of
content
like
changes
that
we
want
to
make
before
we
issue
a
new
release
and
basically
decide
the
timing
of
releases
based
on
when
certain
work
items
complete,
or
do
we
want
to
do
time?
D
D
We
we
could.
We
don't
have
to
do
the
same
kind
of
time,
boxing
that
open
j9
does
but
I.
Think
since
open
j9
is
one
of
our
biggest
consumers.
We
should
be
cognizant
of
what
their
release
schedule
is.
If
we're
going
to
come
up
with
a
different
release
schedule-
and
hopefully
we
can-
we
can
create
something.
At
least
you
know
reasonably
well
aligns
with
what
it
is
that
they
want,
and
obviously
we
should
solicit
in
for
input
from
from
others
that
are
they're
consuming
omar.
D
At
this
point
you
know
that
might
mean
so
one
way
we
could
do
that
which
would
kind
of
make
it
easier
to
have
multiple
consumers
who
all
may
have
different
release
schedules.
As
we
could
do
a
very
freak,
we
can
do
very
frequent
releases
right.
We
could
do
time
boxed
releases
every
month
say
which
I
don't
know.
If
the
clips
would
appreciate
us
doing
it,
but
we
could
do
it.
D
It
does
put
a
bit
of
an
onus
on
me
and
lead,
because
some
of
the
release
activities
are
things
that
only
a
we
can
do.
I
believe,
but
if
we're
doing
it
once
a
month,
then
we're
also
not
doing
very
much
in
a
month,
so
maybe
not
still
manage
well
yeah
go
ahead.
You
said
that
eclipse
might
not
appreciate
that.
Is
it
because
they
have
their
process
on
the
eclipse
light.
So.
D
To
get
involved
so
so
there's
a
limit
to
help
frequently
we
could
do
this
without
really
going
over
the
top
right.
So
the
release
process
requires
a
one
week
at
least
review,
and
then
parts
of
the
eclipse
review
machinery
have
to
sign
off
on
the
things
that
we're
we're
generating.
So
that
takes
some
time
as
well
as
well.
D
So
I
think
you
know
if
we're
not
going
to
do
pipeline
releases-
and
I
really
hope
we're
not
going
to
do
pipeline
releases-
probably
two
weeks
as
the
absolute
minimum,
but
that
would
mean
we're
basically
doing
like
work
constantly
doing
a
release
and
I
think
that's
very
practical.
Either
monthly
is
kind
of
the
that
might
be
the
right
trade-off.
D
I,
don't
know,
I
mean
obviously
open,
j9
expected
every
Eve
or
is
releasing
every
approximately
three
months,
but
it's
a
little
bit
offset
because
the
feature
releases
go
out
in
two
different
months
and
the
update
releases
go
in
right,
so
update
releases
are
in
January,
April,
July
and
October,
and
then
feature
releases
are
in
May
and
September
right.
So
there's
that
March
April
and
September
October,
where
it's
their
one
month
apart.
Basically.
E
B
What
LLVM
does
she
releases
a
year
there,
six
months
apart,
they're
pretty
much
time
to
modulate
testing
or
other
issues
that
cause
them
to
push
the
timeframe
right
if
they
they
have
a
particular
feature
or
something
that
they
decided
is
going
to
go
in
that
release,
and
it's
not
quite
contained
to
the
timeframe.
They
will
move
the
timeframe
slightly,
but
it's
every
six
months
spring
and
fall,
and
they
usually
time
their
two
dev
conferences
in
Europe
at
the
US
as
around
last
two
times.
D
B
D
I
agree
with
that
I
guess,
but
I
wouldn't
necessarily
expect
every
consumer
to
take
every
monthly
release
as
one
way
that
we
could
adapt
to
that
right.
So
it's
the
idea
behind
the
I'm,
not
I'm,
not
saying
that
I'm
necessarily
in
favor
of
doing
multiple
leases,
I'm
not
trying
to
advocate
for
monthly
releases
I'm.
Just
saying
this
is
an
option
which,
which
would
be
flexible
right.
D
So
it
means
that
you
can
have
different
consumers
who
might
be
interested
in
picking
up
a
release
at
different
times
through
the
year
based
on
whatever
they're
really
schedule
looks
like
and
that
might
allow
them
to
pick
up
whatever
the
latest
and
greatest
or
doodad
is
that
they
want
without
having
to
necessarily
adjust
their
timing.
So
much
but
like
I,
said
I'm
not
necessarily
expecting
this.
Every
single
downstream
consumer
would
pick
up
every
single,
because
Olmert
released
and
incorporated
as
a
release
into
like
open,
Jane
I
think
wouldn't
be
able
to
do
it.
B
Worry
that
there's
not
enough
runway
like
if
I'm
an
open
source
project
and
I
have
my
own
large
list
of
things
to
do
and
OMR
is
doing
things
that
are
the
right
things
for
Almar
that
could
break
my
world.
I
need
to
be
able
to
make
enough
time
to
review
those
investors
and
do
my
testing
against
those
and
provide
the
feedback
and
are
we?
B
D
E
D
I
think
it's
a
nice
kind
of
seal
of
approval
on
like,
if,
like
we
I,
don't
know
what
this
actually
like.
A
hundred
percent
worked
with
the
first
release
that
we
did,
but
but
for
the
0.10
release
we
chose
the
exact
same
or
more
commit
that
the
open,
j9
0.17
release
used.
You
know
they
may
have
tacked
on
something
after
that,
as
a
small
change
to
it.
But
in
terms
of
what
that
release
is
it's
the
one?
D
B
Guess
if
you
went
to
that
monthly,
you
know,
let's
say
that
we
are
looking
at
doing
a
much
more
major
refactoring
right.
So
we
know
we
know
that
there
are
some
of
those
that
are
going
to
need
to
happen
right.
We
need
to
like.
We
want
to
bring
a
team
for
structure
up
into
the
compiler.
We
want
to
bring
up
persistent
method
info
for
open
j9
factory
data
grade
and
various
bits
of
Java
Java.
B
B
And
I
guess
might
have
taken
how
old
house,
how
would
you
propose
that
the
project
managed
the
delivery
of
that
stuff
where
it
may
not
be
practical
to
have
the
two
implementations
sitting
in
the
code
right
like
some
of
these
refactorings
are
pretty
hard
to
stage.
Some
of
them
do
need
to
be
sort
of
BIGBANG.
You
know
here
it
is
well.
C
C
B
I
mean
at
the
same
time,
if
you
are
going
to
look
to
consume
this
technology
having
random
stuff
just
get
up
and
move
around
whenever
the
hell
it
feels
like.
It
is
not
a
great
position
to
be
in
as
a
consumer
or
anything.
You
know
the
Omar
project
committee
can
decide
at
whatever
point:
okay,
hey
presto
major
thing
is
landing.
It's
going
to
be
in
the
next
monthly
release.
I
have
to
suck
it
or
not,
and
if
not
I'm
going
to
be
back
level
for
a
while.
So.
B
B
D
We
were
willing
to
step
up
to
a
monthly
release
cycle
I
think
we
would
also
have
to
very
seriously
consider
what
the
impact
of
those
kinds
of
changes
are
going
to
be
on
downstream
consumers,
and
we
would
have
to
look
very
hard
at
how
we
deliver
those
things
such
that
I.
Don't
think
I'm,
not
sure
we
could
make
the
choice
that
you
get
one
or
the
other,
and
so
are
you
gonna
deal
with
it,
because
that's
not
gonna
be
something
that
everyone
will
be
able
to
tolerate
right.
D
So
I
guess
my
point
is
like
you.
It
would
force
us
to
think
about
refactoring
in
a
way
in
which
downstream
consumers
can
tolerate
the
intermediate
steps,
and
that's
definitely
more
painful
and
for
all
our
on
a
problem.
That's
already
pretty
damn
painful
to
work
on
so
that
I
mean
this
may
be
like
that
thought.
The
issue
that
you're,
raising
and
I
think
what
we
would
have
to
do
in
order
to
support
the
monthly
release,
maybe
in
all
sort
of
the
biggest.
D
Yeah
I
get
it
I,
think
open
G.
Knowing,
though,
because
of
the
way
it
releases,
it
would
choose
to
pick
up
the
master,
and
so
you
can
run
as
it
wants
stuff.
That's
in
the
master
branch.
It
doesn't
have
just
want
fixes.
So
if
you
want
even
one
thing,
that's
in
the
master
branch,
you're
kind
of
forced
to
take
it
all
right.
D
D
D
At
least
with
me
is
changing
by
a
lot
again:
I'm
wondering
it
the
further
apart
you
make
the
releases,
the
less
I
get
the
more
painful
it's
going
to
be
for
zooming
Pro,
just
to
pick
up
that
release
too
right,
like
it's,
not
just
the
few
things
that
are
changing
in
a
large
way
this
month.
It's
all
the
things
that
have
changed
in
a
big
way
in
the
last
six
months
today
as
an
example
here
right,
so
there's
definitely
a
sweet
spot.
E
C
C
B
I,
don't
know
that
they're
I,
don't
know
I
would
go
so
far
as
to
say
that
they
do
it
negatively,
but
that
moving
up
versions
is
known
to
be
a
lot
of
work.
So
you
people
who
live
downstream
from
LLVM
either
have
to
have
a
team
of
people
who
are
constantly
update,
update
updating
their
project
with
head
right.
B
So
there
are
some
projects
that
follow
head
and
every
refactoring
and
everything
else
that
lands
in
it
they're
immediately
trying
to
keep
up
with
it
so
that
they
don't
have
a
big
bang
adoption,
but
other
projects
that
do
do
the
Big
Bang
adoption.
But
when
you
do
that,
it
can
be
two
three
four
weeks
that
work
for
somebody
for
a
small
team
of
people
to
go
through
and
do
all
of
the
refactoring
that
might
be
required
because,
while
they're
API
stable,
they
still
have
new
stuff
added.
And
you
know
they
do.
B
B
E
F
E
Like
public
API
isn't
changing,
you
can
do
a
month
a
release,
but
if
you
know
that
you're
gonna
change
some
of
that
breaks
API,
you
could
push
it
a
bit
later.
I,
don't
know
how
easy
that
is
to
do.
Considering
that,
maybe
you
need
that
API
change
now,
I,
don't
know
I'm
just
sort
of
curious
as
to
whether
it
has
to
be
like
stable
cadence
or
it
can
fluctuate
a
bit.
So
I
think
it
depends
on
the
component
you're
talking
about
so
for
the.
D
B
D
Of
the
stumbling
blocks
toward
defining
that
API,
because
right
now,
it's
a
very
large
surface
area
that
the
compiler
exposes
to
other
to
other
projects.
We
need
to
complete
some
of
the
internal
refactoring
work
within
Omar
that
we
wanted
to
do
to
this
basically
clean
up
the
various
components
of
the
compiler
to
get
things
in
a
better
conceptual
integrity
kind
of
state.
And
then
we
can
go
about
producing
or.
D
Example
of
something
that
that
probably
is
closer
to
having
an
API
that
we
could,
we
could
standardize
at
some
point
but
more
stable,
but
we
have
been
changing
things
and
still
it's
not
it's
not
a
1.0
api.
At
this
point
either
it
is,
is
changing
fact,
there's
some
fairly
major
changes,
an
implementation
that
I'm
contemplating,
which
hopefully
won't
be
API
breaking,
but
could
be
certainly
will
add.
A
lot
of
new
API
may
not
break
existing
API,
but
anyway,
that's
a
discussion
for.
E
D
Think
in
the
end,
we'd
have
to
come
up
with
like
what's
the
trigger
for
us
to
do
a
release,
in
that
case,
right
like
what
are
the
criteria
that
we're
going
to
use
to
say
it
now's
the
time
for
a
release
and
I,
don't
know
in
my
mind
this
is
gonna,
be
there's
gonna,
be
some
pain
associated
with
doing
a
release
for
a
while.
You
know
if
we
can
get
into
a
sort
of
regular
habit
of
doing
it,
we'll
get
accommodated
to
that
pain
and
and
we'll
fix
the
hardest
parts
of
that
pains.
D
A
C
To
yeah
number
a
a
1.0
days,
yeah
I've
looked
at
doing
just
that.
It
there's
a
lot
of
places
where
it's
not
trivial,
to
move
that
piece
of
code,
as
you
have
like
it's
not
obvious,
specifically,
what's
functionality
that
code
represents
so
coming
up
with
a
good
extension
point
for
that
functionality
ends
up
becoming
very.
D
D
All
right!
Well,
so
you
know
all
of
that
I
think
we're
kind
of
we
didn't
state
it,
but
we're
envisioning,
continuous
releases.
The
other
approach
we
could
do
is
which
again
doesn't
completely
mitigate
the
problems
that
we're
talking
about,
but
we
could
do
what
LTS
releases
and
like
have
a
service
dream
release
where
only
fixes
that
are
kind
of
reported
against
that
release
could
be.
Could.
B
D
The
choice,
no
contributions,
if
it's
an
obvious
change
that
should
be
refactored
in
some
way
to
make
it
live
in
one
downstream
project
rather
than
omar.
Then
we
should
suggest
that.
Well,
it
means
probably
a
premature
question.
Given
the
number
of
consumers,
we've
got
right
now,
who
would
be
consuming
a
release
and
expecting
fixes.
D
Nothing
stopping
us
right
now
from
doing
that.
Right,
I
mean
we
put
zero
dot,
one
dot
zero.
I
created
a
branch,
so
in
principle
I
mean
you
can
go
back
date,
a
branch
anywhere
right
button.
So
it's
nothing
stopping
us
from
releasing
a
fix
on
any
release
in
principle.
I!
Guess
it's
a
question
of
whether
or
not
the
project
think
that's
where
well.
Maybe.
C
That's
a
premature
questions
because
we
don't
have
very
many
consumers.
We
can.
We
can
punt
that
one
I
guess
I
mean
I,
think
we're
just
from
a
maintainability
point
of
view.
I,
don't
think
the
project
is
any
chance,
because,
even
if,
like
we
make
it
so
that
it's
up
to
the
consumer
to
do
the
fake,
it
will
still
be
on
the
project
to
review
the
figs
and
make
sure
that
it
got
tested
properly
and
do
the
fixed
release
and
all
of
that.
But
there's
still
going
to
be
an
overhead.
D
You
don't
look
over
him
if
you
know
how'd
I
get
that
I,
don't
like
them
either
right
well,
I
mean
I
mean
all
of
this
could
be
cart
before
the
horse
and
principal
rank
me.
We
could.
We
could
just
decide
for
now
we'll
do
a
release
in
six
months.
Then
what
happened
will
happen
open,
g9
and
continue
on
its
merry
way
of
taking
commits
from
in
the
middle
of
those
releases,
and
as
we
get
closer
to
a
point
where
we
think
it's
more
sensible
to
start
talking
about
more
frequent
releases
if
they're
warranted
that.
E
D
So
maybe,
if
we're
gonna
do
that
pal
all
right?
Well,
it's
out
of
an
open,
j9
centric
way
of
thinking
about
this,
but
we
could
issue
a
No
More
release
that
sort
of
predates
the
open
gene
on
future
releases
by
a
little
bit.
Okay,
there's
only
two
of
those
there,
every
six
months,
they're,
otherwise
gonna
get
kind
of
make
sense.
That
is
the
newest
friends
banking,
new
version
of
Java.
E
D
D
And
what
people
think
so
that
would
mean
I,
guess,
March
and
September
elope
or
though,
or
when
open
genuine
releases.
What
kind
of
I
guess
mid,
March
mid,
mid
September,
so
we'd
probably
want
to
try
to
cut
our
release
a
little
bit
like
end
of
February.
So
what
the
first
one
would
be
six
months
away,
but
then
we
could
go
on
to
a
six
month
of
cadence
at
that
point
and
until
we
feel
like
there's
a
point
in
doing
something
else,.
D
We
already
run
the
maximum
mi.
Well,
so
Shelly
Chile
has
indicated
an
interest
in
making
it
easier
for
downstream
consumers
to
do
testing
with
early
early
drops
a
little
more
having
ways
of
sort
of
using
actually
sure
exactly
how
she's
imagining
this
will
work,
but
but
trying
to
make
it
easier
to
design
test
testing
for
downstream
projects
to
be
able
to
reflect
the
impact
of
things
back
into
back
into
say,
Walmart
or
in
voltage
a9,
but
she's,
actually,
looking
at
all
more
from
this
perspective
too,
so
I
think.
D
If
we're
gonna
have
a
six-month
release
cycle,
then
I
think
it
probably
makes
sense
for
us
to
at
least
be
notionally
identifying
what
the
big
pieces
are
trying
to
get
those
done,
and
we
need
to
talk
about
that
too.
But
ideally,
if
you
have
a
really
cycle,
you're
trying
to
do
big
stuff
early
and
you're
trying
not
to
do
as
much
big
stuff
right
before.
B
I
might
make
things
easier
or
open
Jana
in
some
ways,
because
the
moment
they
don't
have
any
real
direct
control
over
anything
blending
Omar
so
right
he's
different
cutting
of
those
releases
in
it
but
gives
it
gives
AUSA
justifications
themselves.
But
yes
right,
but
it
gives
us
a
justification
for
holding
off
a
larger
change
for
a
period
of
time
because
we're
getting
ready
to
release
or
whatever
emerge,
ring.
D
D
So
if
we
can
enable,
via
whatever
ideas
that
Shelly's
proposing,
make
it
easier
for
open
j
9
NJ,
whatever
whoever
else
all
of
those
all
of
the
JIT
bills
are
based
projects,
make
it
easier
for
to
pick
up
a
release
candidate
where
a
milestone
build
or
something
and
be
able
to
feedback
test
results
into
the
Omar
project.
To
say,
I
ran
my
tests
and
you
know
nothing
went
wrong.
So
this
looks
good
from
from
my
perspective,
that
kind
of
feedback
I
think
as
long
as
we
leave
enough
time
at
the
end
of
the
release.
D
For
that
type
of
thing
to
happen
and
we'll
have
to
play
by
ear
how
we
do
this,
but
like
we'll,
try
to
try
to
solicit
I,
guess
the
feedback
from
our
stakeholders
on
how
well
they
think
things
are
looking
and
then
you
know
I
think
that's
likely
to
be
the
best
kind
of
feedback
we'll
get
on
the
on
the
larger
quality
statement
of
oven,
Omar
release.
What
do
you
think
can't
read
your
faces,
you're
listening
to
that
kind
of
arbitrary
does,
but
okay,
so
do
you
have
canticle
injustice?
D
Okay,
all
right!
Well,
it
isn't
decided
today
right
now
and
lost
in
place
for
never
more
to
be
changed,
but
right,
but
it's
a
topic
I
think
we
should
continue
to
think
about.
Yes,
I
guess,
if
we're
going
to,
if
we
were
going
to
follow
this
model
and
we're
doing
the
next
release
at
the
end
of
February,
20
20
doesn't
mean
that
we
need
to
have
some
kind
of
a
better
testing
or
story
in
place
by
then,
which
may
not
necessarily
be
realistic.
But
again
it's
something
that
we
iterate
going
forward
yeah.
F
C
E
D
Bar
so
I
think
I
think
I
think
what
Shelly's
looking
at
is
kind
of.
Looking
at
that,
from
the
other
side,
it's
what
infrastructure
and
facilities
can
Omar
provide.
That
will
make
it
easy
for
a
downstream
consumer
to
run
a
set
of
their
own
tests,
like
just
pull
in
a
particular
release.
Candidate,
build
a
Baltimore
and
run
a
set
of
tests
on
that
and
reflect
those
results
back
in
right
into
Omar
did
have
to
be
somewhere.
E
C
Had
talked
about
this,
and
we
talked
about
a
lot
of
things
but
end
up.
We
basically
came
up
with
kind
of
two
models:
red
one
is
where
we
basically
go
to
this.
We
would
have
some
sort
of
subscription
model
away
downstream
projects
would
say,
hey,
please
let
us
know
when
you
have
a
release
ready
and
then,
when
we
notify
them
that
their
release
is
ready,
then
they
go
and
run
their
tests.
C
However,
they
want
and
then
bring
us
back
the
results
or
we
could
make
it
so
that
by
subscribing
they
could
provide
something
like
a
docker
image.
That
just
only
will
do
is
build
their
project
and
run
their
test
suite
and
we
specify
which
OMR
committed
build
on
top
of,
and
then
we
can
just
grab
whatever
docker
images
were
given
run
the
test,
with
the
commits
that
we
think
is
going
to
be
our
release
and
see
what
we
get,
but.
B
B
It's
that's
the
kind
of
model
that
LLVM
users,
for
there
have
at
least
four
platforms
right.
If
you,
if
you
want
to
support
a
hardware
platform,
you
can
go
and
talk
to
them,
they
will
give
you
the
scripts
and
stuff
to
put
on
your
machine.
You
put
your
machine
on,
you
run
their
image,
you
register
it
and
it
will
become
a
slave
to
the
farm
and
it
will
do
all
to
the
test
right.
Please
join
the
Borg
collective,
yes,
exactly.
D
D
D
D
Then,
probably
with
some
type
of
mouth,
don't
identify
somewhat
earlier
in
the
release
whenever
that
makes
sense
and
I
think
I
think
it
still
does
make
sense
for
us
to
do
some
more.
So
if
we
can
all
kind
of
agree
on
that
is
the
basic
way
forward
and
seeing
basically
people
modding
and
Robert
agreed
that
will
document
this
in
an
issue,
and
we
can
do
an
official
committee
vote
or
something
like
that.
D
B
A
D
B
Right
but
having
those
morning
emails
and
kind
of
going
right,
we're
now
four
weeks
out
from
fries
two
weeks
out
from
fries,
okay,
we're
now
in
fries,
and
that
means
this
to
the
committers
and
okay
I'm
wearing
you
know,
and
the
split
has
now
completed
and
it's
it's
back
to
the
next
release.
Right
and
funding
is
out
like
on
the
dev
mailing
list,
so
that
the
committers
and
all
the
interested
contributors
can
see
that
that
happening
in
a
very
visible
way.
So.
E
D
D
B
D
D
D
So
that's
definitely
the
people
who
would
be
deciding
this
or
I
mean
it
comes
down
to
whether
it's
a
group
of
committers
or
whether
it's
the
committer
who's
going
to
merge.
It
was
reviewing
it
and
merging
it
or
you
know
it's
like.
Is
it
just
a
we
devised
a
set
of
rules
to
handle
situations
and-
and
we
just
follow
those
rules
consistently
across
the
committer
group
or
do
like
what
do
you
know
it's
gonna
be
or
my
given
the
number
of
pull
requests
to
get
her
to
know
me,
kids
or
it
could
be
by
anyone.
B
D
C
The
state
of
entropy
of
the
I
would
say
this:
let's
process
already
had
some
of
that
wit,
like
she
Q's
right
words
like
there's
already
this
notion
that
basically
lines
of
codes-
oh
yeah,
but
what
I
mean
when
I
filled
in
the
contributor?
Yes
right,
yep
yeah,
what
I
mean
is
there's
already
this
notion
that
larger
contributions
have
to
be
vetted
in
some
way.
This
would
be
just
something
that,
in
my
mind,
were
just
kind
of
taking
that
idea
and
buying
it
to
a
release.
C
B
Well,
then
the
bar
goes
higher
that
big
stuff
move
whatever
the
definition
of
big
stuff
is
that's
not
going
in
until
the
freeze
is
done
right
you
reach
the
three
week
mark
or
whatever
it
is.
The
bar
goes
up
again.
It's
only
going
to
be
fixes.
It's
only
going
to
be
whatever
anything
else.
You
know
is
tagged
and
just
waits
on
the
merge
queue
and
then
yeah.
D
I
would
actually
suggest
that
we'd
be
good
a
little
bit
even
more
more
overhead,
slightly
more
overhead,
but
I.
Think
if
we're,
if
we're
going
to
go
down
this
path,
then
so
say
four
weeks
out
is
where
we
kind
of
cuz.
We
don't
want
it
to
be
too
far
at
all,
but
we
do
want.
You
want
some
time
for
downstream
projects
to
be
able
to.
D
You
know,
schedule
the
process
of
running
these
extra
tests
or
means
you
don't
want
it
to
be
like
three
days
before
we
release,
because
no
will
be
able
to
do
it
on
that
kind
of
notice.
You
don't
want
it
to
be
like
two
months,
because
a
whole
bunch
of
other
crap
will
show
up
and
it'll
have
to.
If
we're
not
going
to
accept
it
and
let
the
sit-ins
become
stale.
D
D
You
know
give
us
the
list
and
we'll
go
through
it
and
decide
whether
or
not
we're
willing,
like
you,
have
to
tell
us
about
whatever
it
is.
That's
coming
essentially
right
and
get
it
otherwise.
Somebody
shows
up
with
a
fixin.
It's
like
well
three
lines
longer
than
the
you
know,
criterion
for
being
able
to
accept
this
thing,
and
it's
only
a
day
before
but
yeah.
Maybe
we
could
smiley
like
it's.
E
E
C
B
C
B
Or
is
even
something
that
the
committer
is
like?
A
bunch
of
us
are
going
through
and
tagging
stuff
anyway,
if
we
aren't
actually
doing
the
review.
If
it
looks
like
something
that
does
not
fit
the
criteria
right,
we
can
tag
it
as
such
and
if
the
contributor
or
the
committer
is
those
to
review
it
says
this
is
actually
really
important
for
the
release.
We
really
need
to
try
and
get
this
in.
Well,
then,
you
can
have
a
you,
can
go
okay,
well,
you
need
one
or
two
other
committers
or
you
need
a
lead
or
whatever.
B
B
D
But,
let's
be
clear:
I,
don't
think
we're
designing
anything
in
this
forum
right
now
we're
we're
having
a
discussion
which
I'll,
try
and
capture
parts
of
it.
I
know
I'll,
forget
parts
of
it.
So
I'll
ask
everyone
here
to
contribute
the
film,
since
my
brain
forgets
one
between
we
having
this
meeting
and
me
creating
this
issues,
but
I
will
try
to
do
it
soon
and
I
think
we
need
to
have.
We
need
to
make
sure
that
our
downstream
stakeholders
see
this
right,
because
this
is
a
change.
D
That's
going
to
impact
particularly
open,
j9
right,
because
open
genome
does
have
a
habit
of
just
contributing
stuff
whenever
it
wants
to
and
making
sure
that
they're
aware
of
the
changes
that
I
mean.
Obviously
we
have
open
genuine
contributors
and
emitters
here,
but
I
thought
the
broader
set.
I
think
need
to
be
aware
of
the
changes
that
we're
considering
here
and
making
sure
that
we've
started
socializing
and
why
we're
trying
to
do
that
and
what
expectations
they
should
have
going
forward.
So
everybody's
kind
of
on
on
board,
with
what
we're
doing
it's.
B
What
mark
emitters
are
going
to
behave
like
the
four
week
mark
and
at
the
two
week
mark
and
if
they
need
to
make
an
exception,
what
the
process,
what
the
can,
what
the
convention
is
or
doing
that
exception
in
a
way
where
it's
visible
to
the
project
and
accepted
by
the
people
responsible
for
signing
off
the
release
and
as
long
as
there's
a
document
that
says
that
and
we
communicate
on
the
dead
list.
We
are
in
this
period
and
somebody
opens
the
PR
and
we
go
that's
not
going
to
fit.
B
We
can
point
at
it
that
we're
we're
in
the
you
know,
release
zone
so,
and
this
is
going
to
wait
until
after
the
release,
we
can
continue
to
discuss
it,
but
I
won't
be
merging
it
until
after
the
release
branches
for
right,
then
it's
transparent,
there's,
no,
and
if
they
want
to
debate
that
well,
they
can
make
their
case.
And
you
know
even
at
the
project
leader
whatever,
if
they
don't
agree
with
the
committer
and
then
there's
a
final
decision
made
and
that
that's
it
that's
all
they
are
for
people
who
look
at.
D
The
link-
that's
all
I've,
got
in
my
feeble
brain
for
talking
about
this
topic
today,
like
I,
said
I'll
try
to
write
down
what
I'll
do
going
forward
from
this
is
I
will
try
to
write
down
the
net
of
this
discussion
into
an
issue
which
I'll
then
tag
into
the
agenda,
I,
guess
and
maybe
even
send
out
a
note
to
the
mailing
list,
just
because
it
is
such
a
relevant
project
level
topic,
and
then
we
can
continue.
The
discussion
there,
like
I,
said
if
I
forget
anything
I've
got
anything
wrong.
D
Please
feel
free
to
update
the
issue
with
the
the
information.
That's
right
and
I'll
tag,
some
of
the
open,
genuine
folks,
just
to
make
sure
that
we
get
the
right
feedback
from
them.
I'll,
peg,
dibyendu,
I,
guess
in
tease
the
other
primary,
all
more
consumer,
as
well
as
the
the
people
I
know
of
who
work
on
various
pit
builder
reports
that
based
Portsmouth
that
are
out
there
every
time,
the
really
five
guys?
Yes,
yes,
good
point
and
and
we'll
start
collecting
feedback.
D
Obviously,
if
we're
talking
about
a
release
in
February,
it's
not
super
urgent
that
we
decide
this
soon,
but
I
think
you
know,
given
that
we've
had
this
topic
now,
it's
kind
of
hot
in
her
mind.
So,
let's,
let's
set
up,
let's
see
the
next
couple
of
weeks,
are
kind
of
ugly
with
Cascone
and
all
that
prep
and
other
things
happening.
So
maybe
something
like
November
or
something
will
try
to
drive
to
a
conclusion
on
all
of
this
so
that
at
least
we
know
what
we're
doing
and,
like
I
said,
not
written
in
stone
tablets.