Re: Crash signature change: signatures now include abort messages

[Adrian Gaudebert]

Thanks Benjamin!

Here's a search that shows what those new signatures look like on stage:
https://crash-stats.allizom.org/search/?product=Firefox=%5EAbort&_facets=abort_message&_columns=date&_columns=signature&_columns=abort_message

Please let me know if that seems good or not before we push this change to
prod. :)

Cheers,
Adrian

On Thu, Apr 7, 2016 at 3:27 AM, Bobby Holley  wrote:

> On Wed, Apr 6, 2016 at 2:34 PM, Benjamin Smedberg 
> wrote:
>
>> No, it does not catch MOZ_RELEASE_ASSERT, because that doesn't call
>> NS_DebugBreak and that is what does the AbortMessage annotation[1].
>> NS_RUNTIMEABORT is the recommended way to reliably crash if you're in
>> XPCOM-y code.
>>
>
> That's unfortunate, because according to MXR (and anecdotally) almost
> everyone uses MOZ_CRASH.
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Eric Rescorla]

Sorry to be dense, but if I understand correctly, you'd like to:

1. Have a policy that all of Gecko needs to triage bugs in a certain way.
2. Redefine how everyone defines priorities?

And you think that 24 hours is enough time to get consensus on that.

Do I have that right?

-Ekr


On Wed, Apr 6, 2016 at 10:47 PM, Emma Humphries  wrote:

> Following up on yesterday's email: I put together a draft second proposal
> and shopped it around some, and now I want to bring that back into the main
> discussion.
>
> The bullet point version of this is:
>
> * Add a binary field that components can use, TRIAGED (Y/N, T/F, +,-)
> * In the case of Firefox related components, have a consistent definition
> of P1-P5 and make sure that triaged bugs have a Priority assigned
>
> This has a couple of implications:
>
> This means I have to have a plan in place for dealing with Priority going
> from ad-hoc to one set of meanings for bugs in Firefox components.
>
> If any of you have worked with longitudinal social sciences data sets,
> this is a common thing. Values for fields change over time, and researcher
> consult documentation so that code consuming the data would work with the
> discontinuities. Some of this can be handled through bugzilla UI, so that
> components using the TRIAGED flag would display the description
> corresponding to P1-P5 and other components would not.
>
> We also need to go through all the existing whiteboard, keywords, and
> custom flags we are using for e10s and other projects that are being used
> to indicate importance.
>
> I'd like to finish up feedback on by the end of the working day Thursday
> the 6th (PST.)
>
Then we'll get to work on a solid specification for the work so we can
> start implementation sometime in Q2.
>
> Thanks.
>
> -- Emma
>
> On Tue, Apr 5, 2016 at 5:27 PM, Emma Humphries  wrote:
>
>> It's been a week since I asked for your comments on the plan for triage,
>> thank you.
>>
>> I'm going reply to some general comments on the plan, and outline next
>> steps.
>>
>> Ekt and others said that up to now, individual teams have owned how they
>> triage and prioritized bugs. Mozilla has made commitments to how we are
>> going to follow up with people filing bugs. Thus we need consistent
>> decisions across all the components that go into Firefox about bugs that we
>> can share back to non-Mozillans on bugs they file, so that we can get them
>> to contribute more high-quality bugs, and participate in other efforts in
>> support of the project and the Open Web. I'm aware I'm asking teams with
>> existing process to make a change, but it's for a global gain.
>>
>> Several people pointed out all the fields in Bugzilla that have and could
>> be used to manage priorities, such as priority and rank. But we don't use
>> the priority field consistently across the project. I've asked for teams to
>> document how they use Priority,
>> https://wiki.mozilla.org/Bugmasters/Projects/Folk_Knowledge/Priority_Field,
>> and you'll see how that varies.
>>
>> When I checked how the Priority field was used in Firefox-related
>> components, that distribution was:
>>
>> --- 460,362
>> P1   14,304
>> P2   15,971
>> P3   37,933
>> P44,204
>> P52,913
>>
>> The bulk of bugs in Firefox-related components are P3, most likely
>> because we have a bug filing form that defaults to P3 and that needs to be
>> fixed if it's still in use.
>>
>> Having to make what seemed like snap-decisions on bugs was also a point
>> of concern, but that's something the proposal had a work around for, using
>> needinfo? to defer a triage decision on a bug until enough questions were
>> answered. And since we made a commitment to make decisions on bugs, we need
>> back pressure on untriaged bugs.
>>
>> But from what I read, y'all are amenable to standardizing the priority
>> flag's use in Triage. Doing that would create a discontinuity in historical
>> data, but that's not an insurmountable problem, and we can document that
>> breakage for researchers using historical data.
>>
>> So next step is a second proposal, simplified, using Priority to
>> represent triage decisions.
>>
>> In addition, I'll want to remove several fields which are not useful, or
>> superfluous from the bug entry wizards. Priority is a field that should be
>> set by people triaging bugs, not entering them. We have a keyword
>> vocabulary which is more expressive than severity. And our bug entry forms
>> don't show the version affected, or the STR (steps to reproduce) flags
>> which means it's an extra edit to get the information relman needs into a
>> bug.
>>
>> Thank you again for your time and consideration as we make Bugzilla and
>> Firefox better for everyone.
>>
>> -- Emma Humphries
>>
>>
>> On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries  wrote:
>>
>>> tl;dr
>>>
>>> In Quarter Two I'm implementing the work we’ve been doing to improve
>>> triage, make actionable decisions on new bugs, and 

