On 4/11/14, 6:50 PM, Chris Peterson wrote:
On 4/11/14, 4:53 AM, Till Schneidereit wrote:
>
>I see two issues:
> -Javascript:JIT component seems to be missing.
>
Also the other sub-components.
No, they are included. I just verified this. The bug queries search any
component with the substrin
On 4/11/14, 4:53 AM, Till Schneidereit wrote:
>
>I see two issues:
> -Javascript:JIT component seems to be missing.
>
Also the other sub-components.
No, they are included. I just verified this. The bug queries search any
component with the substring "JavaScript" (in the "Core" product to
a
On 4/11/14, 2:37 AM, Nicolas B. Pierron wrote:
Thanks for doing this priority list, at least this make things clear. :)
I would suggest to amend it as follow:
6a. *reproducible* topcrash bugs
6b. fuzzblockers
[…]
9f. *non-reproducible* topcrash bugs
- top-crash are not always
On 4/11/14, 2:37 AM, Nicolas B. Pierron wrote:
Thanks for doing this priority list, at least this make things clear. :)
I would suggest to amend it as follow:
6a. *reproducible* topcrash bugs
6b. fuzzblockers
[…]
9f. *non-reproducible* topcrash bugs
- top-crash are not always
What Bobby says here is right. While sec-high are usually less bad than
sec-crit, we would still probably chemspill for a sec-high in the wild.
Another thing that is missing is triaging security bugs. If something should
be a sec-crit but it hasn't been marked as such, that's probably worse th
On Fri, Apr 11, 2014 at 12:52 AM, Chris Peterson wrote:
> 1. Chemspill bugs
> 2. sec-crit bugs
> 11b. sec-high bugs
>
This doesn't make sense. The distinction between sec-high and sec-crit is
just a technicality on the modern world, and we chemspill for both with
equivalent urgency. I've ar
Hello,
"25 minutes of Cake and JavaScript" today at 10AM MV Time.
Totally optional. On vidyo, my room. BYO cake.
No agenda. BYO something cool to talk about.
Here's a link.
https://v.mozilla.com/flex.html?roomdirect.html&key=5HY8vvNxNyNd
If you DON'T have an account on v.mozilla.com, you can e
I think we also miss "Performance regressions".
Those also should get high priority. We should at least make sure they
don't stick too long in the tree.
The reason for this is that it could obscure other regressions or in the
worst case scenario be present on merge date.
Making it hard to track and
On Fri, Apr 11, 2014 at 11:37 AM, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:
> On 04/11/2014 12:52 AM, Chris Peterson wrote:
>
>> Following up on our brainstorming sessions at the JS work week, I'd like
>> to
>> get your feedback on SpiderMonkey's priorities and document them in an
On 04/11/2014 12:52 AM, Chris Peterson wrote:
Following up on our brainstorming sessions at the JS work week, I'd like to
get your feedback on SpiderMonkey's priorities and document them in an
ordered list that we can use as our "moral compass". :)
Below I also propose a lightweight planning pro
Following up on our brainstorming sessions at the JS work week, I'd like
to get your feedback on SpiderMonkey's priorities and document them in
an ordered list that we can use as our "moral compass". :)
Below I also propose a lightweight planning process to keep our focus
trained on those proj
11 matches
Mail list logo
