Intent to Implement integration?

[J. Ryan Stinnett]

Something I've seen the Chrome DevTools team do on occasion is chime
in on their version of the various "Intent to Implement / Ship" type
emails (for Mozilla these typically go to dev-platform) with a note
like:

<example>
Re: Intent to Implement XYZ

Here's a link to bug 1234 to build tools for crazy awesome thing XYZ
from your friendly neighborhood DevTools team.
</example>

This way, we might get more consistent coverage of platform tech as
it's being implemented in Gecko. Or at least, it creates a space to
discuss tools for a thing we know the platform team is working on.

Anyway, this is just a thought, and maybe it doesn't make sense. What
do people think?

- Ryan

[Jeff Griffiths]

I think it's a good idea to send that email, as long as it is true. Implied
by those blink / chrome emails is a regular process at Google where they
evaluate all platform projects and discuss tooling. We don't have a
formalized process with them - we probably should?

Jeff

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

[Nick Fitzgerald]

+1

We should be talking with platform folks from day 1.

On Sun, Mar 29, 2015 at 10:49 PM, Jeff Griffiths <jgrif...@mozilla.com>
wrote:

[J. Ryan Stinnett]

Right, it does imply some kind of platform triage process like this. I
am not sure what mechanism is best to stay on top of platform work, or
who is best to tackle the communication needed.

However, something like this could be a wonderful ideal to strive for:

1. Platform is planning to start working on big thing X we want everyone to use
2. DevTools knows what they are up to (somehow) and plans tools for X as well
3. Both teams can work on things iteratively, so thing X and tools for
X can be developed in tandem
* Our tools are not just good for web developers, it can help
platform hackers understand their own features, as well as what we
need from them for our tools.
4. Platform eventually announces X will ship, and DevTools can say
something like "...and it will have tools too!"

Now, maybe that's *too* ambitious...? We can only do so many things,
so today we like to see what platform features people will use before
investing in tools. But looking at it the other way, people would
probably use a lot more platform features if they only had tools! :D

I do think it would be great to do something to improve here. Is there
are good way for us to do this today? Is staying on top of what's
coming a logical fit for our PMs? Maybe some other approach? Not sure
about the best way to start something like this.

- Ryan

[Nick Fitzgerald]

I don't think that is too ambitious, but I think we should move this
conversation to dev-platform so we aren't preaching to the choir here.

[Panos Astithas]

I think the main problem here is resources and prioritization. For example,
we've known for quite a while that ServiceWorkers are coming, and they are
a giant milestone for the web, but we haven't treated it as top-priority.
We don't even support debugging regular workers yet, and we don't have
read/write support in our storage inspector either.

I think this stems from the fact that while we have mostly closed the
feature gap with the competition (or we will once worker debugging and the
perf tools are done), there are still many papercuts that we need to fix
and at the same time e10s has demanded significant attention.

There have been some cases where we were quick to support new platform
features (promises and animations come to mind), but I don't see us being
able to meaningfully promise tool support any time soon, unless it comes at
the cost of papercut fixing.

On the other hand it would be useful to have a tracking bug for that kind
of thing, so that we could consult it while thinking about quarterly goals
:)


On Tue, Mar 31, 2015 at 12:19 AM, Nick Fitzgerald <nfitz...@mozilla.com>
wrote:

[Patrick Brosset]

Being quick at supporting new platform features in the devtools comes at a
risk too: stability.

I've indeed been involved with platform people working on the WebAnimations
API very early in the process, and that's great for all the reasons Ryan
said, but I've had a couple of cases where a little bit of time buffer
would have helped:
- there are still crashes that prevent me from using some features,
- some terminology in the spec can still change (and has), and that may
cause protocol actor or method names to change, which means non-backward
compatibility changes for us.

My 2 cents.
Patrick

--
Patrick Brosset

[Nick Fitzgerald]

I hear you, and I agree that we have to balance polish with shiny new
features (and that our balance has perhaps been less than optimal
historically).

I won't speak for others, but I'm not trying to say "we need devtools to be
a part of every new platform feature and ship them ASAP along with the new
platform feature."

What I'm saying is that when going through the intent-to-implement process,
we should be a part of the conversation and not an after thought
​. ​
We can't do everything ourselves; we need to get platform feature
implementors thinking about what devtools APIs would make sense, and how it
would be best implemented too. Implementation of the
​platform ​
feature should be
​architected for adding instrumentation/debugging down the line. There
should be tracking bugs filed so it doesn't slip through the cracks.

It's good to be realistic about workloads and trade offs, but we should
remain optimistic as well. I am hopeful that participating in
intent-to-implement conversations now will make our lives much easier later
when we determine it is time to add tooling for those new platform features.

On Tue, Mar 31, 2015 at 2:19 AM, Panos Astithas <pa...@mozilla.com> wrote:
>
> There have been some cases where we were quick to support new platform
features (promises and animations come to mind), but I don't see us being
able to meaningfully promise tool support any time soon, unless it comes at
the cost of papercut fixing.

FWIW, one of our returning prodigal intern
​'s (Gabriel Luong) potential projects will be a promise tool. In this
specific case, we have all the platform work done, and it is a matter of
making actors and UI now. Usually it's the other way around.

[Dave Camp]

I wanted to weigh in but Nick said everything I thought should be said.

-dave

On Tue, Mar 31, 2015 at 8:47 AM, Nick Fitzgerald <nfitz...@mozilla.com>
wrote:

[J. Ryan Stinnett]

I sent a new thread to dev-platform on this topic (CCed here), follow
along if you are interested.

- Ryan