[please keep any replies on dev.b2g]
Mozilla and the community have been on a roll creating new products and
evolving existing ones. We now release multiple browsers across a multitude of
platforms, including
* Firefox – three desktop pre-release channels alongside our shipping version
for Mac
> So the main thing we'd lose is graph server monitoring of Trace Malloc Leaks.
> This is occasionally useful, but in a limited way because the monitoring
> process is unowned, and because the current value of the benchmark is high
> enough that small changes are ignored by the monitoring syste
I think we can only make this decision once we know the worst case scenario
these tests are currently preventing, so that we can mitigate or plan for it.
-Alex
On Jul 15, 2013, at 1:45 PM, Chris AtLee wrote:
> Hi!
>
> Leak tests on OSX have been failing intermittently for nearly a year now[1]
A lot of this has to do with population diversity (as opposed to size) and 3rd
party plugins/add-ons only targeting Beta/Release.
-Alex
On Apr 29, 2013, at 12:26 PM, Kyle Huey wrote:
> On Mon, Apr 29, 2013 at 12:17 PM, Taras Glek wrote:
>
>> What is the problem with current population size?
> Chrome has a six-week development cycle like Mozilla, but they only have one
> six-week beta delay between Canary and release. So Chrome can ship a new
> feature in 6-12 weeks compared to Mozilla's 12-18 weeks.
Having three pre-release populations on two branches instead of three
pre-release
> We could come to the compromise of running them on m-c, m-a, m-b and m-r.
> Only this would help a lot since most of the load comes from m-i and try. We
> could make it a non-by-default platform on try.
This strategy would prevent any holes in our coverage, but accomplish the goal
of reducing
To hopefully close the loop on this, 860438 – Remove custom cx-stack munging
scattered around Gecko was backed out to resolve the crash in 863646 – Start up
crash in nsContentUtils::GetCurrentJSContext in profile manager (-p ,
-profilemanager, always ask at startup).
That leaves the crash regre
Johnathan and I also spoke about this last week, and we were going to sync up
with Gavin to work out details and find an owner for channel-specific
preference enables/disables. We'd only discussed having Nightly-only, up to
Aurora, and up to Beta. Up to early beta is a good addition.
Let me set
we'd need to prevent this from happening.
>
> Ah, good point. Didn't think of that initially. That would actually argue in
> favor of target milestone being the permanent entity and the status flags
> only existing within the release --> beta --> aurora --> nigh
> * The need for a particular team to track the concept of "We would
> like to get this fixed in this Firefox release." Some teams I've
> worked with have considered using the target milestone field here,
> but that collides with the trunk management definition, which often
> causes content
Can you clarify the main motivation behind using a subrepo over a Tier 1 dev
branch like m-i or services-central? Mimicking what we already do elsewhere
would have less process/infra change overhead, and my intuition tells me that
per-checkin builds/tests could be configured specifically for tha
We should at least move your suggested removals to the bottom of the new bug
page, given their lower bug filing volume. For instance, SeaMonkey had ~75 bugs
filed in the last month while Firefox for Android (lower on the list) had
closer to 500.
-Alex
On Mar 18, 2013, at 2:14 PM, Jason Smith
Can we programmatically verify that we're unaffected? Does this just require a
local Win7 build, or do we need to loop RelEng in?
-Alex
On Feb 27, 2013, at 7:10 AM, Benoit Jacob wrote:
> 2013/2/27 Gian-Carlo Pascutto
>
>> Hi all,
>>
>> just a heads up: the Windows 7 platform update that's b
[x-post to dev.planning and dev.platform]
In relation to release notes process, we've gotten a couple of pieces of
feedback in recent memory:
1) It's not clear how to mark something as a release notes candidate (some have
used the relnote keyword in the past)
2) It's not clear whether something
Just to echo what David said, PGO builds cause amorphous stability and even
graphics/layout bugs (for instance bug 831296) that we're forced to investigate
in engineering and QA for a specific release, even though the issues aren't
typically caused by actual in-product regressions. Additionally,
> - For the above reasons (short time, relatively small number of users), I am
> not too concerned that large numbers of web developers are going to have been
> detecting our "Tablet" string, or that this will lead to frustration at our
> "ever-changing" UA.
Agreed that major fallout is unlikel
mplete sense from the quality perspective
to match that specific configuration.
Discussions are ongoing as to whether disabling the test is our best path
forward here, given engineering opposition to disabling PGO.
-Alex
On Nov 13, 2012, at 10:07 PM, Taras Glek wrote:
> On 11/13/2012 3:53
should match
what our users work with on a daily basis thus preventing an unnecessary time
sink for our devs.
Hopefully those involved in the Snappy initiative can help us come to a final
decision here.
-Alex
On Nov 13, 2012, at 6:54 AM, Dao wrote:
> On 13.11.2012 00:47, Alex Keybl wr
Bug 799295 [1], the driver for this thread, is still an open issue for FF18
(shipping in 6 weeks). The JS team's recommendation remains to disable PGO on
Linux. According to Taras, the major benefits of PGO on Linux are for a
"starry-eyed-future". Given
> almost nobody uses Mozilla Firefox buil
alternative which would be ready in time.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=798491
>
> On Tue, Oct 30, 2012 at 4:31 PM, Dave Townsend wrote:
>> On 10/30/12 12:08, Alex Keybl wrote:
>>>>
>>>> We have explored various
>>>> techn
> We have explored various
> techniques to lower the overhead of a compartment, but unfortunately those
> fixes that would help at all are either too risky for or cannot be
> completed in time for Gecko 18. We have decided instead to consolidate all
> JSMs and JS components into a single compartme
, Kyle Huey wrote:
> On Tue, Sep 4, 2012 at 12:34 PM, Alex Keybl wrote:
> I'd like to provide everybody with an update about this plan. "B2G v1"
> platform work is continuing on mozilla-central as we speak, and therefore
> will not be a part of FF17 (currentl
will not be the longterm support
branch for B2G v1.
-Alex
On Aug 1, 2012, at 2:47 PM, Alex Keybl wrote:
> Release drivers for the B2G project recently got together to discuss
> committing to a specific Gecko version for B2G v1**, and we've all agreed on
> Gecko 17 making the most se
Nick in RelEng found https://bugzilla.mozilla.org/show_bug.cgi?id=734975 - the
availability of a tar.bz2 instead of a dmg/installer was intentional.
-Alex
On Sep 2, 2012, at 2:45 PM, Alex Keybl wrote:
> Hi Allen,
>
> I'm following up with Release Engineering about the avail
Hi Allen,
I'm following up with Release Engineering about the availability of the 15.0
xulrunner installer. For issues you're seeing running XULRunner itself, please
file a bug against Toolkit/XULRunner and nominate for Firefox 15/16 tracking -
we'll try to find somebody to help take a look. If
Quick ping to platform devs - do you all know of any particularly risky changes
going in over the next 6 weeks that carry the possibility of regression,
especially to B2G? Thanks in advance!
-Alex
___
dev-platform mailing list
dev-platform@lists.mozill
-specific changes on FF17 only.
The goal here is to keep B2G devs and QA focused only on the shipping 17 branch
wherever possible, as long as it poses little to no risk to future
desktop/mobile Firefox versions.
-Alex
On Aug 1, 2012, at 6:43 PM, Blair McBride wrote:
> On 2/08/2012 9:47 a.m.
mobile change that
negatively impacts B2G builds in a significant way will be backed out (and vice
versa).
Please let us know if you have any questions, or if anything could use further
clarification. Please also see [2] for a similar conversation happening around
Gaia v1 convergence if interested
any of the 32-bit binary/library slices are ever loaded on a 64-bit machine
(could definitely be wrong though).
-Alex
On Jul 30, 2012, at 1:29 AM, Mike Hommey wrote:
> On Mon, Jul 30, 2012 at 09:23:43AM +0100, Mark Banner wrote:
>> On 19/07/2012 21:38, Alex Keybl wrote:
>>>
Thanks to everyone who joined this discussion. We've now moved forward with
disabling OS X 10.5 support for FF17 in [1]. Per discussion here, we will
strive to leave code in place through the 17 cycle, but if it becomes difficult
to accomplish necessary work, we may end up breaking things to adv
30 matches
Mail list logo
