Re: Too many oranges!

2015-12-22 Thread Mike Conley 
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, etc.

On 21 December 2015 at 17:35,  wrote:

> 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 everyone drops what they
> are doing and spends a day fixing tests? mc could be closed to everything
> except critical work and test fixes. Managers would be able to opt
> individuals out of this as needed but generally everyone would be expected
> to take part.
>
> Jim
> ___
> 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

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

2015-12-22 Thread Andrei Vaida 

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:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
SeverityID  Summary Status  Resolution  Is a regression 
Assigned to
NORMAL  1233359 
Glitches after opening images in facebook
NEW 
YES  NOBODY



*BETA CHANNEL*
SeverityID  Summary Status  Resolution  Is a regression 
Assigned to
NORMAL  1233414 
	Bookmarking a URL that redirects to something else results in a null 
bookmark

NEW 
YES  NOBODY



*AURORA CHANNEL*
SeverityID  Summary Status  Resolution  Is a regression 
Assigned to
NORMAL  1233073 
[Linux] Youtube videos have a short flicker while going into fullscreen
NEW 
TBD NOBODY
NORMAL  1233046 
	[MAC] ”This demo requires the OES_texture_float extension” error for 
WebGL animation

NEW 
YES  NOBODY



*NIGHTLY CHANNEL
— Nightly 45.0a1
*
SeverityID  Summary Status  Resolution  Is a regression 
Assigned to
NORMAL  1232248 
	Change the way that sharing notification interacts with other infobars 
(translation, EME, plugins etc.)

NEW 
NO  NOBODY
NORMAL  1232254 
Ugly active hello icon when placed in additional tools and features
NEW 
YES  NOBODY
NORMAL  1232307 
Shaking strings when hovering context in standalone
NEW 
TBD NOBODY
NORMAL  1232659 
	[Ubuntu] Black border displayed for Hello conversation window when 
Quicktime is in use

NEW 
YES  NOBODY
NORMAL  1232663 
	Hello panel remains visible when selecting Sign In option via Settings 
gear button

NEW 
NO  NOBODY
NORMAL  1232650 
Unable to rejoin conversation after restart
NEW 
YES  NOBODY
NORMAL  1232675 
[intermittent] Blank Hello panel
NEW 
TBD NOBODY

*— Nightly 46.0a1
*
SeverityID  Summary Status  Resolution  Is a regression 
Assigned to
NORMAL  1233006 
On-screen keyboard is not displayed for google docs
NEW 
NO  NOBODY
NORMAL  1233425 
	Context room does not update in conversation window if focused tab is 
dragged out only after manually switching tabs

NEW 
NO  NOBODY
NORMAL  1233694 
Some settings did not successfully migrate while importing from IE
NEW 
TBD NOBODY



*ESR CHANNEL*
SeverityID  Summary Status  Resolution  Is a regression 
Assigned to
NORMAL  1232284 
[Ubuntu] Customize hint pop-up is resizable
NEW 
NO  NOBODY



Regards,
Andrei.
Andrei Vaida| QC Team Lead

SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania
Email: andrei.va...@softvision.ro  | 
Web: www.softvision.ro 


The content of this communication is classified as SOFTVISION 
Confidential and Proprietary Information.



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

Re: Too many oranges!

2015-12-22 Thread Jason Duell 
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 that, but not sure if its still happening now that he has
> changed roles.
>
> Ben
>
>
I'm with bkelly on this one.  Maybe with some additional initial messaging
("War on Orange raised in priority!") too.  I don't think we want to pivot
all work in platform for this.

Jason



>
> >
> > On Tue, Dec 22, 2015 at 7:41 AM Mike Conley  wrote:
> >
> > > 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, etc.
> > >
> > > On 21 December 2015 at 17:35,  wrote:
> > >
> > > > 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 everyone drops what
> > > they
> > > > are doing and spends a day fixing tests? mc could be closed to
> > everything
> > > > except critical work and test fixes. Managers would be able to opt
> > > > individuals out of this as needed but generally everyone would be
> > > expected
> > > > to take part.
> > > >
> > > > Jim
> > > > ___
> > > > 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
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

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

Re: Too many oranges!

