Sorry for starting a new thread, but I screwed up the previous thread by
mashing together my replies to unrelated messages in a single message.
If you didn't read all the messages in all sub-threads you may have
missed my response. Most of my responses were in this message:
My thoughts on why the average build time is shorter on try vs inbound is
inbound includes pgo builds and debug builds which have other steps. The try
server builds are not usually doing pgo.
___
dev-platform mailing list
Gregory Szorc wrote:
Here is the percent of total builder time we spent performing jobs
broken down by tree:
inbound 43.98%
try 27.48%
central 5.24%
...
We have an inbound and try problem.
After patches have passed try, do people then push them to inbound,
because they don't
the 325 jobs per push come from manually counting jobs on tbpl (ignoring pgo).
remember to use showall=1. The total stats from gps include try which has much
fewer test jobs per push and inbound coalescing.
___
dev-platform mailing list
On 13-04-03 23:05 , Jesse Ruderman wrote:
I suggest adding an Auto branch between Try and Central. Advantages:
[snip]
* In Scenario D (when subtle patch interactions cause build or test
failures), automation can move on to another set of Try landings, giving
sheriffs time react without the
On 13-04-03 19:49 , Jesse Ruderman wrote:
+1.
But can we do this with rebased changesets instead of trivial merge
changesets? While the core of hg can handle merges, pretty much none of
the tools we rely on for understanding history (hg {log, grep, diff,
bisect}) handle them well.
Thinking
On 4/4/13 8:07 AM, Kartikaya Gupta wrote:
On 13-04-03 19:49 , Jesse Ruderman wrote:
+1.
But can we do this with rebased changesets instead of trivial merge
changesets? While the core of hg can handle merges, pretty much none of
the tools we rely on for understanding history (hg {log, grep,
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
Another potential problem with this approach is that we will have more
merge changes in m-c, which generally screws with hg bisect. Personally
I already have enough trouble with hg bisect to the point where I don't
use it because I can't trust it. This may be a legitimate problem for
some, but
If anything this should improve the experience of bisecting, because
you'll be able to bisect known-good csets on m-c and only at the end
step in to the merge csets which may or may not be good.
Right now we say that when people push a patch queue to m-c every
patch should be green, but in
On 04/03/2013 04:44 PM, Joshua Cranmer wrote:
On 4/3/2013 5: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
On Wed, Apr 03, 2013 at 04:59:31PM -0700, Jeff Hammel wrote:
On 04/03/2013 04:44 PM, Joshua Cranmer wrote:
On 4/3/2013 5: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
On 4/3/13 4:11 PM, Gregory Szorc wrote:
I pulled the raw builder logs from
https://secure.pub.build.mozilla.org/builddata/buildjson/ and assembled
a tab-separated file of all the builds for 2013-03-17 through 2013-03-23:
https://people.mozilla.com/~gszorc/builds-20130317-20130323.txt.bz2
On 2013-04-03 7:44 PM, Joshua Cranmer wrote:
On 4/3/2013 5: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
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
On 2013-04-03 9:10 PM, Clint Talbert wrote:
On 4/3/2013 4:28 PM, Joshua Cranmer wrote:
On 4/3/2013 4:31 PM, Kartikaya Gupta wrote:
For what it's worth, I do recall there being release engineering talk
about some sort of autoland feature (which would automatically land
any patch that passed
On Wed, Apr 03, 2013 at 08:55:36PM -0400, Ehsan Akhgari wrote:
On 2013-04-03 7:44 PM, Joshua Cranmer wrote:
On 4/3/2013 5:36 PM, L. David Baron wrote:
On Wednesday 2013-04-03 17:31 -0400, Kartikaya Gupta wrote:
Instead of running {mochitest-*,reftest,crashtest,xpcshell,marionette}
on every
I suggest adding an Auto branch between Try and Central. Advantages:
* Pulling from Central is safe, because it only gets csets that passed
both Try (as individual developer pushes) and Auto (as a group).
* Infrastructure load will be slightly lower, because everyone's pushes
to Try will
On 2013-04-03 10:59 PM, Jeff Hammel wrote:
So I'm not sure I understand:
1. This will incur a significant increase in our infra resource usage
since all of these patches have to do a full try run. We simply cannot
afford that in today's world where we're struggling against wait times
and
19 matches
Mail list logo
