Re: Too many oranges!

I would support scheduled time[1] to do maintenance[2] and help improve our developer tooling and documentation. I'm less sure how to integrate such a thing in practice. [1]: A day, a week, heck maybe even a release cycle [2]: Where maintenance is fixing oranges, closing out papercuts,

[Firefox Desktop] Issues found: December 14th to December 18th

Hi everyone, Here's the list of new issues found and filed by the Desktop Manual QA team last week (Week 51: December 14 - December 18). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

Re: Too many oranges!

On Tue, Dec 22, 2015 at 11:38 AM, Ben Kelly wrote: > > I'd rather see us do: > > 1) Raise the visibility of oranges. Post the most frequent intermittents > without an owner to dev-platform every N days. > 2) Make its someone's job to find owners for top oranges. I believe

Re: Too many oranges!

In general, we need to make some small but hard changes to our development process to improve overall quality of Gecko and Firefox. I don't think there is any silver bullet and we will probably try things that aren't universally +1'ed. We want devs to have autonomy to do what they think is right

Re: Too many oranges!

On 22/12/2015 20:41, Douglas Turner wrote: My suggest was to take the n-th milestone was a strawman. I think in terms of scheduling, setting aside every n-th milestone as a quality release helps planning a bunch. When we tell customers (the web, the firefox team, firefoxos) that feature X will

Invitation: VR Browser Technical Dev Options @ Tue Dec 29, 2015 9am - 10am (jcarpen...@mozilla.com)

You have been invited to the following event. Title: VR Browser Technical Dev Options Agenda: initial review of technical options for VR browser development in Q1. Kip and Casey will deliver their initial findings, based on work done since Orlando. Setting this early in the day in order to

Re: about:profiles and the new profile manager

On Monday, December 21, 2015 at 5:36:33 AM UTC-8, Andrea Marchesini wrote: > Hi Stephen, > > Can you tell us some more about next phases of this work before it would go > > into the product? > > > > Mainly fixing regressions and improving the usability. > > > > Have you consulted anyone from

Re: Too many oranges!

Thanks Ben -- really great. Let me know you need anything or if things get stuck! Doug On Tue, Dec 22, 2015 at 4:00 PM Ben Kelly wrote: > I'll triage the top orange tomorrow and try to find some owners for things. > > After the new year I'll set something weekly up to stay

Re: Too many oranges!

On Tue, Dec 22, 2015 at 7:29 PM, Douglas Turner wrote: > Thanks Ben -- really great. Let me know you need anything or if things > get stuck! > No problem. Although I should note David Baron has already NI'd a bunch of people on the top orange bugs. Thanks. Ben > > Doug

unowned orange by team

Hi all, In an attempt to wrangle some of the orange plaguing the tree I've tried to triage the top unowned bugs by team. If you are working one of these bugs, please assign yourself to it. If you're not working a bug, but are assigned, please drop it so we can see the status. If you see bugs

Re: Too many oranges!

On 12/22/15 9:39 AM, Jonathan Griffin wrote: If we dedicate a cycle to quality and tests, we should use that opportunity to figure out what a more viable strategy is longer-term for making sure these don't get out of hand again, which might include having teams adopt test, suites, and the

Re: Too many oranges!

Kartikaya Gupta writes: > Personally I much prefer the new approach to reporting intermittents. > It's much easier for me to see at a glance (i.e when the bugs are > updated with the weekly count) which ones are actually occurring more > frequently and which bug would be best to spend time on.

Re: unowned orange by team

On Wed, Dec 23, 2015 at 9:15 AM, Ben Kelly wrote: > fxos: > 24) https://bugzilla.mozilla.org/show_bug.cgi?id=999675 I've just disabled this test. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Intent to implement: One-off Background Sync API

Summary A ServiceWorker onsync event that can be registered for from a main-frame document or service worker with a main-frame client. Once registered, the onsync event will fire when next online (even after the page or browser has closed). The event doesn’t finish until either five minutes

Intent to implement: One-off Background Sync API

Summary A ServiceWorker onsync event that can be registered for from a main-frame document or service worker with a main-frame client. Once registered, the onsync event will fire when next online (even after the page or browser has closed). The event doesn’t finish until either five minutes

