1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
|
---
breadcrumbs:
- - /teams
- Teams
- - /teams/layout-team
- Layout Team
- - /teams/layout-team/meeting-notes
- Layout Team Meeting Notes
page_name: may-28-2015
title: 'Thursday, May 28, 2015: Layout Moose post BlinkOn Sync Up'
---
a.k.a. the project formerly known as "the grand layout re-factoring" and briefly
as "layout slimming"
Attendees: eae, leviw, esprehn, jchaffraix, ojan, cbiesinger, dsinclair
<eae> Thanks for organzing Levi, I'd like to get a quick update, hear
concerns and discuss logistics.
<jchaffraix> I'm concerned about a lack of transparency, meeting notes not
getting out and key people being excluded from meetings.
<ojan> Been meaning to send out notes from BlinkOn sessions, oversight
that they weren’t. Not intentioanlly exlcuding anyone.
<ojan> How do we ensure everyone’s on board?
<eae> I’ve stayed out of the technical part of the discussion to avoid
having yet another cook in the kitchen. Now I want to make sure we have a plan,
circulate it, and ensure we’re moving forward.
<jchaffraix> We need to ensure we have a concrete roster and include all
steakholders.
<eae> We have that.
<ojan> We just didn’t have a chance post-BlinkON to send out the notes. We
weren’t trying to be exclusive.
<ojan> Dan, it sounded like maybe you wanted to be included too?
<dsinclair> I’m interested because it seems like the future, but couldn’t
go to the meetings because of timezones.
<ojan> Sydney + Waterloo is hard.
<esprehn> Ian K will be moving here so we won’t have to keep having Sydney
time zone involved.
<ojan> For future reference voice if you want to be involved. I’ll try to
keep sending emails to layout-dev to tell people ahead of time when there will
be meetings.
<eae> Things will be easier when discussion go from being predementantly
brainstorming and turn into more of a concrete plan. Circulating an actual
design will help guide the discussion.
<ojan> Let me summarize our discussions and current thinking:
- There are a certain set of features we want to achieve (measure, fragments,
async append).
- All these have require things that are hard to do in the current codebase
- We also want more sanity and understanding in the codebase.
- We took our brainstorm and turned it into a slightly more concrete set of
proposals (v1, v2, etc.)
- Added psuedocode
- Result proves some of our ideas, but not necessarily the feasibility of the
approach.
- Doc still isn’t really ready for external consumption
- Next step is to put current box layout code behind an API, then there’s the
controversial step of re-implementing that api behind a flag.
- Unsure of the sense of time required here (somewhere between 3 months and 3
years).
- Important to see the API requirements ahead of time to understand.
<esprehn> Implementing the various box layout algorithms is a relatively
easy exercise.
<ojan> We all agree what the first step is an API. We should do that then
see about next steps.
<jchafrraix> We don’t \*need\* that API.
<eae> We don't but I think we want it regardless.
<jchaffraix> Do we really want to put this in the critical path since
we’re now gating everything on this?
<eae> It fits with our overall goals of a layered platform and it isn't
necesarrily gating other work. Other than opertunity cost of work we could be
doing instead.
<esprehn> This will allow us to enforce sanity.
<jchaffraix> You don’t need to sell me on the API. My point is whether or
not this should be the priority.
<eae> That is a discussion for our OKR meetings. We don't need to resolve
that here today.
<ojan> What happened in Sydney was that we had had a hackathon meeting
where we started working on a Line Layout API. It’s possible that we’ll get
1/3rd the way through this and decide that it doesn't work and have to start
over. We ended up with a patch that moves a handful of Line Layout accessors
into the box tree into an API.
<esprehn> We should do Paint next.
<ojan> My perspective is the next step is to get someone to own the line
layout api patch and get it landed.
<jchaffraix> It seems odd we’re not designing this api, but just grabbing
the things we’re using.
<leviw> Designing it is step 2.
<ojan> We didn’t know exactly what methods are currently in use. The next
step is refactor how the API is used and make it sane.
<eae> Next thing I'd like to see is a 1-pager of our plan, shared with
layout-dev, and a high level overview of what we want in terms of an evental
API.
<ojan> That’s hard to plan ahead of time, we don't know what the API is
going to look like it.
<eae> This could be a living document, maybe that section is blank to
start. Having a document would be super useful as would having an owner.
<ojan> Someone should draft this document and share it around.
\* ojan stares at levi \*
\* levi is volunteered \*
<eae> Assuming this is something we want to work on in Q3, we should have
this document ready in the next couple weeks. It would also be useful to have
something like this for the “v2 rewrite the world” approach.
<ojan> On my todo list is to take the doc we have today and turn it into
something an outsider can read.
<eae> Great! Current doc unreadable unless you where in all the meetings.
Would be useful to have something more concise.
<ojan> Seperate tasks (from nduca); taking all our layout-related
rendering leads items and drawing a chart that tells us what we need to do to
implement all of them. Here’s this proposal that let’s us do them, here’s what
it would take to do it incrementally and how long, etc.
<eae> I agree but having the API doc is the highest properity for me.
<esprehn> Boundaries would exist between layout, paint, dom, editing APIs.
Woudln’t be super disruptive. Then we’d have a real list of where we’re actually
interacting with the layout tree.
<dsinclair> Sounds like someone else will own all clusterfuzz bugs --
hooray!
\* everyone hooray! We haz plan! \*
<eae> As for the API document, I'd really like to see it ready for
circulation in the next week or two to allow it to be circulated and reasoned
about in time for setting the Q3 OKRs.
\* eae looks at Levi \*
<leviw> This shouldn’t block anything.
<ojan> Mark pilgrim would be a good guy to run with the layout stuff once
it’s started.
<ojan> I keep hearing people say “Should I not do this because Moose” and
I say Noooooooooooo.
<leviw> Ties in with much of our, and Dans, previous work. Should not
block.
<dsinclair> Do we know what all our API boundaries are?
<ojan> We know the big ones. We don’t necessarily need to know \*all\* of
them. (line, paint, dom, editing)
<esprehn> Chris says they’re aiming for 45-46 to rip out paint stuff. Is
optimistic. Hope that by December we should be able to take out tons of
compositor-related stuff. Shouldn’t focus on that api surface. Editing will be
so gross we’ll have plenty to do without the compositor.
\* levi makes moose noise \*
<eae> That’s a wrap!
|
