Bug 1286075: major changes to in-tree task graph generation for non-test tasks
If you have worked on adding or modifying the gecko tasks that run in
taskcluster, heads up!
I've just pushed a patchset to bug 1286075 which will dramatically
change how tasks are configured. Change for the better, of course!
Please see the bug for the details, but the general idea is that tasks
are now defined in a more semantic form ("to perform the frob task,
invoke mozharness with these frob-related options, while indexing the
task and displaying it in treeherder as fr(OB)") and that is then
interpreted using some simple, easiliy-modified logic to produce the
~870 tasks that run for each push.
In the process, the "legacy" kind, taskcluster/ci/legacy, has been deleted.
I have bitrotted a few patches I know of, and probably more I don't
know of. For that, I am deeply sorry, but also hopeful that you will
like the new way better. I've taken pains not to change the test
kinds much, so test-only changes should not be bitrotten.
Please head on over to the bug to have a look, and either comment
there or get in touch with me with any questions or concerns.
I plan to land this as soon as there are adequate r+'s -- like any
in-tree change, it can be backed out if it causes severe issues. If
you'd like to know when it lands, please cc yourself to the bug.
Thanks,
Dustin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: CSS Working Group
On Monday 2016-08-29 17:21 -0700, L. David Baron wrote: > The W3C is proposing a revised charter for: > > Cascading Style Sheets (CSS) Working Group > https://www.w3.org/Style/2016/css-2016.html > https://lists.w3.org/Archives/Public/public-new-work/2016Aug/.html > > Mozilla has the opportunity to send comments or objections through > this Friday, September 2. > > Please reply to this thread if you think there's something we should > say as part of this charter review, or if you think we should > support or oppose it. Nobody else replied, so I wrote the following (the deadline was extended to today): While the CSS WG continues to produce a number of important specifications, it has remained weak at getting good input from all of the relevant constituencies. This isn't necessarily something that the charter can fix, but I think it is worth pointing out. Some impromevents that would help with this are fixing some of the problems that scare participants away; for example, spending large meetings on very technical details that many people aren't interested in, thus scaring off people who have important things to say about bigger-picture issues but aren't interested in the most detailed discussions. (This may even be helped by improvements already present in this charter.) Some of the more speculative Houdini specs are not listed as deliverables in the charter, but it seems they should be. (CSS Layout API, Box Tree API, and maybe also CSS Parser API and Font Metrics API) I also *think* the group has agreed to rename the Motion Path spec (listed in the charter as motion-1) as part of merging its uses with some requirements for CSS Round Display; the charter should be updated to reflect the new name (which I don't currently recall). I'm also not entirely happy about the implication of the sentence "This avoids waiting for the next weekly call, if consensus can be determined before then." in the Decision Policy section; it seems to imply that the only value of asynchronous decision making is to make decisions faster. Asynchronous decision making can also help to include those who would be left out by a synchronous decision making process. I think it would be an improvement to just drop the sentence. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: canvas getTransform() and setTransform(DOMMatrixInit) methods.
The canvas draft spec used to have a currentTransform attribute on 2D canvas context objects, which was implemented by Chrome (behind a runtime flag). We also ship our own similar (but non-standard) mozGetTransform and mozSetTransform methods. The draft spec has since changed to add a getTransform method returning a DOMMatrix, and a setTransform method that accepts a new DOMMatrixInit dictionary. It seems that the Chrome team intends to support these new methods instead of currentTransform, so I would like to implement them as well, and help push the spec forward. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=928150 Proposed preference behind which to implement: canvas.transform_extensions.enabled Draft spec: https://html.spec.whatwg.org/multipage/scripting.html#current-transformation-matrix Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=637940 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case
I wrote a test using fetch() that seems to suggest we don't re-use in-progress requests at the http cache level. (Note, this downloads about 200MB... don't click on your mobile.) https://people.mozilla.org/~bkelly/fetch/http-cache/ On Wed, Sep 7, 2016 at 1:45 PM, Andrew Sutherland < asutherl...@asutherland.org> wrote: > There's a proposal at https://github.com/jakearchibald/background-cache > for enabling persistently-tracked uploads/downloads in the background. It > might change names to background-fetch. > > I'm interested in getting some informed feedback about the following > use-case on https://github.com/jakearchibald/background-cache/issues/3 > > A motivating use-case is for a site that wants to download movies/podcasts > in the background and keep them around for offline purposes. Once the file > is downloaded, it seems clear that the (ServiceWorker [DOM]) Cache API[1] > is a great place to store the result. What's less clear is how best to > handle allowing the user to begin watching the movie when the download is > still in-progress. A potential straw-man is: > > * Start the download with background-fetch > * Use the background-fetch API to track the status of the download. When > there's "enough" downloaded, start playing the video via its online URL > with the confidence that the netwerk cache2 can unify the two requests as > much as possible. > * When the download completes, stick the movie in the DOM Cache API and > use Cache-furnished Responses for all future playback requests. > > The greatest concern right now is around range requests and redundantly > downloaded data. We've seen interest in the Service Worker repo issues for > the ability to track/match in-flight fetch requests[2] that I hope should > be entirely mooted by the HTTP cache. Depending on the HTTP cache until > the download is complete ideally avoids redundant downloads, but it would > be great to have reassurance and an understanding of how a background-fetch > download mechanism might interact with the HTTP cache. Could the download > entirely use the HTTP cache for storage with the cache entries pinned to > avoid eviction until the download notification extendable event completes? > > Andrew > > 1: https://w3c.github.io/ServiceWorker/spec/service_worker/ > index.html#cache-objects > 2: https://github.com/w3c/ServiceWorker/issues/959 > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case
There's a proposal at https://github.com/jakearchibald/background-cache for enabling persistently-tracked uploads/downloads in the background. It might change names to background-fetch. I'm interested in getting some informed feedback about the following use-case on https://github.com/jakearchibald/background-cache/issues/3 A motivating use-case is for a site that wants to download movies/podcasts in the background and keep them around for offline purposes. Once the file is downloaded, it seems clear that the (ServiceWorker [DOM]) Cache API[1] is a great place to store the result. What's less clear is how best to handle allowing the user to begin watching the movie when the download is still in-progress. A potential straw-man is: * Start the download with background-fetch * Use the background-fetch API to track the status of the download. When there's "enough" downloaded, start playing the video via its online URL with the confidence that the netwerk cache2 can unify the two requests as much as possible. * When the download completes, stick the movie in the DOM Cache API and use Cache-furnished Responses for all future playback requests. The greatest concern right now is around range requests and redundantly downloaded data. We've seen interest in the Service Worker repo issues for the ability to track/match in-flight fetch requests[2] that I hope should be entirely mooted by the HTTP cache. Depending on the HTTP cache until the download is complete ideally avoids redundant downloads, but it would be great to have reassurance and an understanding of how a background-fetch download mechanism might interact with the HTTP cache. Could the download entirely use the HTTP cache for storage with the cache entries pinned to avoid eviction until the download notification extendable event completes? Andrew 1: https://w3c.github.io/ServiceWorker/spec/service_worker/index.html#cache-objects 2: https://github.com/w3c/ServiceWorker/issues/959 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
