Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue
Following up on this, no breakage whatsoever was reported, so I removed the pref and the API from the tree in bug 1408301. Thanks, -- Emilio On 3/23/18 7:23 PM, Emilio Cobos Álvarez wrote: Hi, Bug 1408301 tracks unshipping CSSStyleDeclaration.getPropertyCSSValue. This is a non-standard API only implemented by Mozilla, and that generally can be replaced by usage of the standard .getPropertyValue. We added a use counter and deprecation warning in bug 474655. The data seems to indicate the usage is low, so I'm trying to remove this API on Nightly only to see if there's any breakage in bug 1448415, tentatively under the pref layout.css.getPropertyCSSValue.enabled. Let me know if there's any concern with doing this, and please file bugs blocking either bug 1448415 or bug 1408301 if you see something broken because of this. Thanks! -- Emilio ___ 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
Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue
Given that you are unshipping this... probably we should uplift a pref switch to beta to make it unship in 61 directly, and then remove in 62. I think that's probably safer than not unshipping it in 61 but removing directly in 62. - Xidorn On Sat, May 12, 2018, at 7:30 PM, Emilio Cobos Álvarez wrote: > Following up on this, no breakage whatsoever was reported, so I removed > the pref and the API from the tree in bug 1408301. > > Thanks, > > -- Emilio > > On 3/23/18 7:23 PM, Emilio Cobos Álvarez wrote: > > Hi, > > > > Bug 1408301 tracks unshipping CSSStyleDeclaration.getPropertyCSSValue. > > > > This is a non-standard API only implemented by Mozilla, and that > > generally can be replaced by usage of the standard .getPropertyValue. > > > > We added a use counter and deprecation warning in bug 474655. The data > > seems to indicate the usage is low, so I'm trying to remove this API on > > Nightly only to see if there's any breakage in bug 1448415, tentatively > > under the pref layout.css.getPropertyCSSValue.enabled. > > > > Let me know if there's any concern with doing this, and please file bugs > > blocking either bug 1448415 or bug 1408301 if you see something broken > > because of this. > > > > Thanks! > > > > -- Emilio > > ___ > > 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue
Hmm, so my reasoning is that this had already been unshipped during 61 Nightly so that gave us two nightlies + one beta cycle. But unshipping it in 61 entirely is probably better indeed. Filed bug 1461092. -- Emilio On 5/12/18 1:03 PM, Xidorn Quan wrote: Given that you are unshipping this... probably we should uplift a pref switch to beta to make it unship in 61 directly, and then remove in 62. I think that's probably safer than not unshipping it in 61 but removing directly in 62. - Xidorn On Sat, May 12, 2018, at 7:30 PM, Emilio Cobos Álvarez wrote: Following up on this, no breakage whatsoever was reported, so I removed the pref and the API from the tree in bug 1408301. Thanks, -- Emilio On 3/23/18 7:23 PM, Emilio Cobos Álvarez wrote: Hi, Bug 1408301 tracks unshipping CSSStyleDeclaration.getPropertyCSSValue. This is a non-standard API only implemented by Mozilla, and that generally can be replaced by usage of the standard .getPropertyValue. We added a use counter and deprecation warning in bug 474655. The data seems to indicate the usage is low, so I'm trying to remove this API on Nightly only to see if there's any breakage in bug 1448415, tentatively under the pref layout.css.getPropertyCSSValue.enabled. Let me know if there's any concern with doing this, and please file bugs blocking either bug 1448415 or bug 1408301 if you see something broken because of this. Thanks! -- Emilio ___ 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 ___ 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
Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue
It seems risky to remove the code (and then have the risk of doing things that depend on the code being gone) until we've actually shipped the pref-flip that turns the API off to release. (Or am I misunderstanding, and that's already happened?) Until we've safely shipped it to release, we can't really be sure we won't have to change our minds. -David On Saturday 2018-05-12 11:30 +0200, Emilio Cobos Álvarez wrote: > Following up on this, no breakage whatsoever was reported, so I removed the > pref and the API from the tree in bug 1408301. > > Thanks, > > -- Emilio > > On 3/23/18 7:23 PM, Emilio Cobos Álvarez wrote: > > Hi, > > > > Bug 1408301 tracks unshipping CSSStyleDeclaration.getPropertyCSSValue. > > > > This is a non-standard API only implemented by Mozilla, and that > > generally can be replaced by usage of the standard .getPropertyValue. > > > > We added a use counter and deprecation warning in bug 474655. The data > > seems to indicate the usage is low, so I'm trying to remove this API on > > Nightly only to see if there's any breakage in bug 1448415, tentatively > > under the pref layout.css.getPropertyCSSValue.enabled. > > > > Let me know if there's any concern with doing this, and please file bugs > > blocking either bug 1448415 or bug 1408301 if you see something broken > > because of this. > > > > Thanks! > > > > -- Emilio > > ___ > > 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 -- 𝄞 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
Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue
On 5/12/18 9:26 PM, L. David Baron wrote: It seems risky to remove the code (and then have the risk of doing things that depend on the code being gone) until we've actually shipped the pref-flip that turns the API off to release. (Or am I misunderstanding, and that's already happened?) Until we've safely shipped it to release, we can't really be sure we won't have to change our minds. So, the code for the API isn't gone yet. Indeed getPropertyValue is still backed by what used to be getPropertyCSSValue (see nsComputedDOMStyle::GetPropertyCSSValueWithoutWarning). I plan to change the getComputedStyle back-end in bug 1408300 to use the Rust code, and unexpose (and remove cycle-collection bits from) related interfaces in bug 1459871. With that, I planned to keep the related code around for a bit until it's unshipped from release, then remove all the CSSValue related code and similar bits. Does that seem like a reasonable path forward? Thanks! -- Emilio -David On Saturday 2018-05-12 11:30 +0200, Emilio Cobos Álvarez wrote: Following up on this, no breakage whatsoever was reported, so I removed the pref and the API from the tree in bug 1408301. Thanks, -- Emilio On 3/23/18 7:23 PM, Emilio Cobos Álvarez wrote: Hi, Bug 1408301 tracks unshipping CSSStyleDeclaration.getPropertyCSSValue. This is a non-standard API only implemented by Mozilla, and that generally can be replaced by usage of the standard .getPropertyValue. We added a use counter and deprecation warning in bug 474655. The data seems to indicate the usage is low, so I'm trying to remove this API on Nightly only to see if there's any breakage in bug 1448415, tentatively under the pref layout.css.getPropertyCSSValue.enabled. Let me know if there's any concern with doing this, and please file bugs blocking either bug 1448415 or bug 1408301 if you see something broken because of this. Thanks! -- Emilio ___ 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing tinderbox-builds from archive.mozilla.org
On Fri, May 11, 2018 at 4:06 PM, Gregory Szorc wrote: > On Wed, May 9, 2018 at 11:01 AM, Ted Mielczarek > wrote: > > > On Wed, May 9, 2018, at 1:11 PM, L. David Baron wrote: > > > > mozregression won't be able to bisect into inbound branches then, > but I > > > > believe we've always been expiring build artifacts created from > > integration > > > > branches after a few months in any case. > > > > > > > > My impression was that people use mozregression primarily for > tracking > > down > > > > relatively recent regressions. Please correct me if I'm wrong. > > > > > > It's useful for tracking down regressions no matter how old the > > > regression is; I pretty regularly see mozregression finding useful > > > data on bugs that regressed multiple years ago. > > > > To be clear here--we still have an archive of nightly builds dating back > > to 2004, so you should be able to bisect to a single day using that. We > > haven't ever had a great policy for retaining individual CI builds like > > these tinderbox-builds. They're definitely useful, and storage is not > that > > expensive, but given the number of build configurations we produce > nowadays > > and the volume of changes being pushed we can't archive everything > forever. > > > It's worth noting that once builds are deterministic, a build system is > effectively a highly advanced caching mechanism. It follows that cache > eviction is therefore a tolerable problem: if the entry isn't in the cache, > you just build again! Artifact retention and expiration boils down to a > trade-off between the cost of storage and the convenience of accessing > something immediately (as opposed to waiting several dozen minutes to > populate the cache). > > The good news is that Linux Firefox builds have been effectively > deterministic (modulo PGO and some minor build details like the build time) > for several months now (thanks, glandium!). And moving to Clang on all > platforms will make it easier to achieve deterministic builds on other > platforms. The bad news is we still have many areas of CI that are not > hermetic and attempts to retrigger Firefox build tasks in the future have a > very high possibility of failing for numerous reasons (e.g. some dependent > task of the build hits a 3rd party server that is no longer available or > has deleted a file). In other words, our CI results may not be reproducible > in the future. So if we delete an artifact, even though the build is > deterministic, we may not have all the inputs to reconstruct that result. > > Making CI hermetic and reproducible far in the future is a hard problem. > There are esoteric failure scenarios like "what if we need to fetch content > from a server in 2030 but TLS 1.2 has been disabled due to a critical > vulnerability and code in the hermetic build task doesn't support TLS 1.3." > In order to realistically achieve reproducible builds in the future, we > need to store *all* inputs somewhere reliable where they will always be > available. Version control is one possibility. A content-indexed service > like tooltool is another. (At Google, they check in the source code for > Clang, glibc, binutils, Linux, etc into version control so all they need is > a version revision and a bootstrap compiler (which I also suspect they > check into the monorepo) to rebuild the world from source.) > > What I'm trying to say is we're making strides towards making builds > deterministic and reproducible far in the future. So hopefully in a few > years we won't need to be concerned about deleting old data because our > answer will be "we can easily reproduce it at any time." > This might end up being true, but it seems a bit optimistic to me. I've worked with lots of systems much simpler than our builds that were in theory reproducible but then found when I went back to reproduce the results, things weren't so simple. You allude to one case above: it's one thing to have reproducible builds from days ago and quite another from years ago. Given the incredibly low cost of storage (the street price of Glacier is $.004/GB/month) [0] I'd be pretty hesitant to delete data which we thought we might want to use again just because we figured we'd reproduce it. -Ekr [0] https://aws.amazon.com/glacier/ > ___ > 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
