On 2/13/14, 5:33 PM, Bill McCloskey wrote:
We're hoping that exposing the "New OOP Window" menu item will make it easier
for people to test electrolysis.
When you file e10s bugs, please include "[e10s]" in the bug summary
and/or make your new bug block one of the e10s tracking bugs:
• Bug 8
Hi everyone,
I just wanted to make a quick announcement about preference changes for
out-of-process tabs. Bug 960783, which landed recently, added a "New OOP
Window" menu option to open a new window with out-of-process tabs. Right now
this option is only enabled on Macs because it requires OMTC
On Fri, Feb 14, 2014 at 4:01 AM, Kartikaya Gupta wrote:
> Hi all,
>
> Recently I've noted a significant increase in the number of bug comments
> that are meta-information and not particularly relevant to the bug itself.
> Often these comments are product/planning people moving the bug around
> ask
On 2/13/14, 1:23 PM, Honza Bambas wrote:
An optional /* @reviewer: m...@foo.com */ comment under the license would
do. If not present, find reviewer the usual way (not always hitting the
right person).
Reason is that despite we have peer lists, sometimes files are
written/maintained by non-peer
I like the idea but I’m not sure I agree that non-technical comments are spam,
I think we should reserve that for actual spam. While the information might not
be directly technical it can still be quite relevant and important and if it’s
default hidden that could be overlooked to the detriment o
On Thu 13 Feb 2014 01:42:23 PM PST, Till Schneidereit wrote:
> sfink's mqext Mercurial plugin[1] adds the command `hg reviewers`, that
> gives you a list of potential reviewers for the current mq tip. Is there
> anything you'd want to find out about reviewers that this doesn't provide?
Or you can
On Thu, Feb 13, 2014 at 1:39 PM, Botond Ballo wrote:
>>
>> landing - For comments that include commit URLs
>> summary - For comments that summarize a previously lengthy discussion
>> workaround - For comments that include a workaround for an unfixed bug
>> spam - For comments that don't provide te
On Fri, Feb 14, 2014 at 10:35 AM, Nick Alexander wrote:
> On 2/13/2014, 1:23 PM, Honza Bambas wrote:
>
>> An optional /* @reviewer: m...@foo.com */ comment under the license would
>> do. If not present, find reviewer the usual way (not always hitting the
>> right person).
>>
>
> -1 from me on any
> as a starting point here's some of the tags
> I've been using to flag things:
>
> landing - For comments that include commit URLs
> summary - For comments that summarize a previously lengthy discussion
> workaround - For comments that include a workaround for an unfixed bug
> spam - For comments
I think this is prone to error since it requires someone to take reviewer
status from someone else, or assume responsibility for a file that doesn't have
a reviewer yet. Generally, I just use |hg blame| and |hg blame -u| to see who
has been working on the file and how recently. If I ask the wron
On 2/13/2014, 1:23 PM, Honza Bambas wrote:
An optional /* @reviewer: m...@foo.com */ comment under the license would
do. If not present, find reviewer the usual way (not always hitting the
right person).
-1 from me on anything that even *looks* like a file owner in the file
itself. This is r
An optional /* @reviewer: m...@foo.com */ comment under the license would
do. If not present, find reviewer the usual way (not always hitting the
right person).
Reason is that despite we have peer lists, sometimes files are
written/maintained by non-peers of the module a file is in or should
Hi all,
Recently I've noted a significant increase in the number of bug comments
that are meta-information and not particularly relevant to the bug
itself. Often these comments are product/planning people moving the bug
around asking for attention on it (this particularly happens in B2G-land
On 02/13/2014 12:53 PM, Girish Sharma wrote:
Thank you everyone for your inputs. Since there is no current method of
precisely tracking window creation and removal, how should I proceed and
add such functionality ?
What I basically want is that despite of BFCache or anything, I should be
able to
Thank you everyone for your inputs. Since there is no current method of
precisely tracking window creation and removal, how should I proceed and
add such functionality ?
What I basically want is that despite of BFCache or anything, I should be
able to track when a new docshell (or the correspondin
15 matches
Mail list logo