2015-12-22 Thread Douglas Turner 
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 and this means
not being too prescriptive (e.g., fix bug 123, 456, xyz.  Go reduce the
number of orange tests.).  However, organizationally we need to improve our
over all backlogs, fix the papercuts, reduce test failures, improve
developer productivity, build better tooling etc.  We need to set aside
time to sharpen our axe.

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 be delivered by Aug, we can build in time to
sharpen our axe.

Another suggest from blassey was to make the last two weeks of the cycle
focused on the above issues.  This is pretty slick as it is a forcing
function again devs crash landing features before an uplift (Not that we'd
ever do that!)

Doug

On Tue, Dec 22, 2015 at 11:58 AM Jason Duell  wrote:

> 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 that, but not sure if its still happening now that he has
>> changed roles.
>>
>> Ben
>>
>>
> I'm with bkelly on this one.  Maybe with some additional initial messaging
> ("War on Orange raised in priority!") too.  I don't think we want to pivot
> all work in platform for this.
>
> Jason
>
>
>
>>
>> >
>> > On Tue, Dec 22, 2015 at 7:41 AM Mike Conley 
>> wrote:
>> >
>> > > 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, etc.
>> > >
>> > > On 21 December 2015 at 17:35,  wrote:
>> > >
>> > > > 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 everyone drops
>> what
>> > > they
>> > > > are doing and spends a day fixing tests? mc could be closed to
>> > everything
>> > > > except critical work and test fixes. Managers would be able to opt
>> > > > individuals out of this as needed but generally everyone would be
>> > > expected
>> > > > to take part.
>> > > >
>> > > > Jim
>> > > > ___
>> > > > 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
>> >
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
> --
>
> Jason
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Too many oranges!

2015-12-22 Thread Mark Banner 

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 be delivered by Aug, we can build in time to
sharpen our axe.


On Hello, we've being attempting to take care of quality slightly 
different. We're working in an agile manner, and for each cycle, we're 
trying to allocate a certain amount of time to fixing bugs, addressing 
technical debt, and other quality issues. I can't remember the exact 
percentages at the moment, but I know we originally discussed something 
like 20%. The remaining 80% is spent on feature work. We're also 
starting to expect/allocate more time for fully implementing features 
after the "initial" implementation is complete.


We've only been trying this over the last couple of months, and with 
other changes going on at the same time, I think its too early to say 
how successful we're being. For me, the positive part, is that we're 
constantly thinking about quality and improving the code base, rather 
than doing it in spurts when it gets very bad.


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

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

2015-12-22 Thread Joshua Carpenter 

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 make the time work for other time  
zones.

When: Tue Dec 29, 2015 9am - 10am Pacific Time
Where: WebVR Vidyo
Calendar: jcarpen...@mozilla.com
Who:
* Joshua Carpenter - organizer
* Kevin Grandon
* Kevin Ngo
* Tim Chien
* Chris Van
* Daosheng Mu
* George Williams
* Kearwood Kip Gilbert
* Casey (Kok Ching) Yee
* Jonas Sicking

Event details:  
https://www.google.com/calendar/event?action=VIEW=XzhkMzRjaDIyNmdvajJiYTU2aDJrOGI5azY5MWpjYmEyNjhxNGNiOW02cDI0MmNxNDhvb2pjZzlpOGcgZGV2LXBsYXRmb3JtQGxpc3RzLm1vemlsbGEub3Jn=MjIjamNhcnBlbnRlckBtb3ppbGxhLmNvbWNjNzgyMjY1ZWExYzVlNTY5ZjU2OTM5MTA3Nzc1NzYyOWJhNTFiYTk=America/Los_Angeles=en


Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account  
dev-platform@lists.mozilla.org because you are an attendee of this event.


To stop receiving future updates for this event, decline this event.  
Alternatively you can sign up for a Google account at  
https://www.google.com/calendar/ and control your notification settings for  
your entire calendar.


Forwarding this invitation could allow any recipient to modify your RSVP  
response. Learn more at  
https://support.google.com/calendar/answer/37135#forwarding

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

Re: about:profiles and the new profile manager

2015-12-22 Thread yali001 
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 the Firefox front-end or Firefox UX team
> > about this already?
> >
> 
> Jeff Griffiths, but there is not a serious plan about improving the UX of
> the ProfileManager, yet.
> 
> b

