Confirmed users
353
edits
EngineeringProductivity/Projects/Treeherder/Meetings/2013-01-23: Difference between revisions
EngineeringProductivity/Projects/Treeherder/Meetings/2013-01-23 (view source)
Revision as of 00:47, 30 January 2013
, 30 January 2013→Design Notes
| Line 27: | Line 27: | ||
== Scheduled Job Objects (valgrind, releases etc...) == | == Scheduled Job Objects (valgrind, releases etc...) == | ||
* There needs to be some way to see and understand what the status is of these auxiliary build/test jobs that run more periodically - valgrind, QA update tests etc. | * There needs to be some way to see and understand what the status is of these auxiliary build/test jobs that run more periodically - valgrind, QA update tests etc. | ||
== Putting it All Together == | |||
* The structure of how tests and builds are related and even "jobs" depend on other jobs are different and the way that we handle these things is complex - for releases for instance we "fan in" w.r.t. various jobs that must complete before we do the next job. For m-c we "fan out" where a build finishes and then the tests are run for that build, etc. | |||
* Building a deep correlation with builds and tests into tbpl v2 might bite us or constrain us. So we need to think about supporting the release automation and l10n builds | |||
** Note: not sure if this would bite us if build objects and test objects are stored in separate object stores with no constraints on when test data gets populated. | |||
* We need to fit in l10n somewhere | |||
** For l10N we key off an english build and then do a localized build | |||
** we also generate a one-off repack for l10ners from older nightly english builds | |||
== UI Design == | == UI Design == | ||