On 2013-04-03 7:11 PM, Gregory Szorc wrote:
On 4/3/13 3:36 PM, L. David Baron wrote:
On Wednesday 2013-04-03 17:31 -0400, Kartikaya Gupta wrote:
1. Take the latest green m-c change, commit your patch(es) on top of
it, and push it to try.
2. If your try push is green, flag it for eventual merge to m-c and
you're done.
3. If your try push is not green, update your patch(es) and go back
to step 1.
This seems like it would lead to a substantial increase in
build/test load -- one that I suspect we don't currently have the
hardware to support. This is because it would require a full
build/test run for every push, which we avoid today because many
builds and tests get merged on inbound when things are behind. (I
also don't feel like we need a full build/test run for every push,
so it feels like unnecessary use of resources to me.)
Let me ask a related question: why does my push to change a .js file in
/services incur 40+ hours of machine time to run the full reftest suite
- something which it is practically guaranteed to not interfere with?
Because we don't have a dependency graph between source code files and
unit tests that will be testing something different if you change
something in that source file.
Note that it's very easy to come up with simple examples of unneeded
test runs such as the one you gave above, but this is a very hard
problem to solve. For this specific one, please file a RelEng bug.
We've already limited the full set of builds/tests for things that only
touch browser/, b2g/, mobile/, etc. But fixing this would be a tiny
improvement over the situation today.
IMO we should have a mechanism in place that audits changesets for
likely impact, chooses a reasonable set of builds/tests to perform, and
runs with it. We can supplement this with "no changeset lands in m-c
until all builds/tests have ran on it" (i.e. a later push on that tree
or a manual or timer triggered full gamut run). This general idea is
being considered in bug 849385.
Do you have a concrete proposal on what that mechanism would look like?
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
