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 Wed, May 9, 2018 at 2:10 PM William Lachance <wlacha...@mozilla.com> wrote: > 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 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. > > jrmuizel pointed this bug to me, I assume this kind of scenario is not > that uncommon, where a manual/source bisection (which would presumably > take a bunch of scarce developer time) is required due to the > integration builds being expired: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1444055 > > Based on the feedback I'm seeing here, I think it might be worth > extending the expiry dates a little further back for some common build > configurations used by mozregression. Obviously no one cares about a > linux32 asan build from 2013, but I feel like there might be a better > sweet spot than where we're at. > > Will > _______________________________________________ > 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
