On Thu, Apr 4, 2013 at 9:27 PM, Karl Tomlinson wrote:
> Nicholas Nethercote writes:
>
>> Warnings about possibly dubious but common practices aren't much use.
>> I gave up on turning on -Wshadow for this reason,
>
> If you could now use |index| as a variable name, would it be worth
> revisiting -W
Nicholas Nethercote writes:
> Warnings about possibly dubious but common practices aren't much use.
> I gave up on turning on -Wshadow for this reason,
If you could now use |index| as a variable name, would it be worth
revisiting -Wshadow?
http://gcc.gnu.org/gcc-4.8/changes.html
On Thu, Apr 4, 2013 at 4:50 PM, Jeff Walden wrote:
> On 04/04/2013 01:55 PM, Daniel Holbert wrote:
>> MSVC C4244 is by far our spammiest MSVC warning -- it's already disabled
>> in /js/src due to its low value::trouble ratio.
>
> Actually I think this is a mistake, one that we should fix at some p
On 04/04/2013 01:55 PM, Daniel Holbert wrote:
> MSVC C4244 is by far our spammiest MSVC warning -- it's already disabled
> in /js/src due to its low value::trouble ratio.
Actually I think this is a mistake, one that we should fix at some point. I
have very little confidence that all of SpiderMon
Mike Hommey schrieb:
4.8 is IMHO too young to even consider testing.
Though its feature set seems to be quite helpful for us:
http://lwn.net/Articles/543570/
Makes me think that we should at least experiment with it to make sure
are issues we have with it will be fixed in a .1 or so and we'
On 4/4/13 7:12 AM, Kartikaya Gupta wrote:
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,
W3C is proposing a revised charter for the Web and TV Interest
For more details, see:
http://lists.w3.org/Archives/Public/public-new-work/2013Mar/0008.html
http://www.w3.org/2012/11/webTVIGcharter.html
Mozilla has the opportunity to send comments or objections through
Friday, April 26. Please rep
W3C is proposing revised charters for a collection of working groups
in the XML area:
http://lists.w3.org/Archives/Public/public-new-work/2013Mar/0007.html
http://www.w3.org/XML/2013/exi-charter.html
http://www.w3.org/XML/2013/query-charter.html
http://www.w3.org/XML/2013/xml-core-charter.html
h
W3C is proposing a revised charter for the Web Performance Working
Group. For more details, see:
http://www.w3.org/2013/01/webperf.html
http://lists.w3.org/Archives/Public/public-new-work/2013Mar/.html
Mozilla has the opportunity to send comments or objections through
Thursday, April 11. Ple
MSVC C4244 is by far our spammiest MSVC warning -- it's already disabled
in /js/src due to its low value::trouble ratio. Once the tree reopens,
I'll be disabling it in the toplevel configure.in -- more info on that here:
https://bugzilla.mozilla.org/show_bug.cgi?id=857863
(There doesn't seem to
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, d
In addition to this change from CVS to Mercurial, the following changes will be
made in mozilla-central the next time we update NSS:
dbm/ will be moved security/nss/lib/dbm/
security/coreconf/ will be moved to security/nss/coreconf/
This should reduce some confusion about what parts of the tree
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
(Moving thread from from m.d.tree-managment to m.d.platform)
On 13-04-03 19:03 , Jeff Hammel wrote:
Without wanting to start a contraversy, is there a particular reason to
use multiple trees here vs e.g. a checkin-needed flag on bugzilla or
similar?
I'm not quite sure what you're suggesting. A
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 pre
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
dev-platfo
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 want
On 03/04/13 15:32, Ed Morley wrote:
> Agreed - TBPL's successor is going to be called something other than
> TBPL2 (name chosen so far is treeherder).
Surely then it should be called "Ent"? :-)
Gerv
___
dev-platform mailing list
dev-platform@lists.mozi
On (2013年04月04日 00:45), ISHIKAWA, Chiaki wrote:
> Right now, I am running the compiled and linked DEBUG BUILD of TB
> (comm-central) by invoking
> "make mozmill" to test if anything unwanted my have crept in using "gold".
After checking the session log, I don't think gcc-4.7 + gold produced any
u
On 4/3/13 10:45 PM, Kartikaya Gupta wrote:
> On 13-04-03 19:49 , Jesse Ruderman wrote:
> > 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
20 matches
Mail list logo
