Thanks for the many comments! I replied to a bunch of stuff below.
On 13-04-03 18:34 , Justin Lebar wrote:
This is a really interesting idea.
git is smart enough to let you pull only the csets that end up getting
merged into master. I don't know how multiple heads works with hg,
but I wonder i
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 inf
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 hav
On 4/3/2013 6:33 PM, jmaher wrote:
I looked at the data used to calculate the offenders, and I found:
total type, total jobs, total duration, total hours
try builders, 3525, 12239477, 3399.8547
try testers, 71821, 121294315, 33692.8652778
inbound builders, 7862, 30877533, 8577.0925
inbound t
On 04/03/2013 06:33 PM, Ehsan Akhgari wrote:
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
On 4/3/13 6:03 PM, Ehsan Akhgari wrote:
A while ago I filed bug 813742 about parallelizing reftests and
crashtests. I believe that there should be no huge technical challenges
in doing this. It mostly needs somebody to commit to work on it.
Since that bug has received very little attention so
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}
> >
I looked at the data used to calculate the offenders, and I found:
total type, total jobs, total duration, total hours
try builders, 3525, 12239477, 3399.8547
try testers, 71821, 121294315, 33692.8652778
inbound builders, 7862, 30877533, 8577.0925
inbound testers, 121641, 182883638, 50801.0105
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 passe
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 try or something), and I recall (my memory
A while ago I filed bug 813742 about parallelizing reftests and
crashtests. I believe that there should be no huge technical challenges
in doing this. It mostly needs somebody to commit to work on it.
Since that bug has received very little attention so far, I thought I'd
mention it here and
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 6: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 pu
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 m
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
Yes
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
> >>
On 16:11, Wed, 03 Apr, 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 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
> But can we do this with rebased changesets instead of "trivial" merge
> changesets?
Personally, I think merges are a Very Good idea because they bake into
the tree information that is currently contained only in the pushlog.
This improves bisect from my perspective, although I'll grant it might
Stepping back: [
This issue is really a special case of "This patch compiles fine in my
local configuration, but it busts the build for $OTHER_PLATFORM".
The general solution to this class of problems is a try push, with
builds on at least one platform other than your local config (if not all
plat
+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.
___
de
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 merge to m-c and
you're done.
3. If your try push
>
> 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 inb
On 4/3/2013 4:31 PM, Kartikaya Gupta wrote:
The developer workflow I'm proposing requires there be a tree that is
allowed to have multiple heads. The "try" tree we have now satisfies
this requirement, so I'm using that in my proposal, but we could just
as easily use inbound or some other tree p
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 i
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 practic
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 it'
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)
This is a really interesting idea.
git is smart enough to let you pull only the csets that end up getting
merged into master. I don't know how multiple heads works with hg,
but I wonder if we could make hg smart enough to do the same thing.
Otherwise, maybe it's time to switch to git.
On Wed,
On 4/3/13 2:31 PM, Kartikaya Gupta wrote:
Excellent write-up! I think a re-examination of our tree management is
long overdue, especially with all the recent closures on inbound.
My suggested process *requires* a tree which allows multiple heads,
which is why I suggest "try" instead of "inbou
hi
i tried to create the patch for 846629 but ran into troubles.
(from JS the constants are all 0)
i have attached a (incomplete) patch at bugzilla.
https://bugzilla.mozilla.org/show_bug.cgi?id=846629
Maybe someone can point me to missing part between c++ <-> JS constant s
handling?
Am Freitag
(Cross-posted to mozilla.dev.tree-management; please reply to
mozilla.dev.platform)
TL;DR: I propose that instead of using inbound as a "linear commit;
rebase as needed" tree, we use a tree that allows multiple heads (e.g
try) to land patches on. Each patch queue would be based off a
known-gr
Yesterday a number of people discussed future plans for the WebAPI team.
Our discussion resulted in the ideas and comments that are on this
wiki page:
https://wiki.mozilla.org/WebAPI/PlannedWork
We'll add items to that page as time goes by and we'll pop items off it
as we work on them. As
I just tested this myself and found that it works. The problem is in
your command-line:
>>> 2. runtps --binary=/Users/raymond/Documents/mozilla-central/obj-ff-dbg/
--binary needs to be the full path of the binary, not the directory to it.
The error message could certainly be improved. :)
Le
(Ignoring whether or not WARNINGS_AS_ERRORS is a good idea, ignoring
whether or not having it disabled by default on developer builds but
enabled on automation is a good idea, ignoring whether or not we can deal
with the tendency of gcc to lurch from complaining incessantly about one
silly thing to
On 3/4/13 15:32, Ed Morley wrote:
> On 03 April 2013 15:21:33, Neil wrote:
>> Since tinderboxpushlog no longer uses tinderbox, maybe it should get
>> renamed ;-)
>
> Agreed - TBPL's successor is going to be called something other than
> TBPL2 (name chosen so far is treeherder).
I presume it'll be
You can't run TPS via tryserver; it isn't run in buildbot at all. It
can't, since it uses live Sync servers.
Raymond, the problem you're experiencing is likely due to changes in
mozprocess/mozrunner API's that TPS hasn't been updated to handle. Can
you file a bug about this, and assign it to
On 2013-04-03 10:32 AM, Ed Morley wrote:
On 03 April 2013 15:21:33, Neil wrote:
Since tinderboxpushlog no longer uses tinderbox, maybe it should get
renamed ;-)
Agreed - TBPL's successor is going to be called something other than
TBPL2 (name chosen so far is treeherder).
I disagree. TBPL2 s
On 30/03/2013 12:41, Martijn wrote:
> Dev.platforms.mobile seems removed, so I'm posting this here:
>
https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.platforms.mobile/PrEk4BsKkfA
>
> I tried building Fennec for a patch that I made, but the build that
> came out of it seemed to be
Thanks Justin! Can you suggest what try syntax I can use please? I don't see
a TPS option in the try syntax builder page.
http://trychooser.pub.build.mozilla.org/
Justin Lebar於 2013年4月3日星期三UTC+8下午11時47分58秒寫道：
> In general you'll have much more success running these benchmarks on
>
> tryserve
I don't know, actually. You can ask on #developers, but I'd just run
'em all. :)
On Wed, Apr 3, 2013 at 12:54 PM, Raymond Lee
wrote:
> Thanks Justin! Can you suggest what try syntax I can use please? I don't
> see a TPS option in the try syntax builder page.
> http://trychooser.pub.build.mozi
(2013/04/03 16:32), ishikawa wrote:
> On (2013年04月03日 15:32), Mike Hommey wrote:
>> On Wed, Apr 03, 2013 at 02:22:35PM +0900, ishikawa wrote:
>>> FYI: Upgrading binutils to 2.23.2 did not help.
>>> (Well, at least I got a better memory usage report when
>>> memory was exhausted. "ld" printed out th
In general you'll have much more success running these benchmarks on
tryserver rather than trying to run them locally. Even if you got the
test working, there's no guarantee that your local benchmark results
will have any bearing on the benchmark results on our servers. (In
particular, the server
On 03 April 2013 15:21:33, Neil wrote:
Since tinderboxpushlog no longer uses tinderbox, maybe it should get
renamed ;-)
Agreed - TBPL's successor is going to be called something other than
TBPL2 (name chosen so far is treeherder).
Best wishes,
Ed
John O'Duinn wrote:
NOTE: This announcement is *only* about decommissioning tinderbox.m.o. Obviously, the
"new" tbpl.m.o will continue in full production use, but I wanted to be
explicit to avoid any confusion/concerns.
Since tinderboxpushlog no longer uses tinderbox, maybe it should get
ren
On (2013年04月03日 15:32), Mike Hommey wrote:
> On Wed, Apr 03, 2013 at 02:22:35PM +0900, ishikawa wrote:
>> FYI: Upgrading binutils to 2.23.2 did not help.
>> (Well, at least I got a better memory usage report when
>> memory was exhausted. "ld" printed out that it fails to allocate this many
>> bytes
Hi all
I am trying to run TPS to ensure my patch works for bug 852041
(https://bugzilla.mozilla.org/show_bug.cgi?id=852041)
However, I got some errors when I ran the following. Could someone give me
some suggestions how to fix it please?
1. source /Users/raymond/Documents/virtualenv/bin/activ
47 matches
Mail list logo
