Re: License of test data?

[glob]

mhoye wrote:

Does "just do it" imply that it's now OK to import that stuff without

an analog of the previous r+ from Gerv?
I'm putting together a licensing runbook with Legal's help, and the 
aim of that will be getting us to that point. As well, Glob is 
building some logic into Phabricator to automate a bunch of this stuff 
on ingest as well.
to clarify the bits i'm working on aren't integrated with phabricator; 
it's a framework for standardising and automating how we vendor in code, 
and part of that is ensuring a license is specified and is one that we 
permit.  it will exist as a new mach command.


integration with build, review, and/or ci systems to automate license 
validation will be possible once this lands, but isn't part of the 
initial scope.



-glob

--
glob — engineering workflow — moz://a

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing tinderbox-builds from archive.mozilla.org

[Karl Tomlinson]

On Fri, 18 May 2018 13:13:04 -0400, Chris AtLee wrote:

> IMO, it's not reasonable to keep CI builds around forever, so the question
> is then how long to keep them? 1 year doesn't quite cover a full ESR cycle,
> would 18 months be sufficient for most cases?
>
> Alternatively, we could investigate having different expiration policies
> for different type of artifacts. My assumption is that the Firefox binaries
> for the opt builds are the most useful over the long term, and that other
> build configurations and artifacts are less useful. How accurate is that
> assumption?

Having a subset of builds around for longer would be more useful
to me than having all builds available for a shorter period.

The nightly builds often include large numbers of changesets,
sometimes collected over several days, and so it becomes hard to
identify which code change modified a particular behavior.

I always use opt builds for regression testing, and so your
assumption is consistent with my experience.

I assume there are more pgo builds than nightly builds, but fewer
than all opt builds.  If so, then having a long expiration policy
on pgo builds could be a helpful way to reduce storage costs but
maintain the most valuable builds.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform