+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
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/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 o
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
On Monday, July 15, 2013 3:09:05 PM UTC-7, Kyle Huey wrote:
> FWIW now that we have AWSY and we don't really care about
> shutdown leaks
>
> specifically I don't think these tests are very useful to
> memshrink anymore.
AWSY is not a replacement for shutdown-leak testing. It's limited to code
If MOZ_IGNORE_WARNINGS=1 becomes common, I worry that warning spew will
pile up even more than it does now, making it impossible to use warnings
as part of the development process.
Incorrect warnings should be removed. Especially noisy warnings, such as
those that happen during startup and sho
Features I'd like:
* Show declarations and definitions (including webidl!) above refs
* context:3
* context:statement
* Search only within string literals / "search by color"
* A way to load ALL results (other than holding Cmd+Down)
* Offer `hg grep --all --follow word file` when I click a word
The three bug reports:
https://bugzilla.mozilla.org/show_bug.cgi?id=823336
https://bugzilla.mozilla.org/show_bug.cgi?id=823338
https://bugzilla.mozilla.org/show_bug.cgi?id=826201
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists
If we had blame enabled on http://git.mozilla.org/ would you be able to
get what you need easily?
Currently, if I replace 'history' with 'blame' in a gitweb url, I get
"403 - Blame view not allowed" :(
http://git.mozilla.org/?p=integration/gecko-dev.git;a=history;f=README.txt;h=da882f56b14bd8
In the long run, it may be more efficient to use the clang "sanitizer"
suite instead of Valgrind. It will need two runs (ASan+LSan+UBSan and
MSan) but the total run time should be lower.
http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation
> Valgrind can find the following kind
Nick, this is great. Even just having the "PGO" tests passing under
Valgrind means we can use V to diagnose intermittent failures in any
suite. And maybe even to fuzz, although I'd like to see reftest and
crashtest passing first.
> 8) Must avoid patterns known to cause non deterministic failures
We have a lot of pointer casts in our tree [1][2][3] and some security
holes involve these casts going wrong [4][5].
Should we make debug builds check casts to (vtableful?) pointer types?
This could be done by adding and calling an "assert_cast" function, or
by adding a new "sanitizer" mode [6] to
12 matches
Mail list logo