Re: about:profiles and the new profile manager

On 12/18/2015 5:09 PM, Stephen Horlander wrote: I am not sure I understand. Does "not intended to be product code" mean that this won't be riding the trains and shipping in a general release of Firefox? No. It means that, like the old profile manager, about:config, and other things like

Re: Too many oranges!

Mike -- totally supportive of this. I would *love* to see a release cycle completely dedicated to quality. We branch again on January 26. We could use that cycle to focus on nothing but quality (fixing tests, bug triaging, no feature development at all). Thoughts? On Tue, Dec 22, 2015 at 7:41

Re: Too many oranges!

You had me at "quality". :) On 22/12/2015 11:16 AM, Douglas Turner wrote: > Mike -- totally supportive of this. I would *love* to see a release > cycle completely dedicated to quality. We branch again on January 26. > We could use that cycle to focus on nothing but quality (fixing tests, > bug

Re: Too many oranges!

On Mon, Dec 21, 2015 at 3:11 PM, L. David Baron wrote: > I agree it's definitely gone up recently, and agree that it causes a > lot of wasted time. I'm not convinced about closing the tree, > though; keeping the tree closed for extended periods just leads to > big backups. > >

Re: Too many oranges!

I like the sound of your ideas and I would like to subscribe to your newsletter. On 12/22/2015 9:16 AM, Douglas Turner wrote: Mike -- totally supportive of this. I would *love* to see a release cycle completely dedicated to quality. We branch again on January 26. We could use that cycle to

Re: Too many oranges!

Do we actually need to have everybody working on oranges / quality at once? Shouldn't we just prioritize it (probably permanently) in a way such that _some_ members of every team are working on it? Saying "everybody needs to work on this together" is a socially expedient way of getting volunteers

Re: Too many oranges!

On 2015-12-22 11:18 AM, Kartikaya Gupta wrote: On Mon, Dec 21, 2015 at 3:11 PM, L. David Baron wrote: I agree it's definitely gone up recently, and agree that it causes a lot of wasted time. I'm not convinced about closing the tree, though; keeping the tree closed for

Re: Too many oranges!

Does anyone feel the changes to how intermittents are reported to bugs has affected things? We used to get a comment for each intermittent, but now its rolled up into a periodic summary. Perhaps people feel less urgency to fix things without the constant bugmail. Not that I want to advocate

Re: Too many oranges!

Personally I much prefer the new approach to reporting intermittents. It's much easier for me to see at a glance (i.e when the bugs are updated with the weekly count) which ones are actually occurring more frequently and which bug would be best to spend time on. With the old system I just got so

Re: Too many oranges!

On Tue, Dec 22, 2015 at 11:16 AM, Douglas Turner wrote: > Mike -- totally supportive of this. I would *love* to see a release cycle > completely dedicated to quality. We branch again on January 26. We could > use that cycle to focus on nothing but quality (fixing tests, bug

Re: Too many oranges!

On 22/12/15 17:22, Andrew Halberstadt wrote: FWIW a summary of top orangefactor[1] oranges are posted regularly to dev.tree-alerts. Configuring it to also post to dev.platform is certainly possible if that's what people want. Though I have a feeling that people will mostly ignore these emails

Re: Too many oranges!

On 22/12/15 11:38 AM, Ben Kelly wrote: On Tue, Dec 22, 2015 at 11:16 AM, Douglas Turner wrote: Mike -- totally supportive of this. I would *love* to see a release cycle completely dedicated to quality. We branch again on January 26. We could use that cycle to focus on

Re: Too many oranges!

I think this is a great idea. Although it won't fix the problem long-term, what it will do is get engineers and especially engineering managers thinking about the problem, and hopefully understanding it better so they can incorporate it into future priorities. There are two fundamental problems

Re: Too many oranges!

+1 I'd prefer to see quality be a perpetually ongoing effort over a periodic burst. I'd like to see management rotate people into "quality mode" by explicitly setting goals and deliverables around addressing it. The problem in the past has been this notion of "greatest impact". Things like