Re: Too many oranges!

On 2015-12-29 6:24 PM, Steve Fink wrote: That makes me think that we're not disagreeing very much. Still some, I think, but sure -- if assigning a handful of people to work on intermittent oranges makes the problem go away, then that seems like a reasonable thing to do. Though if you're taking ex

Re: Too many oranges!

More to the point, I don't think that doing this is "a big hammer [that] should be used sparingly." Getting paid to work on Mozilla stuff is a huge privilege, and that privilege comes with the duty to work on what the organization thinks is most important. The fact that it's often most prac

Re: Too many oranges!

On Tue, Dec 29, 2015 at 12:23 PM, Steve Fink wrote: > On 12/29/2015 11:49 AM, Bobby Holley wrote: > > > > On Tue, Dec 29, 2015 at 11:41 AM, Steve Fink wrote: > >> On 12/22/2015 10:06 AM, L. David Baron wrote: >> >>> But I don't think having mozilla-inbound/mozilla-central be closed >>> more than

Re: Too many oranges!

On 12/29/2015 11:49 AM, Bobby Holley wrote: On Tue, Dec 29, 2015 at 11:41 AM, Steve Fink > wrote: On 12/22/2015 10:06 AM, L. David Baron wrote: But I don't think having mozilla-inbound/mozilla-central be closed more than it already is is going to

Re: Too many oranges!

On Tue, Dec 29, 2015 at 11:41 AM, Steve Fink wrote: > On 12/22/2015 10:06 AM, L. David Baron wrote: > >> On Tuesday 2015-12-22 11:49 -0500, Ehsan Akhgari wrote: >> >>> On 2015-12-22 11:18 AM, Kartikaya Gupta wrote: >>> On Mon, Dec 21, 2015 at 3:11 PM, L. David Baron wrote: > I

Re: Too many oranges!

On 12/22/2015 10:06 AM, L. David Baron wrote: On Tuesday 2015-12-22 11:49 -0500, Ehsan Akhgari wrote: 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.

Re: Too many oranges!

On 22/12/2015 17:40, James Graham wrote: 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

Re: Too many oranges!

On 12/22/15 5:38 PM, 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. While I am all for raising awareness of oranges, I don't think posting them to dev-platform is the right thi

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 > > On Tue, Dec 22,

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 on top of things. >

Re: Too many oranges!

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 on top of things. On Dec 22, 2015 2:58 PM, "Jason Duell" wrote: > > > On Tue, Dec 22, 2015 at 11:38 AM, Ben Kelly wrote: > >> >> I'd rather see us do: >> >> 1) Rai

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. Wit

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 b

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 intermi

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 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 RyanVM > used to do th

Re: Too many oranges!

On 12/22/2015 10:40 AM, Andrew Halberstadt wrote: 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. I agree that it is necessary to have

Re: Too many oranges!

On Tuesday 2015-12-22 11:49 -0500, Ehsan Akhgari wrote: > 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 t

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 refac

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 any

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 th

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 nothing but quality (fi

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 extended periods just lea

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 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 triaging, > no featu

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 t

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 fo

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 triaging, > no featur

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 mu

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. > > How about everybody

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 A

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 spam

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, refactoring

Re: Too many oranges!

On Tue, Dec 22, 2015 at 6:16 AM, Kartikaya Gupta wrote: > So, I propose that we create an orangefactor threshold above which the > tree should just be closed until people start fixing intermittent > oranges. Thoughts? I think oranges on try is somehow different than oranges on integration trees,

Re: Too many oranges!

On Monday, December 21, 2015 at 1:16:13 PM UTC-6, Kartikaya Gupta wrote: > So, I propose that we create an orangefactor threshold above which the > tree should just be closed until people start fixing intermittent > oranges. Thoughts? > > kats How about regularly scheduled test fix days where eve

Re: Too many oranges!

On Monday 2015-12-21 14:16 -0500, Kartikaya Gupta wrote: > Is it just me, or has the number of intermittent oranges gone up quite > a lot in the last couple of months? It seems like every try push I do > has a lot of oranges which are completely unrelated to may patch. > Clearly everbody has more u

Too many oranges!

Is it just me, or has the number of intermittent oranges gone up quite a lot in the last couple of months? It seems like every try push I do has a lot of oranges which are completely unrelated to may patch. Clearly everbody has more urgent things to do than fix intermittent failures (myself include