Thanks Andrea. I had three issues, maybe you might know how to address these:
1) Any ideas on how to restart into another build? For example if currently 
running in nightly.app/exe, and I want to restart that profile into 
develeoper.app/exe, the restart mechanism only launches into the same profile, 
so I had trouble with that.

2) On mac os x, when create system launcher it breaks the update mechanism -  
reason this is needed is because otherwise you cant "keep in dock", "custom 
icons", and some other stuff - http://i.imgur.com/XfRDaw8.png --- a) I copy the 
Firefox.app, Firefox.app/Contents b) I then copy as "symlink" the 
Firefox.app/Contents/MacOS, and Firefox.app/Contents/Resources c) I then create 
in the origianl MacOS folder a shell script d) In original resources folder I 
create a new icon specific for this profile e) I then copy over the plist.info 
but change the execute line to the new one created in "c" and icon to the new 
one created in "d". --- Now this works, however updates fail to happen, it 
always tries to download it. The issue is these special paths no should point 
to original directory as I "symlink"ed it, however they are pointing to the new 
location. I am going to try "alias"'ing them instead of "symlink"ing them and 
see if that fixes it. But would you happen to know? If "alias" m
 ethod doesn't work either, would we be able to land a patch so that it tests 
if its a symlink/alias and gets the original path?

These are the special paths that get overridden - UpdRootD, XREExeF, 
XREAppDist, DefRt, PrfDef, profDef, ProfDefNoLoc, ARes, AChrom, APlugns, 
SrchPlugns, XPIClnupD, CurProcD, XCurProcD, XpcomLib, GreD, GreBinD, ProfLDS, 
ProfLD. Overriding them to point to the original path with this method does not 
fix it - http://stackoverflow.com/a/28357788/1828637

3) The last one was caching issues when cloning a profile. I discovered jpm 
uses firefoxl-profile-js module, so I'm going to try that - 
https://github.com/saadtazi/firefox-profile-js/issues/56 - but do you have any 
experience with cloning profiles?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Too many oranges!

2015-12-22 Thread Douglas Turner 
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.
> 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) 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 that, but not sure if its still happening now that he has
>>> changed roles.
>>>
>>> Ben
>>>
>>>
>> I'm with bkelly on this one.  Maybe with some additional initial
>> messaging ("War on Orange raised in priority!") too.  I don't think we want
>> to pivot all work in platform for this.
>>
>> Jason
>>
>>
>>
>>>
>>> >
>>> > On Tue, Dec 22, 2015 at 7:41 AM Mike Conley 
>>> wrote:
>>> >
>>> > > 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, etc.
>>> > >
>>> > > On 21 December 2015 at 17:35,  wrote:
>>> > >
>>> > > > 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 everyone drops
>>> what
>>> > > they
>>> > > > are doing and spends a day fixing tests? mc could be closed to
>>> > everything
>>> > > > except critical work and test fixes. Managers would be able to opt
>>> > > > individuals out of this as needed but generally everyone would be
>>> > > expected
>>> > > > to take part.
>>> > > >
>>> > > > Jim
>>> > > > ___
>>> > > > 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
>>> >
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
>>
>> --
>>
>> Jason
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Too many oranges!

2015-12-22 Thread Ben Kelly 
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, 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.
>> 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) 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 that, but not sure if its still happening now that he has
 changed roles.

 Ben


>>> I'm with bkelly on this one.  Maybe with some additional initial
>>> messaging ("War on Orange raised in priority!") too.  I don't think we want
>>> to pivot all work in platform for this.
>>>
>>> Jason
>>>
>>>
>>>

 >
 > On Tue, Dec 22, 2015 at 7:41 AM Mike Conley 
 wrote:
 >
 > > 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, etc.
 > >
 > > On 21 December 2015 at 17:35,  wrote:
 > >
 > > > 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 everyone drops
 what
 > > they
 > > > are doing and spends a day fixing tests? mc could be closed to
 > everything
 > > > except critical work and test fixes. Managers would be able to opt
 > > > individuals out of this as needed but generally everyone would be
 > > expected
 > > > to take part.
 > > >
 > > > Jim
 > > > ___
 > > > 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
 >
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

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

unowned orange by team

