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!