Re: Triage Plan for Firefox Components

[Emma Humphries]

On Fri, Apr 1, 2016 at 9:45 AM, James Graham  wrote:

> But once we have picked something, can we at least try to remove any UI
> that is more-or-less vestigial given that decision and, at least briefly,
> fight entropy by making things simpler and more consistent, rather than the
> reverse.



​Yes. I do want to do this as I work on the implementation of the changes
for triage.

-- Emma​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Crash signature change: signatures now include abort messages

[Bobby Holley]

On Wed, Apr 6, 2016 at 2:34 PM, Benjamin Smedberg 
wrote:

> No, it does not catch MOZ_RELEASE_ASSERT, because that doesn't call
> NS_DebugBreak and that is what does the AbortMessage annotation[1].
> NS_RUNTIMEABORT is the recommended way to reliably crash if you're in
> XPCOM-y code.
>

That's unfortunate, because according to MXR (and anecdotally) almost
everyone uses MOZ_CRASH.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Crash signature change: signatures now include abort messages

[Benjamin Smedberg]

No, it does not catch MOZ_RELEASE_ASSERT, because that doesn't call
NS_DebugBreak and that is what does the AbortMessage annotation[1].
NS_RUNTIMEABORT is the recommended way to reliably crash if you're in
XPCOM-y code.

Bug 1104682 is filed for this, though. I'd love for somebody to take this.

--BDS

[1]
http://mxr.mozilla.org/mozilla-central/source/xpcom/base/nsDebugImpl.cpp#392

On Wed, Apr 6, 2016 at 5:29 PM, Kyle Huey  wrote:

> Does this catch MOZ_RELEASE_ASSERT and similar?  It would be nice to
> distinguish those somehow in crash-stats.
>
> - Kyle
>
> On Wed, Apr 6, 2016 at 2:18 PM, Benjamin Smedberg 
> wrote:
>
>> A change just landed which will change the way crash signatures are
>> computed for intentional aborts. Previously the crash signature would be
>> "NS_DebugAbort | ". Now the signature will be "Abort | > message up to 80 chars> | ".
>>
>> This should make it much easier to distinguish various classes of abort.
>>
>> Thanks to Adrian Gaudebert for taking this in bug 803779!
>>
>> --BDS
>>
>> --
>> Benjamin Smedberg
>> Engineering Manager, Firefox
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>


-- 
Benjamin Smedberg
Engineering Manager, Firefox
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Crash signature change: signatures now include abort messages

[Kyle Huey]

Does this catch MOZ_RELEASE_ASSERT and similar?  It would be nice to
distinguish those somehow in crash-stats.

- Kyle

On Wed, Apr 6, 2016 at 2:18 PM, Benjamin Smedberg 
wrote:

> A change just landed which will change the way crash signatures are
> computed for intentional aborts. Previously the crash signature would be
> "NS_DebugAbort | ". Now the signature will be "Abort |  message up to 80 chars> | ".
>
> This should make it much easier to distinguish various classes of abort.
>
> Thanks to Adrian Gaudebert for taking this in bug 803779!
>
> --BDS
>
> --
> Benjamin Smedberg
> Engineering Manager, Firefox
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Crash signature change: signatures now include abort messages

[Benjamin Smedberg]

A change just landed which will change the way crash signatures are
computed for intentional aborts. Previously the crash signature would be
"NS_DebugAbort | ". Now the signature will be "Abort |  | ".