2015-12-22 Thread Ben Kelly 
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 in your team, please feel free to jump on it.  I'm also
going to try to track down a manager for each team to see if they can help
prioritize things.  Of course, the holiday will complicate things, but
maybe we can get this sorted quickly when we get back from break.

Thanks everyone!

Of the top 30 orange we have only six that are clearly being owned and
worked by someone.  The rest fall into these rough categories/teams:

memory:
1) https://bugzilla.mozilla.org/show_bug.cgi?id=1220517
20) https://bugzilla.mozilla.org/show_bug.cgi?id=1218297

addons:
4) https://bugzilla.mozilla.org/show_bug.cgi?id=1135866

ateam/releng:
5) https://bugzilla.mozilla.org/show_bug.cgi?id=1197950
9) https://bugzilla.mozilla.org/show_bug.cgi?id=1198092
10) https://bugzilla.mozilla.org/show_bug.cgi?id=1231798
17) https://bugzilla.mozilla.org/show_bug.cgi?id=1073442
18) https://bugzilla.mozilla.org/show_bug.cgi?id=1204281
25) https://bugzilla.mozilla.org/show_bug.cgi?id=1231034
30) https://bugzilla.mozilla.org/show_bug.cgi?id=1234416

necko:
7) https://bugzilla.mozilla.org/show_bug.cgi?id=1203430
12) https://bugzilla.mozilla.org/show_bug.cgi?id=1233774

firefox:
8) https://bugzilla.mozilla.org/show_bug.cgi?id=1182072
9) https://bugzilla.mozilla.org/show_bug.cgi?id=1230027

e10s:
11) https://bugzilla.mozilla.org/show_bug.cgi?id=1230978

dom:
14) https://bugzilla.mozilla.org/show_bug.cgi?id=1197786
15) https://bugzilla.mozilla.org/show_bug.cgi?id=1227320
24) https://bugzilla.mozilla.org/show_bug.cgi?id=1203441
27) https://bugzilla.mozilla.org/show_bug.cgi?id=1213633

layout:
19) https://bugzilla.mozilla.org/show_bug.cgi?id=1204897

devtools:
21) https://bugzilla.mozilla.org/show_bug.cgi?id=992275
22) https://bugzilla.mozilla.org/show_bug.cgi?id=1210208
23) https://bugzilla.mozilla.org/show_bug.cgi?id=1230031
29) https://bugzilla.mozilla.org/show_bug.cgi?id=1209295

android:
23) https://bugzilla.mozilla.org/show_bug.cgi?id=1213030
28) https://bugzilla.mozilla.org/show_bug.cgi?id=1118268

fxos:
24) https://bugzilla.mozilla.org/show_bug.cgi?id=999675

Thanks again for your help with this.

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

Re: Too many oranges!

2015-12-22 Thread Chris Peterson 

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 intermittent orange counts associated with them, and
being accountable for them in goals and deliverables.


The Firefox team plans for three two-week iterations per release cycle. 
To make quality a long-term commitment, we could dedicate the third 
two-week iteration of each release cycle to just fixing tests and bugs.


This has the added benefit of stablizing Nightly before it merges to Dev 
Edition. People have expressed concerns that Dev Edition, as a "real 
product", should have a higher quality bar than Aurora did.


OTOH, a mozilla-central code freeze will frustrate people and lead to 
more big landings in the first or second iteration of the each release 
cycle. That might be OK because those features would then have 2–5 weeks 
of bake time on Nightly instead of just one. :)

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

Re: Too many oranges!

2015-12-22 Thread Karl Tomlinson 
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. With the old
> system I just got so much intermittent-failure bugmail that I would
> just ignore it all.

Yes, periodic summaries would be much better than the previous
approach, but not all occurrences are reported.  Sometimes a
search on http://brasstacks.mozilla.com/orangefactor/ is required.

The "Bug Details" search is much faster than the search on the front
page, but it would be more helpful if all occurrences trigger some
sort of periodic report, to indicate whether a search would find
anything.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: unowned orange by team

2015-12-22 Thread Tim Guan-tin Chien 
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
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: One-off Background Sync API

2015-12-22 Thread Fernando Jiménez Moreno 
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 have passed, the 
event completes without a waitUntil, or the waitUntil rejects/resolves. If the 
event fails, the browser will retry (exponential backoff) up to a total of five 
attempts.

