Re: PSA: Retiring Bugzilla Socorro Lens
This is now live. Much thanks to Dylan Hardison for getting it across the line. If you see any issues with it, or have feature requests, please report them to https://github.com/ashughes1/bmo-bsl Cheers! On 31 October 2017 at 13:07, Anthony Hughes <ahug...@mozilla.com> wrote: > Due to an unrelated infrastructure issue the push has been delayed. > Apologies for the delay. > > On 30 October 2017 at 13:27, Anthony Hughes <ahug...@mozilla.com> wrote: > >> This is a heads up that I am shutting down further development of my >> Bugzilla Socorro Lens add-on. If you're currently using the add-on I >> recommend that you uninstall it and please file issues at >> https://github.com/ashughes1/bmo-bsl. >> >> Over the past few weeks I've been working to integrate the functionality >> it provides natively with bugzilla.mozilla.org. These changes should be >> live as of Tuesday, October 31, 2017. You can read more about this at >> https://ashughes.com/?p=453. >> >> Thank you >> >> -- >> Anthony Hughes >> Senior Quality Engineer >> Mozilla Corporation >> > > > > -- > Anthony Hughes > Senior Quality Engineer > Mozilla Corporation > -- Anthony Hughes Senior Quality Engineer Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Retiring Bugzilla Socorro Lens
Due to an unrelated infrastructure issue the push has been delayed. Apologies for the delay. On 30 October 2017 at 13:27, Anthony Hughes <ahug...@mozilla.com> wrote: > This is a heads up that I am shutting down further development of my > Bugzilla Socorro Lens add-on. If you're currently using the add-on I > recommend that you uninstall it and please file issues at > https://github.com/ashughes1/bmo-bsl. > > Over the past few weeks I've been working to integrate the functionality > it provides natively with bugzilla.mozilla.org. These changes should be > live as of Tuesday, October 31, 2017. You can read more about this at > https://ashughes.com/?p=453. > > Thank you > > -- > Anthony Hughes > Senior Quality Engineer > Mozilla Corporation > -- Anthony Hughes Senior Quality Engineer Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Retiring Bugzilla Socorro Lens
This is a heads up that I am shutting down further development of my Bugzilla Socorro Lens add-on. If you're currently using the add-on I recommend that you uninstall it and please file issues at https://github.com/ashughes1/bmo-bsl. Over the past few weeks I've been working to integrate the functionality it provides natively with bugzilla.mozilla.org. These changes should be live as of Tuesday, October 31, 2017. You can read more about this at https://ashughes.com/?p=453. Thank you -- Anthony Hughes Senior Quality Engineer Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: FYI, BSL Broken by Bug 1317697
The issue is now resolved and a new version of the add-on has been submitted to AMO for review. Special thanks to Andy Mackay for the fix. Cheers! On 24 April 2017 at 10:32, Anthony Hughes <ahug...@mozilla.com> wrote: > This is a heads up that crash charts provided by Bugzilla Socorro Lens are > currently broken in Nightly due to the landing of bug 1317697. Any > suggestions for how I can fix this are welcome via > https://github.com/ashughes1/bugzilla-socorro-lens/issues/20. > > Thank you > > -- > Anthony Hughes > Senior Quality Engineer > Mozilla Corporation > -- Anthony Hughes Senior Quality Engineer Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
FYI, BSL Broken by Bug 1317697
This is a heads up that crash charts provided by Bugzilla Socorro Lens are currently broken in Nightly due to the landing of bug 1317697. Any suggestions for how I can fix this are welcome via https://github.com/ashughes1/bugzilla-socorro-lens/issues/20. Thank you -- Anthony Hughes Senior Quality Engineer Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GPU Process Experiment Results
Thanks for the feedback Chris. Graphs measuring crash rates is "crashes per 1000 hours" for Telemetry data via the crash_aggregates table (links to my re:dash queries are link at the bottom of the post) and "crashes per install_time cardinality" for Socorro data. I tried to focus on crash rate instead of crash count this time around. I'll endeavour to add more context in future graphs. Cheers! On 16 January 2017 at 13:22, Chris Hutten-Czapski <chut...@mozilla.com> wrote: > My one-sentence summary of the article - If anything, the test cohort with > the GPU process saw improved stability, especially for graphics crashes. > > Which is awesome! > > May need error bars for the figures to see how much of the results you saw > we might have to attribute to the noise of reported crash figures. > > Also, I can't quite tell what the units are. The initial graphs seem to be > #crashes-reported-to-Socorro, but later ones talk of > #crashes-per-1000-usage-hours. The axes aren't labelled, so it's difficult > to be precise. > > Have you attempted to measure crash counts and types via Telemetry instead > of Socorro? If all you need is a count and some metadata, the submission > rate to Telemetry is much (25x) higher than Socorro. (actually, if all you > need is a count, crash_aggregates would be a good place to start, as most > of the counting has been done for you). > > All in all, very interesting and I can't wait to see future experiments in > Aurora and on Beta, when the time is right. > > :chutten > > > On Mon, Jan 16, 2017 at 4:11 PM, Anthony Hughes <ahug...@mozilla.com> > wrote: > >> Hello Platform folks, >> >> Over the Christmas break I rolled out a Telemetry Experiment on Nightly to >> measure the stability impact of the GPU Process. This experiment concluded >> on January 11. Having had time to analyze the data I've published a report >> on my blog: >> https://ashughes.com/?p=374 >> >> It should come up on Planet shortly but I wanted to post here for >> increased >> visibility. Feel free to send me questions, comments, and feedback. >> >> Cheers >> >> -- >> Anthony Hughes >> Senior Quality Engineer >> Mozilla Corporation >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > > -- Anthony Hughes Senior Quality Engineer Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
GPU Process Experiment Results
Hello Platform folks, Over the Christmas break I rolled out a Telemetry Experiment on Nightly to measure the stability impact of the GPU Process. This experiment concluded on January 11. Having had time to analyze the data I've published a report on my blog: https://ashughes.com/?p=374 It should come up on Planet shortly but I wanted to post here for increased visibility. Feel free to send me questions, comments, and feedback. Cheers -- Anthony Hughes Senior Quality Engineer Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Visualizing Crash Data in Bugzilla
Hi Platform team, In case you don't follow planet.mozilla.org I wanted to highlight that I'm releasing the initial version of my experimental Bugzilla Tweaks add-on, dubbed Bugzilla Socorro Lens v0.3. https://ashughes.com/?p=360 In a nutshell, this inserts a graph of aggregate crash data for signatures listed in the Crash Signature field of a bug report. The visualization is powered by MetricsGraphics.js and the data is coming from the Socorro supersearch API. Feedback welcome! Cheers -- Anthony Hughes Senior Quality Engineer Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Reducing the NVIDIA Blacklist
Hello Mozillians, We recently relaxed our graphics blocklist for users with NVIDIA hardware using certain older graphics drivers. The original blocklist entry blocked all versions less than v8.17.11.8265 due to stability issues with NVIDIA 182.65 and earlier. We recently learned however that the first two numbers in the version string indicate platform version and the latter numbers refer to the actual driver version. As a result we were inadvertently blocking newer drivers on older platforms. We have since opened up the blacklist for versions newer than 8.15.11.8265 (Win XP) and 8.16.11.8265 (Vista/Win7) via https://bugzil.la/1284322, effectively drivers released beyond mid-2009.This change only exists on Nightly currently but we expect it to ride the trains unless some critical regression is discovered. If you are triaging bugs and user feedback, or are engaging with users on social media, please keep an eye out for users with NVIDIA hardware. If the user does have NVIDIA hardware please have them check the Graphics section of about:support to confirm if they are using a driver version that was previously blocked. If they are try to help them get updated to the most recent driver version. If the issue persists, have them disable hardware acceleration to see if the issue goes away. The same goes if you are a user experiencing quality issues (crashes, hangs, black screening, checkerboarding, etc) on NVIDIA hardware with these drivers. Please make sure your drivers are up to date. In either case, if the issue persists please file a bug via https://mzl.la/2a1qfUX so we can investigate what is happening. Feel free to email me if you have any questions. Thank you for your help! -- Anthony Hughes Sr. QA Engineer, Platform GFX Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DOM Bug Triage Meeting
Since I've only had one response I'll assume interest in a DOM triage meeting is pretty low. As such I don't think there will be much interest in a strictly scheduled meeting and will instead be doing triage sporadically on my own. Please email me back if you'd like to join me so that I can try to schedule my sporadic triage sessions at a time that is mutually convenient. Cheers On 2015-03-23 4:42 PM, Anthony Hughes wrote: Hello dev-platform, I'd like to set up a DOM triage meeting every two weeks to serve as a funnel for QA work. As a starting point we'd focus on intermittents needing QA help and resolved bugs needing manual testing or test coverage. Before I schedule a recurring meeting I'd like to gauge interest and availability. Please take some time to fill out this survey if you are interested: https://docs.google.com/forms/d/1UwvlAcDGSyfrEyF3kHAM7lTq7ZMnUmG0jr4sGvEG0Yg/viewform I am hoping to have this meeting up and running before Q2 begins. Thank you -- Anthony Hughes Senior Quality Engineer Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
DOM Bug Triage Meeting
Hello dev-platform, I'd like to set up a DOM triage meeting every two weeks to serve as a funnel for QA work. As a starting point we'd focus on intermittents needing QA help and resolved bugs needing manual testing or test coverage. Before I schedule a recurring meeting I'd like to gauge interest and availability. Please take some time to fill out this survey if you are interested: https://docs.google.com/forms/d/1UwvlAcDGSyfrEyF3kHAM7lTq7ZMnUmG0jr4sGvEG0Yg/viewform I am hoping to have this meeting up and running before Q2 begins. Thank you -- Anthony Hughes Senior Quality Engineer Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Helping the DOM Team
Hello dev-platform, I recently joined the DOM team as an embedded QA member. One of the things I've been working on is establishing and documenting QA processes. I have two goals with this effort: 1. To make it clear how volunteers can help 2. To make it clear how developers and QA can help each other If you go to MDN today, you'll find a Helping the DOM Team document[1] which focuses on explaining bug triage. I plan to continue building this out to include things such as feature ownership and test automation. My hope in sharing this with dev-platform is to improve engagement with developers. I welcome any feedback you want to share. Thank you. -- Anthony Hughes Senior Quality Engineer Mozilla Corporation 1. https://developer.mozilla.org/en-US/docs/Mozilla/QA/Helping_the_DOM_team ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Help with porting to Android One
Hello Kaushal, I'm sorry, I don't have an answer to your question. I suggest you repost this to the dev-...@lists.mozilla.org as that list has more people directly involved with B2G. Best of luck On 24 February 2015 at 18:53, Kaushal Rajkotia kaushal.rajko...@gmail.com wrote: I visited the mozilla website to get instructions for flashing my phone with B2G but it turns out that it isn't supported yet. My device : Karbonn Sparkle V (Android One), identified as 'sprout' on Cynogenmod. How do I get started with the codebase on github? and what are the things that I need to get from my device in order for me to begin changes on the B2G project? Thanks ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Anthony Hughes Senior Quality Engineer Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Please Help Dogfood Desktop Firefox 21.0b6
I'm writing today to ask for your help with dogfooding Firefox 21.0b6. There have been several changes lately to address stability concerns related to plugins. We need your help to determine if these changes have caused any regressions. All that you need to do is download and install the Beta[1] and use it as your day-to-day browser for the next few days. If you encounter any issues with plugins (Flash, Java, Silverlight, etc) please reply to this thread immediately describing the issue, any loaded URLs, and the plugin versions you have installed. Thank you Anthony Hughes QA Engineer, Desktop Firefox Mozilla Corporation 1. http://beta.mozilla.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming separation between resource://app and resource://gre
I've completed all the testing that I can think of to alert of us any concerns and found no regressions in the latest Nightly builds. See my comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=827354#c26 Please advise if anything more is needed. Anthony Hughes QA Engineer, Desktop Firefox Mozilla Corporation - Original Message - From: Anthony Hughes ahug...@mozilla.com To: Dave Townsend dtowns...@mozilla.com Cc: dev-platform@lists.mozilla.org Sent: Friday, February 8, 2013 9:28:33 AM Subject: Re: Upcoming separation between resource://app and resource://gre If we could identify some of the more popular add-ons that meet this criteria I can add it to my test plan. I'll be testing this in Nightly on Tuesday. Anthony Hughes QA Engineer, Desktop Firefox Mozilla Corporation - Original Message - From: Dave Townsend dtowns...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Friday, February 8, 2013 9:17:04 AM Subject: Re: Upcoming separation between resource://app and resource://gre On 2/8/2013 7:11 AM, Matt Brubeck wrote: On 2/7/2013 6:12 AM, Mike Hommey wrote: - But really, what does it change for developers? Almost nothing they shouldn't be doing already. The main difference is that resource://app/ and resource://gre/ urls are not going to point to the same location anymore, which means I won't have to file bugs about $randomFile including resource://gre/modules/something.jsm instead of resource://app/modules/something.jsm. This seems like a major add-on compatibility issue. Has anyone looked into how many add-ons will now have incorrect resource: URIs? How can we scan for these, and how can we mitigate the breakage? Any add-ons that get broken by thins would have already been broken when used on most linux distributions. That said we could search the add-ons mxr for instances of common gre modules in use without the prefix. ___ 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming separation between resource://app and resource://gre
If we could identify some of the more popular add-ons that meet this criteria I can add it to my test plan. I'll be testing this in Nightly on Tuesday. Anthony Hughes QA Engineer, Desktop Firefox Mozilla Corporation - Original Message - From: Dave Townsend dtowns...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Friday, February 8, 2013 9:17:04 AM Subject: Re: Upcoming separation between resource://app and resource://gre On 2/8/2013 7:11 AM, Matt Brubeck wrote: On 2/7/2013 6:12 AM, Mike Hommey wrote: - But really, what does it change for developers? Almost nothing they shouldn't be doing already. The main difference is that resource://app/ and resource://gre/ urls are not going to point to the same location anymore, which means I won't have to file bugs about $randomFile including resource://gre/modules/something.jsm instead of resource://app/modules/something.jsm. This seems like a major add-on compatibility issue. Has anyone looked into how many add-ons will now have incorrect resource: URIs? How can we scan for these, and how can we mitigate the breakage? Any add-ons that get broken by thins would have already been broken when used on most linux distributions. That said we could search the add-ons mxr for instances of common gre modules in use without the prefix. ___ 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
Re: server not found myspace
On 12-08-26 06:12 AM, Whiffy wrote: Is the myspace website down? I get server not found on Firefox Internet Explorer gets cannot display the webpage it was the same yesterday also at the command prompt... C:\Documents and Settings\userping www.myspace.com Ping request could not find host www.myspace.com. Please check the name and try again. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform Whiffy, you are probably better off posting like this to support.mozilla.org. The dev-platform mailing list is not really the right place. That said, www.myspace.com works fine for me. -- Anthony Hughes Quality Engineer Mozilla QA (Desktop) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: STR Needed Keyword?
For those interested, I've gone ahead and filed a bug to get the keyword added: https://bugzilla.mozilla.org/show_bug.cgi?id=785519 Thanks to everyone who provided feedback. On 12-08-17 10:30 AM, Ralph Giles wrote: On 12-08-16 6:01 PM, Anthony Hughes wrote: (CCing dev-quality to reach a broader audience -- please direct responses to dev-platform) It has come to my attention that we lack a keyword in Bugzilla for when steps-to-reproduce are needed (a very common request). However, we do have keywords for when a testcase, regression range, or URLs are wanted. I find it to be extremely useful when someone requesting qawanted pairs it with a keyword indicating what is being requested. It's certainly more efficient then having to parse the comments to interpret the request. Assuming support for such a keyword here are some proposed names: * steps-wanted * str-wanted * needSTR * need-steps Would people find this keyword useful? If so, I can file a bug to get it added. I think this would be useful, and improves workflow clarity along the lines of dbaron's blog post yesterday. * steps-wanted This is the most obvious of the options you gave. -r -- Anthony Hughes Quality Engineer Mozilla QA (Desktop) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Verification Culture
Sorry, this should have went to dev-platform... - Original Message - From: Anthony Hughes ahug...@mozilla.com To: dev-planning dev-plann...@lists.mozilla.org Cc: dev-qual...@lists.mozilla.org Sent: Friday, August 10, 2012 1:40:15 PM Subject: Fwd: Verification Culture I started this discussion on dev-quality[1] but there has been some suggestion that the dev-planning list is more appropriate so I'm moving the discussion here. There's been a couple of great responses to the dev-quality thread so far but I won't repost them here verbatim. The general concensus in the feedback was that QA spending a lot of time simply verifying that the immediate test conditions (or test case) is not a valuable practice. It was suggested that it would be a far more valuable use of QA's time and be of greater benefit to the quality of our product if we pulled out a subset of critical issues and ran deep-diving sprints around those issues to touch on edge-cases. I, for one, support this idea in the hypothetical form. I'd like to get various peoples' perspectives on this issue (not just QA). Thank you do David Baron, Ehsan Akhgari, Jason Smith, and Boris Zbarsky for the feedback that was the catalyst for me starting this discussion. For reference, it might help to have a look at my dev-planning post[2] which spawned the dev-quality post, which in turn has spawned the post you are now reading. Anthony Hughes Mozilla Quality Engineer 1. https://groups.google.com/forum/#!topic/mozilla.dev.quality/zpK52mDE2Jg 2. https://groups.google.com/forum/#!topic/mozilla.dev.planning/15TSrCbakEc - Forwarded Message - From: Anthony Hughes ahug...@mozilla.com To: dev-qual...@lists.mozilla.org Sent: Thursday, August 9, 2012 5:14:02 PM Subject: Verification Culture Today, David Baron brought to my attention an old bugzilla comment[1] about whether or not putting as much emphasis on bug fix verification was a useful practice or not. Having read the comment for the first time, it really got me wondering whether our cultural desire to verify so many bug fixes before releasing Firefox to the public was a prudent one. Does verifying as many fixes as we do really raise the quality bar for Firefox? Could the time we spend be better used elsewhere? If I were to ballpark it, I'd guess that nearly half of the testing we do during Beta is for bug fix verifications. Now sure, we'll always want to have some level of verification (making sure security fixes and critical regressions are *truly* fixed is important); But maybe, just maybe, we're being a little too purist in our approach. What do you think? Anthony Hughes Quality Engineer Mozilla Corporation 1. https://bugzilla.mozilla.org/show_bug.cgi?id=172191#c16 ___ dev-quality mailing list dev-qual...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-quality ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
