On 10/23/2015 3:43 AM, Gregory Szorc wrote:
IMO this is one of the two serious concerns. However, I /think/ it will
only add an incremental burden. If nothing else, perhaps this will force us
to better invest in tools that automatically handle refactorings.
The other serious concern is impact to automation. Are we going to close
trees for Thunderbird failures? Are we going to run Thunderbird jobs on
every push? (Do we do this now?)
The automation aspects are open to some debate as to the most reasonable
way to implement them (caveated on what our infrastructure can support).
Our buildbot infrastructure currently supports triggering builds if only
certain files are changed--so changing SeaMonkey-only code, for example,
doesn't trigger a Thunderbird build and vice versa.
I think it's reasonable to expect that Thunderbird failures do not close
trees (and I've heard that one of the design goals of Treeherder is/was
to make project-specific "tier 1" views that would make this easier). I
also think it's reasonable to not build Thunderbird on every m-i checkin
or every try push. The main model I've envisioned is to build on every
m-{c,a,b,esr} checkin and only build on m-i if a comm-central file is
changed (correspondingly not building FF if only TB-specific code is
touched), with try handled via an extra -a "app" option, although other
models (e.g., retaining c-c as a project branch like build-system or
fx-team) are plausible. I'd like to invite release engineers and
sheriffs to suggest easier models if they can, since they have much more
experience here.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