Motivation

Web Applications often run in environments with unreliable networks (e.g., 
mobile phones) and unknown lifetimes (the browser might be killed or the user 
might navigate away). This makes it difficult to synchronize client data from 
web apps (such as photo uploads, document changes, or composed emails) with 
servers. If the browser closes or the user navigates away before 
synchronization can complete, the app must wait until the user revisits the 
page to try again. This specification provides a new onsync service worker 

 event which can fire in the background 
 so that 
synchronization attempts can continue despite adverse conditions when initially 
requested. This API is intended to reduce the time between content creation and 
content synchronization with the server.

Bug

https://bugzilla.mozilla.org/show_bug.cgi?id=1217544 


Link to standard

https://wicg.github.io/BackgroundSync/spec/ 


Platform coverage

Desktop, Android, Firefox OS.

State in other UAs

Already implemented on Chrome, unclear on the others.

Preference behind which this will be implemented

dom.background.sync.enabled

Cheers,

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

Intent to implement: One-off Background Sync API

2015-12-22 Thread Fernando Jiménez Moreno 
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 have passed, the 
event completes without a waitUntil, or the waitUntil rejects/resolves. If the 
event fails, the browser will retry (exponential backoff) up to a total of five 
attempts.

Motivation

Web Applications often run in environments with unreliable networks (e.g., 
mobile phones) and unknown lifetimes (the browser might be killed or the user 
might navigate away). This makes it difficult to synchronize client data from 
web apps (such as photo uploads, document changes, or composed emails) with 
servers. If the browser closes or the user navigates away before 
synchronization can complete, the app must wait until the user revisits the 
page to try again. This specification provides a new onsync service worker 

 event which can fire in the background 
 so that 
synchronization attempts can continue despite adverse conditions when initially 
requested. This API is intended to reduce the time between content creation and 
content synchronization with the server.

Bug

https://bugzilla.mozilla.org/show_bug.cgi?id=1217544 


Link to standard

https://wicg.github.io/BackgroundSync/spec/ 


Platform coverage

Desktop, Android, Firefox OS.

State in other UAs

Already implemented on Chrome, unclear on the others.

Preference behind which this will be implemented

dom.background.sync.enabled

Cheers,

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

Re: about:profiles and the new profile manager

2015-12-22 Thread Benjamin Smedberg 



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 that, it's not intended for use by end-users.


One of the things I'm most concerned about with about:profiles is that 
it will be easier for users to discover it, but the technical benefits 
of removing a lot of the no-profile gecko startup paths and complex 
restart logic will make this a nice win overall.


--BDS

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

Re: Too many oranges!

2015-12-22 Thread Douglas Turner 
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 AM Mike Conley  wrote:

> 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, etc.
>
> On 21 December 2015 at 17:35,  wrote:
>
> > 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 everyone drops what
> they
> > are doing and spends a day fixing tests? mc could be closed to everything
> > except critical work and test fixes. Managers would be able to opt
> > individuals out of this as needed but generally everyone would be
> expected
> > to take part.
> >
> > Jim
> > ___
> > 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: Too many oranges!

2015-12-22 Thread Mike Conley 
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 triaging, no feature development at all).
> 
> Thoughts?
> 
> On Tue, Dec 22, 2015 at 7:41 AM Mike Conley  > wrote:
> 
> 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, etc.
> 
> On 21 December 2015 at 17:35,  > wrote:
> 
> > 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 everyone drops
> what they
> > are doing and spends a day fixing tests? mc could be closed to
> everything
> > except critical work and test fixes. Managers would be able to opt
> > individuals out of this as needed but generally everyone would be
> expected
> > to take part.
> >
> > Jim
> > ___
> > 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: Too many oranges!

2015-12-22 Thread Kartikaya Gupta 
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 reading this message takes a look at the list on
> http://brasstacks.mozilla.com/orangefactor/ and takes one of them to
> fix?  (Or, better, redoes the search filtered on the last 3 days
> instead of last 7.)


I feel like a voluntary approach is likely to have very little effect,
given the way our goals and priorities are structured. There's very
little incentive to voluntarily spend time banging your head against a
wall. That's why I'm more in favor of a forced approach that is
mandated by managers/product owners/sheriffs (i.e. people who can
actually tell us to some extent what to do).

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

Re: Too many oranges!

2015-12-22 Thread Aaron Klotz 
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 focus on nothing but quality (fixing tests, bug triaging,
no feature development at all).

Thoughts?




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

Re: Too many oranges!

2015-12-22 Thread Bobby Holley 
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 to do things, but we have a large paid staff and
management/planning structure that is designed to direct some of our
resources to walking and some of them to chewing gum.

Last spring I worked on media quality while other people worked on
features. It went great, and there was far less coordination overhead than
if everyone was trying to work on the same thing.

bholley

On Tue, Dec 22, 2015 at 8:32 AM, Mike Conley  wrote:

> 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 triaging, no feature development at all).
> >
> > Thoughts?
> >
> > On Tue, Dec 22, 2015 at 7:41 AM Mike Conley  > > wrote:
> >
> > 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, etc.
> >
> > On 21 December 2015 at 17:35,  > > wrote:
> >
> > > 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 everyone drops
> > what they
> > > are doing and spends a day fixing tests? mc could be closed to
> > everything
> > > except critical work and test fixes. Managers would be able to opt
> > > individuals out of this as needed but generally everyone would be
> > expected
> > > to take part.
> > >
> > > Jim
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org  dev-platform@lists.mozilla.org>
> > > https://lists.mozilla.org/listinfo/dev-platform
> > >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org  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: Too many oranges!

2015-12-22 Thread Ehsan Akhgari 

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 leads to
big backups.

How about everybody reading this message takes a look at the list on
http://brasstacks.mozilla.com/orangefactor/ and takes one of them to
fix?  (Or, better, redoes the search filtered on the last 3 days
instead of last 7.)



I feel like a voluntary approach is likely to have very little effect,
given the way our goals and priorities are structured. There's very
little incentive to voluntarily spend time banging your head against a
wall. That's why I'm more in favor of a forced approach that is
mandated by managers/product owners/sheriffs (i.e. people who can
actually tell us to some extent what to do).


I have tried to volunteer some time from my weekends occasionally to 
look into the most recurring oranges every few weeks, and usually every 
time I manage to figure out a handful of bugs by spending a few hours 
and as a result OF would go down in the following week, but then it 
would go back up again.  This is a demotivating task and doesn't really 
scale to the magnitude of our orange problem.  I agree with kats that a 
voluntary based approach will not go anywhere.

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

Re: Too many oranges!

2015-12-22 Thread Ben Kelly 
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...  but it is a recent change.

On Tue, Dec 22, 2015 at 10:40 AM, Mike Conley  wrote:

> 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, etc.
>
> On 21 December 2015 at 17:35,  wrote:
>
> > 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 everyone drops what
> they
> > are doing and spends a day fixing tests? mc could be closed to everything
> > except critical work and test fixes. Managers would be able to opt
> > individuals out of this as needed but generally everyone would be
> expected
> > to take part.
> >
> > Jim
> > ___
> > 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: Too many oranges!

2015-12-22 Thread Kartikaya Gupta 
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 much intermittent-failure bugmail that I would
just ignore it all.

kats

On Tue, Dec 22, 2015 at 11:08 AM, Ben Kelly  wrote:
> 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...  but it is a recent change.
>
> On Tue, Dec 22, 2015 at 10:40 AM, Mike Conley  wrote:
>
>> 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, etc.
>>
>> On 21 December 2015 at 17:35,  wrote:
>>
>> > 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 everyone drops what
>> they
>> > are doing and spends a day fixing tests? mc could be closed to everything
>> > except critical work and test fixes. Managers would be able to opt
>> > individuals out of this as needed but generally everyone would be
>> expected
>> > to take part.
>> >
>> > Jim
>> > ___
>> > 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Too many oranges!

2015-12-22 Thread Kartikaya Gupta 
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 feature development at all).
>
> Thoughts?
>

I'm in favour of this. I'm assuming that the "spring release"
marketing is going to be focused around Firefox 46, so it would be
nice to spend the 47 nightly just doing quality fixes. More generally
it would be great to spend two releases a year (the first ones after
the fall/spring releases) just doing cleanup work.

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

Re: Too many oranges!

2015-12-22 Thread James Graham 

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 anyway if we do.


