On Wed, Dec 23, 2015 at 12:15 PM, Ben Kelly wrote:
> dom:
> 14) https://bugzilla.mozilla.org/show_bug.cgi?id=1197786
> layout:
> 19) https://bugzilla.mozilla.org/show_bug.cgi?id=1204897
These two intermittents are actually the same issue, which is
https://bugzilla.mozilla.org/show_bug.cgi?id=1223
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-platfor
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 th
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
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,
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.
>
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
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
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
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
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
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
Hello team,
Thanks for using the ability of adding jobs to your pushes from
Treeherder [1].
I want to point out that some of you are having a great experience and
others not seeing anything happen or not all jobs being available.
There are some bugs in the code and efforts will be made in January
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
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
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
+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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 tha
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
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/
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 hav
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 hav
35 matches
Mail list logo
