►
From YouTube: Backdrop CMS weekly meeting 8/14
Description
Status update
A
A
B
B
Which
I'm
not
really
sure
how
many
people
that
is,
but
it's
the
only
core
thing
we
have.
It
will
move
you
from
using
the
hardtick
layouts
to
using
a
layout
module
provided
layouts,
and
I
think
once
we
get
that
upgrade
pack
in
place,
we
should
make
it
so
that
any
other
layouts
that
you
are
upgrading
from
a
custom
theme
to
to
backdrop.
If
the
theme,
regions
and
the
layout
regions
are
aligned,
then
blocks
will
be
removed
from
your
drupal
7
regions
into
your
into
your
backdrop,
1.0
layouts.
B
So
it's
all
looking
really
pretty
good
and
see
I'm
also
working
on
wiring
it
up
so
that
it
actually
takes
over
the
entire
page.
So
the
way
layouts
are
going
to
work
in
backdrop.
Land
is
they're
going
to
be
the
entire
page
rather
than
like
panels
generally,
is
it's
like
panels
everywhere?
Let's
just
say
it
that
way
that
you
won't
have
any
regions
on
in
your
themes.
Instead,
layouts
will
be
providing
the
entire
page
layout.
A
B
B
A
Okay,
okay
views
and
core:
we
need
some
help
with
some
of
the
conversions,
but
all
the
major
stuff
is
done.
So
that's
good
we're
moving
forward
on
that
front.
Config
management
has
been
getting
a
lot
of
attention
lately,
which
is
great.
We
need
help
with
some
of
the
more
complicated
conversions
like
fields,
because
if
we
don't
have
fields
converted,
we
don't
really
have
cmi,
but
I
know
that
we've
made
a
ton
of
progress
on
everything
else.
A
All
the
variables
are
almost
all
converted.
We've
got
a
whole
bunch
of
subsystems.
Converted
I
know
nate
did
a
complete
rework
of
the
format
translation,
because
how
it
was
being
done
in
drupal,
7
was
kind
of
ridiculous
and
how
it
was
being
done
in
drupal.
8
was
really
different,
and
so
I
don't
know
if
you
want
to
give
us
an
update
on
that.
B
Yeah
paul
did
all
of
the
conversions
from
triple
seven
to
backdrop,
but
then,
after
looking
at
it
and
needing
to
do
the
upgrade
and
then
looking
at
what
triple
8
did
really.
We
just
looked
at
the
way
date
formats
worked
and
decided
that
it
really
needed
to
be
revamped
in
terms
of
the
ui,
because
it
was
so
painful
setting
up
date
formats
and
then
localizing
them
that
that
we
rebuilt
some
of
the
uis
to
make
it
easier
to
input
the
information
which
also
in
turn,
may
be
easier
to
store.
So.
B
A
B
Yeah,
the
the
big
thing
that
we
don't
have
and
no
one
is
working
on
as
far
as
I
know,
is
converting
fields
and
conduits
and
that's
definitely
the
biggest
thing.
The
biggest
test
of
our
system
is
getting
those
converted,
so
those
are
definitely
the
highest
priority
and
also
our
biggest
walkers
for
one
point
definitely
super
high
priority,
but
it's
also
just
really
complicated.
B
A
All
right
so
then,
in
terms
of
other
stuff
that
we're
working
on
we've
got
cross
ports
from
drupal
7,
so
this
incur
includes
the
security
releases,
there's
a
whole
bunch
of
security
releases
lately
that
we
now
have
new
issues
for
that
need,
review
and
application
and
there's
a
whole
bunch
of
well
actually
not
that
many,
but
other
changes
that
went
into
triple
seven.
Recently
we
introduced
a
serious
bug
and
then
fixed
it.
So
we
should
get
those
the
same
solutions
into
backdrop.
A
Hopefully
you
know
all
at
the
same
time,
and
then
we've
got
some
drupal
8
back
ports,
we're
working
on
too
a
whole
bunch
of
the
html5
stuff
is
done.
We've
got
a
bunch
of
new
progress
on
css
stuff
in
javascript
cleanup,
so
those
I
wouldn't
update
all
the
those
numbers
today
and
then
there's
a
whole
bunch.
More
pull
requests
now
assigned
to
me
to
review
so
I'll.
A
A
A
A
We
were
all
sitting
around
the
table
talking
about
like
oh
you
know,
maybe
we
she's
a
hedgehog
or
maybe
we
should
try
and
come
up
with
an
animal
that
we
thought
would
work
and
somebody
at
the
table
was
like
you
guys,
should
use
a
dragon
and
I
got
so
excited
because
I
love
dragons
and
then
he
hadn't
even
thought
about
it
and
nate
was
not
sure
he
was
like.
I
don't
know
about
this,
but
then
everybody
around
the
table
had
all
of
these
great
reasons
why
we
should
have
a
dragon.
A
A
I
decided
on
a
dragon
early,
but
I
think
nate's
finally
been
convinced
that
we
should
have
a
dragon
for
a
mascot
and
so
we've
hired
a
illustrator
to
draw
some
pictures
of
said
dragon
and
to
give
them
a
little
direction.
We
didn't
want
to
be
like
a
big
ferocious
dragon.
We
wanted
to
be
like
a
very
approachable,
friendly
dragon,
and
so
we
told
the
designer
that
we
wanted
a
lap
dragon
kind
of
like
a
lap
dog
like
a
small
one.
A
That's
like
you
know
cuddly
and
the
the
designer
we
talked
to
loved
it
and
was
totally
running
with
it.
So
we'll
see
we'll
see
what
we're
gonna
get
from
them
in
terms
of
illustrations,
but
I
think
that
it'll
be
something
that'll
be
really
great.
We
can
have
a
lot
of
fun
with
and
everyone
else
can
have
fun
with
too
so.
I'm
very
excited
about
the
dragon.
A
So
I
was
very
excited
about
the
dragon
nate's
now
on
board
about
the
dragon,
and
then
we
so
we
beta
tested
it
with
our
table
of
10
people
and
10
out
of
10
drupal
developers
agreed
that
backdrop
should
be
a
dragon
and
then
the
next
day
we
went
and
like
ran
around
the
whole
camp
and
we're
like
what
do
you
think?
What
do
you
think
and
then
it
became
like
30
out
of
30
and
then
last
week,
when
we
were
in
twin
cities,
we
ran
it
by
a
hundred
more
people
and
everybody
is
just
like.
A
Yes,
you
should
be
the
dragon
so
yeah.
It
was
great
like
every
time
we
talked
to
someone
they
had
like
another
clump
clever,
like
gimmick
to
attach
to
like
a
dragon
and
backdrop,
and
so
I
was
just
like
okay.
This
is
happening
like
so
dragon
underway.
I'm
really
looking
forward
to
seeing
what
it'll
look
like
so
yeah,
no
more
droplets
for
us,
we're
now
dragons
all
right,
so
other
stuff,
we're
working
on
user
experience.
A
Improvements,
we've
already
done
a
lot
in
terms
of
like
adding
the
admin
menu
and
making
it
responsive,
and
we
changed
names
of
stuff,
like
the
main
top
level
link
where
you
turn
on
modules,
is
now
called
functionality.
But
then,
when
you
drop
down,
there's
still
like
it's
still
the
modules
page.
So
I
don't
think
we
need
to
like
worry
about
breaking
any.
A
A
Teach
people
like
how
to
find
the
things
that
teach
new
people
how
to
find
the
things
that
old
people
already
know
and
old
people
will
be
like
where's,
the
modules
page
and
they'll
hover
over
each
item
and
when
they
see
functionality,
it'll
save
modules
and
they'll
be
able
to
find
it
that
way
too
nate
and
I
both
found
ourselves
being
retrained
by
the
admin
menu
after
we
started
using
it
like.
Oh
look,
it
works,
that's
funny.
A
A
So
I've
been
working
on
killing
the
process
layer
on
the
plane
lately,
every
time
I'm
on
the
plane,
I'm
like
kill
another
function,
so
hopefully
we'll
get
that
in
soon
and
then
there's
a
bunch
of
other
little
cleanup
stuff
too,
that
I
think
other
people
are
working
on.
But
for
the
most
part,
most
theme
system
cleanup
will
happen
after
layouts,
which
is
more
important
and
will
of
course
affect
how
theme
layer
works
too.
A
A
Why
do
we
even
have
these
options
for
choosing
sql
light
or
postgresql
when
you're
installing,
and
so
I
created
an
issue
and
was
like
well
if
you're
trying
to
run
a
drupal
7
site
on
sqlite
you're,
doing
it
wrong,
so
it
shouldn't
be
in
the
installer
anyway,
like?
Is
there
even
a
valid
use
case
for
this
being
here
and
some
of
the
issue
chimed
in
and
said?
Oh,
I
do
that
for
testing
sometimes
so
I
was
like
okay.
A
Well,
that's
fine,
but
I
don't
think
that
that's
you
know.
That's
just
doesn't
qualify
for
80
use
cases
for
random
developers
that
can
do
testing
sometime.
So
it
was
a
pretty
easy
no-brainer
to
remove
sql
light
support,
but
then
that
bigger
option
was
postgraph
support,
which
was
also
in
that
list
and
it
was
like
well
drupal
says
it
supports
postgres.
But
if
you
try
and
run
a
drupal
site
on
postgres,
you
find
out
pretty
quickly
that
contrib
doesn't
actually
support
postgres.
A
So
why?
Why
do
we
say
it's
supported
when
the
people
who
try
and
run
it
end
up
having
a
kind
of
a
painful
and
miserable
experience
doing
so
so?
Okay?
What
would
what
would
it
look
like
if
we
removed
postgres
support?
Like
you
know,
eighty
percent
of
our
people
are
definitely
gonna,
be
running,
my
sequel,
so
that
kind
of
fits
into
backdrops
mentality
of
well.
A
So
we
pulled
out
sql
light
support
and
we
pulled
out
postgres
support,
and
then
we
removed
a
bunch
of
the
like
looping
and
switching
that
happens
in
core
to
try
and
figure
out
which
database
engine
you're
running
so
now
mysql
is
hard-coded
in
there
and
everywhere.
There's
a
query.
It
just
says
you
know
do
this
for
my
sql,
it
doesn't
say:
oh
wait.
A
If
it's
postpressed
do
something
else
or
let's
see,
why
do
something
else,
so
we
haven't
done
any
benchmarks,
but
I
would
guess
that
that
might
have
made
things
a
little
bit
more
straightforward
in
terms
of
performance.
It
definitely
is
going
to
make
things
a
lot
more
straightforward
in
terms
of
what
our
code
is
going
to
look
like
long
term
short
term,
it's
very
similar
to
drupal
7,
just
without
the
switching
and
looping,
and
that's
just
for
kind
of
backwards.
Compatibility
like
if
people
have
done
anything
in
contrib
for
7.
A
That
needs
to
do
the
same
kind
of
thing
in
backdrop
having
it
work
the
same
way,
I
think,
is
going
to
be
good,
but
we're
paving
the
path
to
backdrop,
two
removing
all
of
the
the
you
know
the
subfolder
for
my
sequel
and
all
the
other
stuff
too.
So
I
think
that
you
know
if
we
have
time
to
do
some
extra
cleanup
between
now
and
launch.
There's
a
you
know,
good
reason
to
do
that,
but
it
works
the
way.
A
B
If
not
update,
then
insert
we
can
update
db,
merge
to
use
the
mysql
specific
syntax
for
that
which
neither
postgres
or
sql
light
support.
So
therefore
reducing
it
from
a
select
plus
update,
which
also
has
race
condition,
problems
to
just
being
insert
if
not
or
update,
if
not
insert
statements
which
only
mysql
supports.
So
we
have
opportunities
to
do
like
database
specific
enhancements
now,
and
we
can
also
do
things
like
not
worry
about
things
like
casting
strings
to
lower
before
doing
comparisons
when
doing
selections,
because
my
sql
is
case.
B
Insensitive
but
postgres
is
case
sensitive,
it's
going
to
make
it
so
that
we
can
optimize
situations
to
make
it
so
that
we
can
use
the
particular
like
peculiarities
of
my
sequel,
whether
or
not
they're
actually
faster
or
not.
We
don't
need
to
start
like
hobbling.
All
of
our
database
queries
to
make
it
compatible
with
other
stuff.
B
So
overall
yeah,
it's
gonna
have
a
good
performance
impact
on
us
in
1.0,
just
by
making
it
so
we
can
use
my
sql
specific
stuff
and
in
2.0
we'll
see
if
we
can
actually
remove
dbtng
to
lessen
the
lower
to
lessen
the
learning
curve
and
also
to
help
performance
through
its
removal.
So
but
that's
that's
long
term,
just
hoping
that
that
can
happen.
A
Yeah,
okay,
sorry,
I'm
getting
lost
so
yeah,
that's
exciting
for
referrals
things
not
related
to
the
backdrop
project
itself,
but
things
that
we'll
need
as
a
community.
The
api
website
is
underway.
Luke
is
working
on
it
chatted
with
him
about
it.
Last
wednesday
after
the
east
bay
drupal
user
group
meeting-
and
he
had
some
good
ideas
about
how
to
do
stuff
so
hopefully
we'll
be
able
to
connect
with
him
soon
and
get
that
it's
it's
already
up
on
api.backdropdms.org.
A
A
Editing
skills,
it's
maybe
more
important
once
we
have
software
that
needs
to
know
if
it
needs
to
be
updated,
so
less
urgent
than
working
on
the
project
itself,
but
you
know
still
important
and
then
a
github
service
so
that
people
who
create
github
can
chip
projects
can
register
their
things.
With
the
backdrop,
cms
primary
website
is
going
to
be
important
as
well
and
then,
of
course,
a
little
work
on
the
primary
website.
If
we
have
until
fall
to
get
the
product
out,
I
think
that
that
is
good.
A
I
think
it
would
be
good
if
we
got
our
actual
brand
on
our
own
website
when
the
product
comes
out,
so
we
did
contact
the
lady
who
is
in
charge
of
our
graphic
designer.
We
asked
her
if
she
would
be
able
to
kind
of
help
us
take
what
we
get
from
him,
plus
what
we
have
in
terms
of
our
own
branding
and
mock
up
something
for
our
own
website
to
kind
of
have
down
around
the
same
time.
So
I
think
it
might
be
good
to
look
at
getting
some
theme
resources.
A
So
someone
who
has
some
theming
skills
who
wants
to
work
on
our
primary
website
might
be
a
good
idea
too,
because
I
have
feeling
we'll
probably
all
be
busy
working
on
the
backdrop
code,
but
that
is
moving
forward,
though
probably
slowly
and
then
upcoming
sprints.
So
we're
going
to
be
attending
we're
we're
not
going
to
drupalcon
amsterdam
this
summer,
which
was
we
originally
thought.
We
would
primarily
just
because
it's
expensive
to
get
to
europe,
but
also
because
that's
not
really
our
target
audience
anymore.
A
Most
of
the
developers
who
are
going
to
meet
at
drupalcon,
especially
in
europe,
are
the
ones
who
are
very
excited
about.
What's
going
on
in
drupal,
8
and
talking
to
them
about
backdrop,
isn't
really
highest
priority,
I
mean
it's
good
to.
You
know,
obviously
keep
lines
of
communication
open
with
all
the
people
working
in
drupal,
but
taking
a
really
expensive
trip
to
a
conference
where
nobody
really
wants
to
hear
what
you
have
to
say
anyway
seems
like
not
the
best
way
to
do
that.
A
At
the
same
time,
we've
been
specifically
contacted
by
owners
of
camps
here
in
the
u.s
who
are
saying
you
know,
people
in
our
community
want
to
know
about
backdrop.
Would
you
please
come
to
the
pacific
northwest
triple
summit
or
drupal
camp
la,
and
so
we
feel
like
it's
better
to
go
where
we're
wanted
and
requested
than
it
is
to
go
somewhere
that
you
know
we
might
really
like
europe,
but
how
much
good
does
that
really
do
for
backdrop
to
go
there?
A
C
A
To
those
people
about
backdrop-
and
I
think,
that's
kind
of
a
better
use
of
our
dollars
as
well,
and
I
think
it
would
be
great
if
we
can
organize
sprints
at
those
events
again
pending
organizer
feedback
and
if
possible,
you
can
sponsor
those
spreads,
and
if
we
can
do
another
thing
like
we
did
at
drupalcorn,
where
we
sponsor
both
backdrop
and
drupal
development.
I
think
it'll
also
add
some
goodwill
into
the
general
community
about
backdrop
too.
So
I'm
I'm
looking
forward
to
both
of
those
events.
A
C
I
just
had
a
question
about
the
trib,
so
you
guys
haven't
made
any
progress
on
that
since
the
last
time
I
tuned
in
and
the,
but
you
are
so
the
patch
I
submitted
to
the
xml
rpc
or
was
that
it
whatever
module?
One
of
the
modules
that
got
kicked
out
that
was
turned
into
a
backdrop.
Module
that
exists
on
github
was
patched
and
updated.
C
So
there
are
modules
out
there
that
exists
already,
that
people
may
want
to
be
able
to
put
back
in
to
get
the
functionality
that
they
were
hoping
for.
I've
started
the
city
crm
for
of
the
drupal
7
and
8
work
to
get
that
functionality
working
so
that
exists,
so
how
this
is
actually
going
to
work.
I
I'm
really
interested
to
figure
it
out.
Last
week
we
also
started
white
listing
modules
and
themes
that
are
posted
on
github,
so
they
can
be
pulled
into
distributions.
C
Now
they
still
have
to
be
meet
the
gpl
requirements,
but
users
no
longer
have
to
go
through
project
review,
hell
being
told
that
they
have
not
enough
white
space
or
too
much
white
space,
and
that
determines
whether
or
not
they
can
actually
publish
their
code.
So
so
there's
definitely
interest
in
developing
on
github,
regardless
of
whether
it's
funneling
into
drupal
or
backdrop,
but
I
feel
like
without
any
kind
of
structure.
It's
really
impossible
to
do
anything
with
that.
At
this
point,.
A
We
haven't
set
up
any
of
the
structure
or
even
documentation
on
this
yet
because
I
think
we
want
to
try
it
and
see
if
it
works,
but
the
general
idea
is
that
anyone
in
the
world
can
create
a
project
for
backdrop
and
check
the
little
tick
box,
which
was
a
service
and
that
will
help
show
up
as
the
equivalent
of
like
a
sandbox
project
on
backdrop's
website
in
order
to
register
as
an
official
project.
You'll
need
to
log
in
to
backdrop
website
create
a
page.
That's
of
course
not
possible.
A
Yet,
just
as
that,
you'd
have
a
real
project
page
on
drupal.org,
and
so
you
can
then
add
comments
and
links
to
documentation.
Your
issue
queue
whatever
else
you
want
to
put
on
there.
We
also
have
this
concept
of
having,
like
backdrop
supported
modules
and
that's
something
that
we
can
basically
guarantee
an
upgrade
path
for
so
things
that
are
going
to
be
in
core
in
the
future
stuff
like
that
and
and
as
people
create
modules
and
we
decide.
A
Oh,
this
is
80
use
case
we're
going
to
support
it
and
the
only
difference
between
like
joe
schmo,
creating
a
module
and
a
backdrop
supported
module
would
be
the
owner
of
that
project.
So
if
you
have
a
backdrop
supported
module,
it's
going
to
be
owned
by
the
backdrop
kintrib
group
on
github
and
that
way,
if
the
joshua
who
created
it,
takes
off
and
leaves
we
don't
have
to
worry
about
like
how
do
we
you
know?
Do
we
fork
that
project?
How
do
we
deal
with
it?
A
Long
term
it'll
just
be
any
one
of
the
backdrop
core
team
who
can
take
care
of
any
other
backdrop.
Core
module
can
also
take
care
of
this
backdrop,
core
module
or
sorry
contrib,
keep
saying
so
all
the
backdrop
kinship
people
can
take
care
of
all
the
backdrop.
Control
modules
avery
doesn't
have
to
apply
to
commit
something
to
my
project.
You
know
in
a
dribble.org
way
everybody
kind
of
owns
their
own,
but
it's
all
in
the
same
place
and
you
can
move
them
around
in
github.
A
There
isn't
that
same
kind
of
flexibility,
so
we
don't
want
to
rely
on
the
people
who
created
the
project
to
maintain
it
long
term
if
they
don't
want
to,
but
we
don't.
We
obviously
don't
have
anything
in
the
backdrop
contrib
group
right
now
we
have
a
group,
but
I
don't
think
there
are
any
people
in
it.
I
don't
think
there
are
any
modules
in
it.
I
think
that's
the
kind
of
place
where
I
don't
know
that
xml
rpc
would
go
there,
because
I
don't
think
it's
something
that
the
backdrop
team
wants
to
maintain
forever.
A
I
think
the
xml
or
pc
module
needs
to
have
its
own
maintainer
and
out
in
individual
land
rather
than
as
part
of
a
group,
but
we
do
have
some
things
that
we
know
are
gonna
put
in
there
and
as
soon
as
we
start
building
sites
on
backdrop,
I
think
it'll
become
obvious,
which
ones
those
are
like,
like
looking
at
the
list
of
modules
that
are
included
in
drupal
8
might
be
a
good
starting
point
like.
Oh
you
know:
email
module
or
link
module
like
stuff.
A
That
we
think
is
a
definite
80
use
case
thing.
We
want
to
be
able
to
provide
an
upgrade
path,
not
only
from
7
to
backdrop,
but
also
from
backdrop
contrib
to
backdrop
core.
If
that's
where
it's
going,
and
in
order
to
do
that,
we
need
to
have
control
of
of
that
module
before
it
goes
into
course.
So
we
can
guarantee
that
painless
transition.
A
But
of
course
we
don't,
we
don't
haven't
tried
it.
We
don't
have
any
process
in
place.
We
don't
know
if
it's
going
to
work,
we
just
have
kind
of
ideas
about
how
it's
going
to
work.
I
know
that's
frustrating
for
you
because
you're
like
what
do
I
build
now,
I
think
probably
the
advice
would
be
like
if
you're
going
to
be
working
with
your
project
on
github,
the
first
step
would
be
like
making
sure
we
have
that
checkbox.
You
can
say
this
is
a
github
project.
A
The
second
step
would
be
or
sorry
back
to
our
project.
The
second
step
would
be
having
the
page
on
backdrop's
primary
website.
That
says
you
know
supercrm
for
backdrop
and
links
to
wherever
it
is,
and
then
the
third
step
would
be
like
how
to
you
know.
How
does
it
work
in
terms
of
like
managing
your
own
issue
queue
and
tying
in
with
your
projects
you're
contributing
to
drupal
and
installers,
or
everything
else,
and
we'll
kind
of
figure
out
the?
A
How
does
it
fit
into
the
backdrop
landscape
once
we
have
things
to
fit
into
the
backdrop
landscape,
so
getting
feedback
from
you
and
saying,
like
you
know,
I
don't
like
the
way
my
readme.md
file,
as
shown
on
the
backdrop
website
or
whatever
it
is,
is
going
to
be
useful,
but
we
don't
have
anyone
doing
that.
Yet
we're
still
a
couple
steps
behind
in
terms
of
contrib,
so
I'm
not
sure
how
helpful
that
answer
was.
C
Well,
it's
I
mean
you
guys
are
talking
about
a
fall
1.0
release,
I'm
trying
to
figure
out
how
much
work
it's
going
to
take
to
keep
different
projects
compatible
and
make
them
compatible
with
backdrop,
and
so
I
feel
like
if,
if
your
release,
1.0
release
is
fall,
then
now
would
be
the
time
where
I
would
actually
be
able
to
figure
that
out
or
I'd
be
getting
closer
to
being
able
to
figure
that
out.
So
I
feel
like.
A
I
would
say,
because
we
don't
have
any
like
existing
infrastructure
too.
Now
is
too
soon
for
you
to
be
able
to
figure
that
out.
We
need
to
go
through
a
couple
of
different
stages.
Right,
like
we've,
we've
got
to
get
a
beta
right,
which
is
like
our
apis
are
frozen,
and
at
that
point
you
at
least
know
like
what
your
code
looks
like
and
then,
after
that,
it's
like.
Okay.
Well,
now
that
our
apis
are
frozen,
we
know
that
there's
going
to
be
contrib
trying
to
figure
out
how
to
do
this.
A
So
then
we've
got
to
start
building
the
landscape
freaking
chip,
so
I
would
say
until
we're
in
beta
it's
going
to
be
really
hard
for
you
to
figure
out
what
to
do
with
your
projects,
and
you
won't
necessarily
know
how
much
is
going
to
change
in
how
much
it's
not
going
to
change
between
7
and
backdrop
until
we
have
that
like
api's
frozen
state.
So
I
don't
know
in
terms
of
timeline
when
that'll
be
we've
got
obviously
our
biggest
release.
A
A
Right,
that's
not
gonna,
not
gonna,
be
an
api
break
to
replace
a
core
listing
with
vue,
so
yeah,
I
think
I
think
just
getting
getting
those
done
will
help
kind
of
set
our
timeline
for
when
we're
going
to
be
able
to
have
alpha
beta
and
release
candidate,
and
we
can't.
I
don't
think
that
our
focus
is
going
to
be
on
the
kinship
stuff
until
we
get
to
that
point
just
because
they're
you
know
we
want
to
make
sure
we
get
there
yeah.
So
it's
probably
too
soon.
B
I
think
it
could
also.
Maybe
we
need
to
discuss
this
more
be
used
as
like
any
module
that
wants
to
basically
have
shared
responsibility
like
I
do
think
that
if
it's
in
the
backdrop
contrib
group,
then
that's
kind
of
like
a
blessed
contrib
like
saying
that
we're
going
to
take
responsibility
for
maintaining
these
modules
and
those
are
the
ones
that
get
security
reviewed,
and
it's
also
the
ones
that
you
would
have
a
group
of
people
who,
as
a
as
a
community,
would
be
responsible
for
maintaining
all
of
them.
B
But
I
don't
think
that
it
necessarily
means
that
those
have
to
be
modules
that
their
long-term
plan
is
to
be
moved
into
core.
I
think
it
could
be
used
for
for
any
module
that
is
of
sufficient
popularity
and
utility
that
it
needs
to
be
updated
from
version
of
version
maybe
permanently
as
a
contrib
module.
B
Yeah,
I
think
maintaining
the
module
on
drupal.org
and
github
is
really
one
of
the
more
difficult
problems,
because
you
don't
want
to
split
your
issue
tracking
between
the
two
places
right
and
so
so.
I
think
it
would
be
totally
reasonable
to
only
manage
your
project
in
one
of
those
two
places
issue
wise
and
redirect
the
user
to
the
other
location
and
then
use
the
other,
the
other
repository
as
a
mirror.
So
whether
github
is
the
mirror
or
drupal.org
gets
the
mirror
either
way.
B
But
I
think
the
repository
for
all
code
should
live
in
the
same
place
rather
than
having
one
repository
for
backdrop
code
and
one
for
for
drupal.
If
you're
going
to
be
maintaining
both
of
them
for
the
time
being,
it
might
be
easiest
to
maintain
them
within
one
project
with
multiple
branches.
One
for
backdrop,
one
two
triple
seven
and
then
manage
all
of
the
the
problems
all
in
one
location.
For
the
time
being.
C
That
really
opens
up
a
lot
of
possibilities
again
limited
to
mainly
distributions
and
sites
built
exclusively
with
rush.
I
it
it
gives
people
an
out
at
this
point
of
getting
off
of
drupal.org
as
the
primary
repo.
So
we've
already
started
moving
modules
off
of
drupal.org
that
are
only
used
within
distributions
by
and
I
think
we're
gonna
end
up
doing
the
same
thing
with
city
crm.
C
There
is
a
branch,
a
very
dated
branch
on
drupal.org
from
the
work
that
was
in
github,
but
now
we're
able
to
allow
people
to
include
that
project
by
simply
using
the
make
file
build.
But
the
other
question
I
had-
and
I
don't
know-
maybe
there
is
a
way
to
do
this
in
github.
If
I
use
a
tool
to
move
a
module
to
drupal
or
to
github
from
drupal.org
or
I've.
A
C
A
B
B
No,
it
looks
it
looks
like
it's
here
just
as
well,
so
I
just
checked
in
in
github,
you
go
to
the
settings
in
the
right
hand,
side
and
then
you
go
to
web
hooks
and
services
and
it
looks
like
even
forks
can
have
services
integration
like
there's
the
service
for
the
jquery
plugins
repository
and
that's
what
we
I've
been
saying,
we're
going
to
model
our
trip
around.
Is
you
just
take
a
github
repository?
B
You
go
to
web
hooks
and
services,
and
then
you
say
this
is
a
backdrop
module
and
then
that
will
integrate
it
with
back.cms.org,
and
I
know
that
this
works
for
other
services
because
I
actually
have,
like
my
personal
fork
of
backdrop,
wired
up
to
travis
ci,
so
that
when
I
do
pushes
to
my
fork,
it
triggers
on
travis.
So
it
looks
like
I
mean,
even
a
fork
of
another
project,
you
could
actually
register
with
backdrop
cms.org,
but
then
I
think
like
jquery
and
register
it.
A
I
mean
that's
what
we're
talking
about
like
with
the
you
know,
forking
and
drupal
module,
that's
something
that's
registered
as
like
a
drupal
project
and
now
you're
saying
it's
not
triple
anymore.
It's
backdrop:
oh
you're,
when
you
said
jquery,
do
you
mean
like
jquery
update
or
I
meant
like
jquery
itself,
but
that
was
a
very
extreme
example
yeah,
but.