I think previous discussions on this topic have revealed that people 
mostly ignore those emails if they're not personally actionable. So 
whilst there are a few people who heroically go through all of the OF 
top bugs and try to get traction on fixes, we would get much better 
results from individual mail to developers or teams showing all the top 
intermittents which they are responsible for.


With that in mind, it's perhaps worth detailing some of the improvements 
we have in mind for treeherder in 2016:


1) Automatic classification of intermittent failures to help sheriffs on 
integration trees, and quickly identify failures that are new on try 
pushes. Potentially, automatic notification when an intermittent 
increases in frequency,


2) A replacement for Orange Factor, based on the same data as the 
autoclassification, that will make it easier to present personalised 
(or, at least path-filtered) lists of top intermittents. These could be 
posted to specific lists where most subscribers would get fully 
actionable information.

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

Re: Too many oranges!

2015-12-22 Thread Andrew Halberstadt 

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 (fixing tests, bug triaging,
no feature development at all).

Thoughts?



-1

This has been tried numerous times on fxos without success.  While it might
get oranges down temporarily, its not putting a system in place to address
the problem over the long haul.

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 that, but not sure if its still happening now that he has
changed roles.

Ben


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 anyway if we do.

-Andrew

[1] http://brasstacks.mozilla.com/orangefactor/






On Tue, Dec 22, 2015 at 7:41 AM Mike Conley  wrote:


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, etc.

On 21 December 2015 at 17:35,  wrote:


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 everyone drops what

they

are doing and spends a day fixing tests? mc could be closed to

everything

except critical work and test fixes. Managers would be able to opt
individuals out of this as needed but generally everyone would be

expected

to take part.

Jim
___
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



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

Re: Too many oranges!

2015-12-22 Thread Jonathan Griffin 
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 that lead to the current state: weak or
no ownership of many tests or suites, so that fixing these oranges is
always somebody else's problem, and a focus on "hard" deliverables which
often leave little or no time to deal with unplanned problems like an
increase in intermittents.

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 intermittent orange counts associated with them, and
being accountable for them in goals and deliverables.

Jonathan

On Tue, Dec 22, 2015 at 8: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 feature development at all).
>
> Thoughts?
>
> On Tue, Dec 22, 2015 at 7:41 AM Mike Conley  wrote:
>
> > 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, etc.
> >
> > On 21 December 2015 at 17:35,  wrote:
> >
> > > 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 everyone drops what
> > they
> > > are doing and spends a day fixing tests? mc could be closed to
> everything
> > > except critical work and test fixes. Managers would be able to opt
> > > individuals out of this as needed but generally everyone would be
> > expected
> > > to take part.
> > >
> > > Jim
> > > ___
> > > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Too many oranges!

2015-12-22 Thread Andrew Halberstadt 

+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 refactorings and fixing tests always get deprioritized
because it's really hard to estimate how beneficial they are to the
overall mission. It was much easier to say shiny new feature X aligns
nicely with our top-line goals.

Well, finally, our top-line goal is to "build core strength". To me that
means that fixing tests and quality *now have the greatest impact*, and
everyone's deliverables should reflect this new reality.

-Andrew

On 22/12/15 11:40 AM, Bobby Holley wrote:

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 to do things, but we have a large paid staff and
management/planning structure that is designed to direct some of our
resources to walking and some of them to chewing gum.

Last spring I worked on media quality while other people worked on
features. It went great, and there was far less coordination overhead than
if everyone was trying to work on the same thing.

bholley

On Tue, Dec 22, 2015 at 8:32 AM, Mike Conley  wrote:


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 triaging, no feature development at all).

Thoughts?

On Tue, Dec 22, 2015 at 7:41 AM Mike Conley > wrote:

 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, etc.

 On 21 December 2015 at 17:35, > wrote:

 > 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 everyone drops
 what they
 > are doing and spends a day fixing tests? mc could be closed to
 everything
 > except critical work and test fixes. Managers would be able to opt
 > individuals out of this as needed but generally everyone would be
 expected
 > to take part.
 >
 > Jim
 > ___
 > dev-platform mailing list
 > dev-platform@lists.mozilla.org 
dev-platform@lists.mozilla.org>

 > https://lists.mozilla.org/listinfo/dev-platform
 >
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org 
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