On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey m...@glandium.org wrote:
On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote:
Debian doesn't keep Iceweasel up to date in oldstable anyway.
Actually, I'm providing backports for oldstable. 24 is as far as I'm
ready to go to support
On Fri, Aug 02, 2013 at 08:27:02AM -0400, Ehsan Akhgari wrote:
On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey m...@glandium.org wrote:
On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote:
Debian doesn't keep Iceweasel up to date in oldstable anyway.
Actually, I'm providing
On Fri, Aug 2, 2013 at 2:58 PM, Mike Hommey m...@glandium.org wrote:
Upgrading minimum compiler requirements doesn't imply backporting those
requirements to Aurora where ESR24 is right now. Are you opposed to
updating our minimum supported gcc to 4.7 on trunk when Firefox OS is
ready
to
On Fri, Aug 2, 2013 at 1:36 AM, Joshua Cranmer pidgeo...@gmail.comwrote:
On 8/1/2013 5:46 PM, Brian Smith wrote:
FWIW, I talked about this issue with a group of ~10 Mozillians here in
Berlin and all of them (AFAICT) were in favor of requiring that the latest
versions of GCC be used, or
On 2013-08-02 4:49 PM, Brian Smith wrote:
That sounds reasonable to me. So, based on that then, let's get back to my
original question that motivated the discussion of the policy: If we add
std::move, std::forward, and std::unique_ptr to STLPort for Android and
B2G, can we start using std::move,
On 2013-08-02 4:39 PM, Brian Smith wrote:
On Fri, Aug 2, 2013 at 2:58 PM, Mike Hommey m...@glandium.org
mailto:m...@glandium.org wrote:
Upgrading minimum compiler requirements doesn't imply backporting
those
requirements to Aurora where ESR24 is right now. Are you opposed to
Brian Smith wrote:
We have mozilla-build for Windows. From what you say, it sounds like we should
have mozilla-build for Linux too that would include a pre-built GCC or Clang or
whatever we choose as *the* toolchain for desktop Linux.
mozilla-build doesn't include a compiler or SDK. At one
On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
This adds too much risk of security patches failing to backport from
mozilla-central to ESR 24. Remember that one of the design goals of ESR
is to minimize the amount of effort we put into it so that ESR doesn't
On 8/2/13 8:14 PM, Brian Smith wrote:
The risk that any developer would need to
waste time on ESR just to support a product that isn't even Firefox on a
platform that virtually nobody uses, and the risk that comes with making
any changes to the security fix that you are trying to backport.
I
On Sat, Aug 3, 2013 at 12:50 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
On 2013-08-02 4:49 PM, Brian Smith wrote:
That sounds reasonable to me. So, based on that then, let's get back to my
original question that motivated the discussion of the policy: If we add
std::move, std::forward,
On Sat, Aug 03, 2013 at 02:14:10AM +0200, Brian Smith wrote:
On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
This adds too much risk of security patches failing to backport from
mozilla-central to ESR 24. Remember that one of the design goals of ESR
is to
On 07/31/2013 01:25 AM, Brian Smith wrote:
Anyway, it would be easier to swallow the dependency on MFBT if it wasn't
so large (over 100 files now), if it tried to be (just) a polyfill for
missing standard library features, and if it could easily be used
independently of the Gecko build system.
On Wed, Jul 31, 2013 at 2:19 PM, Mike Hommey m...@glandium.org wrote:
On Wed, Jul 31, 2013 at 01:06:27PM +0200, Brian Smith wrote:
On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey m...@glandium.org wrote:
I strongly oppose to any requirement that would make ESR+2 (ESR31)
not build on the
On Wed, Jul 31, 2013 at 8:09 PM, Joshua Cranmer pidgeo...@gmail.comwrote:
More generally, nobody should be reasonably expected to write code that
builds with any combination that isn't used on mozilla-central's TBPL. So,
(clang, MSVC) is not really something to consider, for example.
On 8/1/2013 5:46 PM, Brian Smith wrote:
FWIW, I talked about this issue with a group of ~10 Mozillians here in
Berlin and all of them (AFAICT) were in favor of requiring that the latest
versions of GCC be used, or even dropping GCC support completely in favor
of clang, if it means that we can
On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote:
Debian doesn't keep Iceweasel up to date in oldstable anyway.
Actually, I'm providing backports for oldstable. 24 is as far as I'm
ready to go to support oldstable until its actual EOL next year. Which
is why i want ESR24 to remain
On Wed, Jul 31, 2013 at 6:53 AM, Joshua Cranmer pidgeo...@gmail.comwrote:
On 7/30/2013 10:39 PM, Brian Smith wrote:
Yes: Then we can use std::unique_ptr in parts of Gecko that are intended
to
be buildable without MFBT (see below).
One thing I want to point out is that, while compiler
On Wed, Jul 31, 2013 at 10:25:15AM +0200, Brian Smith wrote:
We should be more aggressive in requiring newer compiler versions
whenever practical, and we should choose to support as few
compiler/library combinations as we can get away with. That way we can
use as many C++11/14 features (not
On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey m...@glandium.org wrote:
I strongly oppose to any requirement that would make ESR+2 (ESR31) not
build on the current Debian stable (gcc 4.7) and make ESR+1 (ESR24) not
build on the old Debian stable (gcc 4.4). We're not going to change the
On Wed, Jul 31, 2013 at 01:06:27PM +0200, Brian Smith wrote:
On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey m...@glandium.org wrote:
I strongly oppose to any requirement that would make ESR+2 (ESR31)
not build on the current Debian stable (gcc 4.7) and make ESR+1
(ESR24) not build on the
On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith br...@briansmith.org wrote:
On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey m...@glandium.org wrote:
Note that STL is another story. We're not using libstdc++ that comes
with the compiler on android and b2g. We use STLport instead, and STLport
On Tue, Jul 30, 2013 at 10:50:39PM -0400, Ehsan Akhgari wrote:
On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith br...@briansmith.org
wrote:
On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey m...@glandium.org
wrote:
Note that STL is another story. We're not using libstdc++ that
comes with
On Wed, Jul 31, 2013 at 4:50 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith br...@briansmith.orgwrote:
But, shouldn't we just name these std::move and std::forward and use these
implementations only when we're using STLPort? I know we're not
On 7/30/2013 10:39 PM, Brian Smith wrote:
On Wed, Jul 31, 2013 at 4:50 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith br...@briansmith.orgwrote:
But, shouldn't we just name these std::move and std::forward and use these
implementations only when
24 matches
Mail list logo