This should make it much easier to distinguish various classes of abort.

Thanks to Adrian Gaudebert for taking this in bug 803779!

--BDS

-- 
Benjamin Smedberg
Engineering Manager, Firefox
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming SSH Host Key Rotation for hg.mozilla.org

[Philip Chee]

On 05/04/2016 09:09, Philip Chee wrote:
> On 04/04/2016 23:52, Gregory Szorc wrote:
>> We also changed the SSH server config to only support the "modern" set of
>> ciphers, MACs, algorithms, etc from
>> https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern. If you are
>> running an old SSH client, it may not be able to connect.
>> 
>> If you encounter problems connecting, complain in #vcs with a link to
>> pastebinned `ssh -v` output so we can see what your client supports so we
>> may consider adding legacy support on the server as a stop-gap. But
>> upgrading your SSH client to something that supports modern crypto is
>> highly preferred. More and more Mozilla systems will be adopting these
>> "modern" SSH server settings. So you'll have to upgrade sometime.
> 
> I'm using TortoiseHg whichh uses PuTTY and PLINK internally. I've
> deleted the mozilla host key and accepted the new one.
> 
> Now I can't push to comm-central via TortoiseHg. I can't push directly
> via hg.exe either. Putty error message is uninformative.

TortoiseHg 3.7.2 ships with a modified version of Plink from PuTTY 0.62.
I replaced this with the Plink.exe from PuTTY 0.67 and can now push to
hg.mozilla.org.

I have opened a bug in their issue tracker:
https://bitbucket.org/tortoisehg/thg/issues/4476/tortoiseplink-needs-to-be-updated-to-v067

Meanwhile is there a relevant wiki page on wiki.mo where I can add this
information?

Thanks.

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Eric Rescorla]

On Tue, Apr 5, 2016 at 9:27 PM, Emma Humphries  wrote:

> It's been a week since I asked for your comments on the plan for triage,
> thank you.
>
> I'm going reply to some general comments on the plan, and outline next
> steps.
>
> Ekt and others said that up to now, individual teams have owned how they
> triage and prioritized bugs. Mozilla has made commitments to how we are
> going to follow up with people filing bugs.
>

Where were those commitments made? Can you send a link?



The bulk of bugs in Firefox-related components are P3, most likely because
> we have a bug filing form that defaults to P3 and that needs to be fixed if
> it's still in use.
>
> Having to make what seemed like snap-decisions on bugs was also a point of
> concern, but that's something the proposal had a work around for, using
> needinfo? to defer a triage decision on a bug until enough questions were
> answered. And since we made a commitment to make decisions on bugs, we need
> back pressure on untriaged bugs.
>
> But from what I read, y'all are amenable to standardizing the priority
> flag's use in Triage
>

I don't think this is a question of which *flag* to use so much as whether
it's useful to produce a new flat taxonomy which is redundant with the
existing priority mechanisms that teams are using, which in many cases are
richer than a three-level (now, soon, no-plan) hierarchy as you propose.

I think the fundamental problem here is that you're trying to design
something that might be useful for defects but isn't useful for a large
fraction of bugs which are actually a method of documenting planned new
work. Bug Bugzilla needs to work for all of these.

-Ekr


In addition, I'll want to remove several fields which are not useful, or
> superfluous from the bug entry wizards. Priority is a field that should be
> set by people triaging bugs, not entering them. We have a keyword
> vocabulary which is more expressive than severity. And our bug entry forms
> don't show the version affected, or the STR (steps to reproduce) flags
> which means it's an extra edit to get the information relman needs into a
> bug.
>
> Thank you again for your time and consideration as we make Bugzilla and
> Firefox better for everyone.
>
> -- Emma Humphries
>
>
> On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries  wrote:
>
>> tl;dr
>>
>> In Quarter Two I'm implementing the work we’ve been doing to improve
>> triage, make actionable decisions on new bugs, and prevent us from shipping
>> regressions in Firefox.
>>
>> Today I’m asking for feedback on the plan which is posted at:
>>
>>
>> https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko
>>
>> Allowing bugs to sit around without a decision on what we will do about
>> them sends the wrong message to Mozillans about how we treat bugs, how we
>> value their involvement, and reduces quality.
>>
>> The Firefox quality team (myself, Mike Hoye, Ryan VanderMeulen, Mark
>> Cote, and Benjamin Smedberg) want to make better assertions about the
>> quality of our releases by giving you tools to make clear decisions about
>> which bugs must be fixed for each release (urgent) and actively tracking
>> those bugs.
>> What We Learned From The Pilot Program
>>
>> During the past 6 weeks, we have prototyped and tested a triage process
>> with the DOM, Hello, and Developer Tools teams.
>>
>> Andrew Overholt, who participated in the pilot for the DOM team, said, “A
>> consistent bug triage process can help us spread the load of watching
>> incoming bugs and help avoid issues falling through the cracks."
>>
>> During the pilot, the DOM team uncovered critical bugs quickly so that
>> people could be assigned to them.
>>
>> The pilot groups also found that the triage process needs to be fast and
>> have tooling to make going through bugs fast. It’s easy to fall behind on
>> triage for a component, but if you stay up to date it will take no more
>> than 15 minutes a day.
>>
>> You can find the bugs we triaged during the pilot by looking for
>> whiteboard tags containing ‘btpp-’.
>>
>> It is also important to have consistent, shared definitions for
>> regression across components so triagers do not waste effort on mis-labeled
>> bugs.
>> Comments?
>>
>> I am posting this plan now for comment over the next week. I intend to
>> finalize the triage plan for implementation by Tuesday, April 5th. Feedback
>> and questions are welcome on the document, privately via email or IRC
>> (where I’m emceeaich) or on the bugmast...@mozilla.org mailing list.
>> Timeline
>>
>> January: finish finding component responsible parties
>>
>> February: pilot review of NEW bugs with four groups of components, draft
>> new process
>>
>> Now: comment period for new process, finalize process
>>
>> Q2: implement new process across all components involved in shipping
>> Firefox
>> Q3: all newly triaged bugs following the new process
>>
>> -- Emma Humphries, Bugmaster
>>
>
>
> 

Re: Upcoming SSH Host Key Rotation for hg.mozilla.org

[Philip Chee]

On 05/04/2016 14:23, Onno Ekker wrote:
> Op 5-4-2016 om 3:09 schreef Philip Chee:

>> I'm using TortoiseHg whichh uses PuTTY and PLINK internally. I've
>> deleted the mozilla host key and accepted the new one.
>> 
>> Now I can't push to comm-central via TortoiseHg. I can't push directly
>> via hg.exe either. Putty error message is uninformative.
>> 
>> Phil

> I had my old SSH-key not only stored as hg.mozilla.org, but also as
> numeric ip-address, which prevented the new one from working correctly.
> Maybe something similar also happens for you?
> Check your ~/.ssh/known_hosts file.
> 
> Onno

Will do thanks!

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CSS Triggers

[Xidorn Quan]

On Wed, Feb 24, 2016 at 8:53 AM, Boris Zbarsky  wrote:

> On 2/23/16 4:18 PM, Jordan Santell wrote:
>
>> are there any other suggestions on how we
>> can observe this data and minimize incorrect results?
>>
>
> In an automated way, or manually?
>
> Because you can look at nsStyleStruct.cpp to figure out what we will do in
> response to various property changes.  Note that it can be a bit
> complicated, in the sense of depending on the old and new value, and
> possibly on the values of other properties.


I guess a script can be written to extract the simple cases, and then fill
the remaining manually?

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CSS Triggers

[Jean-Yves Perrier]

Hi!

Should these 3 bits of information (trigger reflow, paint or 
compositing) also be displayed on each MDN page related to a CSS property?


--
Jean-Yves Perrier
Senior St. Project Manager, Developer Documentation / MDN
On 23/02/2016 21:18, Jordan Santell wrote:

Awhile back, Google's Paul Lewis made a page listing all CSS triggers for
Chrome[0], mapping CSS property changes to whether or not they caused
paint, reflow and compositing. We initially had some data for this from the
devtools timeline/profiler on this, and they're going through an effort to
add other browsers' data to the page as well. Right now they're using some
of our outdated marker data, and I'd like to update this and make sure it's
accurate, both for web developers and gecko hackers.

I made an addon[1] that goes through their test suite and spins up our
timeline marker tracker and records what markers we observe when a CSS
property changes. An issue is, the markers seem non-deterministic at times,
like other things could schedule paints or layouts in the future that
results in cluttering up the results, getting series of paint markers when
idling. In lieu of having our markers have the original cause or source
(possibly a good chunk of work), are there any other suggestions on how we
can observe this data and minimize incorrect results?

[0] https://csstriggers.com/
[1] https://github.com/jsantell/gecko-css-triggers



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform