On Fri, Aug 2, 2013 at 9:11 PM, Brian Smith wrote:
> On Sat, Aug 3, 2013 at 12:50 AM, Ehsan Akhgari wrote:
>
>> 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 th
On Fri, Aug 2, 2013 at 11:02 PM, Mike Hommey wrote:
> On Sat, Aug 03, 2013 at 02:14:10AM +0200, Brian Smith wrote:
> > On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari >wrote:
> >
> > > This adds too much risk of security patches failing to backport from
> > >
> > >> mozilla-central to ESR 24. Rem
On Sat, Aug 03, 2013 at 02:14:10AM +0200, Brian Smith wrote:
> On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari wrote:
>
> > 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 a
On Sat, Aug 3, 2013 at 12:50 AM, Ehsan Akhgari wrote:
> 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_
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 fe
On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari wrote:
> 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
>> slow down real Fire
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 po
On 2013-08-02 4:39 PM, Brian Smith wrote:
On Fri, Aug 2, 2013 at 2:58 PM, Mike Hommey 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
> updating o
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 Fri, Aug 2, 2013 at 1:36 AM, Joshua Cranmer 🐧 wrote:
> 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 G
On Fri, Aug 2, 2013 at 2:58 PM, Mike Hommey 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 switch?
On Fri, Aug 02, 2013 at 08:27:02AM -0400, Ehsan Akhgari wrote:
> On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey 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
On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey 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 oldstable until it
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 co
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 use
On 7/31/2013 4:06 AM, Brian Smith wrote:
On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey 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
On Wed, Jul 31, 2013 at 8:09 PM, Joshua Cranmer 🐧 wrote:
>
> 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.
>>
>
> clang + MSVC
On Wed, Jul 31, 2013 at 2:19 PM, Mike Hommey 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 wrote:
> >
> > > I strongly oppose to any requirement that would make ESR+2 (ESR31)
> > > not build on the current Debian stable (g
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 syst
ction
compilers until 2014 at the earliest.
Basically, I'm proposing that we add std::unique_ptr, std::move,
std::forward, and some nulllptr polyfill to STLPort with the intention that
we can assume these features work. That is, if some (compiler, standard
library) combination doesn't ha
On Wed, Jul 31, 2013 at 01:06:27PM +0200, Brian Smith wrote:
> On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey 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
On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey 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
> requirements for the
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
issue, but it would not be rolled out to production
> compilers until 2014 at the earliest.
>
Basically, I'm proposing that we add std::unique_ptr, std::move,
std::forward, and some nulllptr polyfill to STLPort with the intention that
we can assume these features work. That is, if some
On 7/30/2013 10:39 PM, Brian Smith wrote:
On Wed, Jul 31, 2013 at 4:50 AM, Ehsan Akhgari wrote:
On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith wrote:
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 suppos
On Wed, Jul 31, 2013 at 4:50 AM, Ehsan Akhgari wrote:
> On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith wrote:
>
>> 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 supposed
>> to
>> add stuff to the std:: na
On Tue, Jul 30, 2013 at 10:50:39PM -0400, Ehsan Akhgari wrote:
> On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith
> wrote:
>
> > On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey
> > wrote:
> >
> > > Note that STL is another story. We're not using libstdc++ that
> > > comes with the compiler on android a
On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith wrote:
> On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey 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
> > has, afaik, no support for C++11
On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey 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
> has, afaik, no support for C++11 STL types. So, while we can now fix
> nsAutoPtr to use move sem
29 matches
Mail list logo