Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla

[David Ascher]

Seems like a good proposal, but dev-platform doesn't really feel like the
best place to get feedback from the people affected.  Not sure what would
be, though.

(on Labs: There's a bunch of smaller projects there, but I don't mind if
they're slightly harder to find)

--da


On Mon, Mar 18, 2013 at 9:27 AM, Jason Smith  wrote:

> Hi Everyone,
>
> In bug 851818 
> (https://bugzilla.mozilla.org/**show_bug.cgi?id=851818),
> I've filed a bug to suggest rethinking what our enter bug entry page for
> users who are filing bugs with canconfirm or no canconfirm access. I'd like
> to discuss what changes we should make to that enter bug entry page such as
> adding new products to the list that we think should be there, keeping
> certain products on the list that are important enough to remain there, and
> removing certain products that we don't think need to be there. I've
> outlined the state of enter bug entry pages under canconfirm and no
> canconfirm below and included my initial thoughts below. Thoughts?
>
> *existing canconfirm access* *enter bug entry page list*
>
> - Core
> - Firefox
> - Thunderbird
> - Calendar
> - Camino
> - SeaMonkey
> - Firefox for Android
> - Mozilla Localizations
> - Mozilla Labs
> - Mozilla Services
> - Other Products
>
> *existing no canconfirm access enter bug entry page list*
>
> - Firefox
> - Firefox for Android
> - Thunderbird
> - Mozilla Services
> - SeaMonkey
> - Mozilla Localizations
> - Mozilla Labs
> - Calendar
> - Core
>
> *Ideas for what products we should add*
>
> - BootToGecko (canconfirm and not canconfirm)
> - Firefox for Metro (canconfirm and not canconfirm)
> - Marketplace (canconfirm and not canconfirm)
>
> *Ideas for what products we should remove*
>
> - Thunderbird (canconfirm and not canconfirm)
> - Calendar (canconfirm and not canconfirm)
> - Camino (canconfirm and not canconfirm)
> - SeaMonkey (canconfirm and not canconfirm)
> - Mozilla Labs (canconfirm and not canconfirm)
>
> *Rationale for Additions*
>
> - BootToGecko - Big focus at Mozilla with a lot of people working on this
> project, so I think this could benefit greatly from being on the front page.
> - Firefox for Metro - Important for our Windows 8 story and could probably
> benefit for contributors from knowing up front where to file bugs on this
> while it's under development
> - Marketplace - Important in conjunction with BootToGecko and a common
> bugzilla product I don't think people realize exists. In doing bug triage
> for B2G, there's very high cases where bugs for Marketplace have ended up
> in the incorrect component, so I'm hoping putting this on the front page
> will increase likelihood that the bug ends up in the right spot.
>
> *Rationale for Removals*
>
> - Thunderbird - Decreased focus at Mozilla now that has moved to
> contribution only now, so I don't think this needs to be on the front page.
> - Calendar - Decreased focus at Mozilla overall in comparison to other
> products on the front page
> - Camino - Low focus at Mozilla overall in comparison to other products on
> the front page
> - SeaMonkey - Low focus at Mozilla overall in comparison to other products
> on the front page
> - Mozilla Labs - Looks like an outdated Bugzilla product that may not have
> high bug filing usage - probably does not need to be on the front page
>
> --
> Sincerely,
> Jason Smith
>
> Desktop QA Engineer
> Mozilla Corporation
> https://quality.mozilla.com
>
> __**_
> 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: Nightly *very* crashy on OSX

[David Ascher]

Mine is crashing on startup.  Can't even get to profile chooser dialog.


On Sun, Apr 21, 2013 at 6:55 AM, Axel Hecht  wrote:

> Hi,
>
> I'm having a very crashy nightly, uptime below an hour, not really bound
> to a site.
>
> Might be 
> https://bugzilla.mozilla.org/**show_bug.cgi?id=864125,
> but I've experienced a bunch of crashes, all with pretty non-existing stack
> traces of no or one frame.
>
> bp-48ad9b29-145f-49ec-b282-**5538f2130421 4/21/13 3:27 PM
> bp-bea9322a-ab85-4586-8f26-**bfbcb2130421 4/21/13 2:45 PM
> bp-b3b43fa7-4c37-4f92-8d17-**c82802130420 4/20/13 10:59 PM
> bp-7e7f70e9-85c9-4fd2-a2d6-**31c892130420 4/20/13 8:34 PM
> bp-3faed1dd-98bb-4448-997b-**db6f22130420 4/20/13 8:16 PM
> bp-5440caa0-7ebc-48e2-bd15-**7fcf12130416 4/17/13 12:44 AM
> bp-3dbd9606-7d63-4a90-957a-**98f772130416 4/17/13 12:32 AM
> bp-2b7ac91d-1110-4780-9370-**89a372130416 4/17/13 12:31 AM
>
> Any ideas?
>
> Axel
> __**_
> 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: Some data on mozilla-inbound

[David Ascher]

> The messaging around this should not be to tell people "always test on
> try".  It should be to help them figure out how to make better judgement
> calls on this.  This is a skill that people develop and are not born with,
> and without data it's hard an an individual to judge how good I'm at that.


One idea might be to give developers feedback on the consequences of a
particular push, e.g. the AWS cost, a proxy for "time during which
developers couldn't push" or some other measurable metric.  Right now each
push probably "feels" as "expensive" as every other.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform