This is great news! Are the natvis files embedded in the PDBs, or do we
have to reference them separately?
On 5/9/2018 1:17 PM, Ted Mielczarek wrote:
Hello,
I recently landed a patch[1] that added a Gecko.natvis file[2] to the tree.
natvis files[3] are Microsoft's current way of providing
Hello,
I recently landed a patch[1] that added a Gecko.natvis file[2] to the tree.
natvis files[3] are Microsoft's current way of providing nicer views of data
types for their debuggers. The file as-landed was written by Vlad a few years
ago so it could definitely use some changes (there's a
On 2018-05-09 2:58 PM, Andrew Halberstadt wrote:
Going back to the original question, it looks like mozregression doesn't
use the builds that Nick wants to remove anyway. So regardless of our
retention policies, it looks like removing these builds would have no
impact on mozregression's
Going back to the original question, it looks like mozregression doesn't
use the builds that Nick wants to remove anyway. So regardless of our
retention policies, it looks like removing these builds would have no
impact on mozregression's effectiveness. Is that an accurate statement?
-Andrew
On
On 2018-05-09 2:01 PM, Ted Mielczarek wrote:
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
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
On 5/9/18 12:11 PM, L. David Baron wrote:
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.
I want to agree with David -- I recall one incident in particular where
On Wednesday 2018-05-09 12:39 -0400, William Lachance wrote:
> On 2018-05-09 11:48 AM, Botond Ballo wrote:
> > > Good question. I checked and it seems that the answer is no (yay).
> > >
> > > For nightly builds in mozregression, we fetch stuff out of:
> > >
> > >
On 2018-05-09 11:48 AM, Botond Ballo wrote:
Good question. I checked and it seems that the answer is no (yay).
For nightly builds in mozregression, we fetch stuff out of:
https://archive.mozilla.org/pub/firefox/nightly/
For inbound builds, we've been using taskcluster for a while.
What about
On Tuesday, May 8, 2018 at 1:38:26 PM UTC-4, Ted Mielczarek wrote:
> To debug the resulting build you will need to use a slightly different URL
> for the symbol server: https://symbols.mozilla.org/try . You can otherwise
> follow the symbol server instructions[2]. Try symbols are stored
On 2018-05-09 4:59 AM, Xidorn Quan wrote:
Would removing those files affect the ability of mozregression to locate pushes
of old regressions?
Good question. I checked and it seems that the answer is no (yay).
For nightly builds in mozregression, we fetch stuff out of:
Would removing those files affect the ability of mozregression to locate pushes
of old regressions?
- Xidorn
On Wed, May 9, 2018, at 4:49 PM, ntho...@mozilla.com wrote:
> We have approximately 400 TB of old files in the two directories
> firefox/tinderbox-builds and mobile/tinderbox-builds on
>
We have approximately 400 TB of old files in the two directories
firefox/tinderbox-builds and mobile/tinderbox-builds on
archive.mozilla.org [1,2]. I'm suggesting it's time to remove them.
The files come from pushes into the gecko repositories when the builds &
tests were run on Buildbot. The
13 matches
Mail list logo
