Re: Proposal for an inbound2 branch

Ryan VanderMeulen wrote: My proposal: -Create an inbound2 branch identically configured to mozilla-inbound. -Under normal circumstances (i.e. m-i open), inbound2 will be CLOSED. -In the event of a long tree closure, the last green changeset from m-i will be merged to inbound2 and inbound2 will

Re: Proposal for an inbound2 branch

On 2013-05-02 5:46 AM, Neil wrote: Ryan VanderMeulen wrote: My proposal: -Create an inbound2 branch identically configured to mozilla-inbound. -Under normal circumstances (i.e. m-i open), inbound2 will be CLOSED. -In the event of a long tree closure, the last green changeset from m-i will be me

Re: Proposal for an inbound2 branch

Ehsan Akhgari wrote: Multiheaded repos are evil. They're very hard to deal with, and I don't think that buildbot can deal with them properly. Also, they cannot be represented in git, which means that they will break the git mirror. Why does mozilla-inbound need a git mirror? -- Warning: M

Re: Proposal for an inbound2 branch

On Thu, May 02, 2013 at 09:21:57AM -0400, Ehsan Akhgari wrote: > Also, they cannot be represented in git I doubt this is true. The bridging tools may well not support it, but there's nothing structural about multiple-head repository that would prevent them to be mirrored in git. Mike

Re: Proposal for an inbound2 branch

On 5/2/2013 6:21 AM, Ehsan Akhgari wrote: On 2013-05-02 5:46 AM, Neil wrote: Why do we need a separate repo? Can we not simply close the broken head and start again at the last green changeset? Multiheaded repos are evil. They're very hard to deal with, and I don't think that buildbot can dea

Re: Proposal for an inbound2 branch

On 5/2/13 10:09 AM, Matt Brubeck wrote: The suggested workflow with inbound2 would lead to almost-identical multi-headed repos in developers' local clones anyway. Only temporary ones, until inbound and inbound2 merge. -Boris ___ dev-platform mailing

smartmake-like functionality has landed in mach

Hello dev-platform, If you don't use mach, this message does not concern you. If you use mach, in particular |mach build DIRECTORY|, keep reading. Bug 677452 landed "smartmake-like" functionality into mach, which I have dubbed dumbmake. smartmake (and dumbmake) [1] maintains a list of dependen

Mac OSX 10.7+ lion style scroll bars landed on m-i

Hi, This is a quick heads up that Mac OSX 10.7+ lion style scroll bars (bug 636564) have landed on mozilla-inbound with https://hg.mozilla.org/integration/mozilla-inbound/rev/0c513ba74137. Once merged to mozilla-central expect them to appear in our nightlies. If you have any feedback or run

Re: Mac OSX 10.7+ lion style scroll bars landed on m-i

Hooray! Thanks for all the hard work, Stephen. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq

Re: smartmake-like functionality has landed in mach

Hi, what exactly does this do? If I mach build chrome does it build the things I need to get everything in chrome built, or does it build everything that depends on the chrome dir, or both? Axel On 5/2/13 7:03 PM, Nick Alexander wrote: Hello dev-platform, If you don't use mach, this messag

Re: smartmake-like functionality has landed in mach

According to http://mxr.mozilla.org/mozilla-central/source/build/dumbmake-dependencies#8, it is equivalent to the following: ./mach build -X chrome xpcom toolkit/library Nothing more, nothing less. Cheers, Josh On 05/02/2013 10:58 PM, Axel Hecht wrote: Hi, what exactly does this do? If I

Re: smartmake-like functionality has landed in mach

On 13-05-02 3:09 PM, Josh Matthews wrote: According to http://mxr.mozilla.org/mozilla-central/source/build/dumbmake-dependencies#8, it is equivalent to the following: ./mach build -X chrome xpcom toolkit/library That's correct. Or, if you're not a mach user, it translates to make -f client.m

Re: Storage in Gecko

- Original Message - > Great post, Taras! > > Per IRC conversations, we'd like to move subsequent discussion of > actions into a meeting so we can more quickly arrive at a resolution. > > Please meet in Gregory Szorc's Vidyo Room at 1400 PDT Tuesday, April > 30. > That's 2200 UTC. Apolo

Re: smartmake-like functionality has landed in mach

On 5/2/2013 3:45 PM, Nick Alexander wrote: On 13-05-02 3:09 PM, Josh Matthews wrote: According to http://mxr.mozilla.org/mozilla-central/source/build/dumbmake-dependencies#8, it is equivalent to the following: ./mach build -X chrome xpcom toolkit/library That's correct. Or, if you're not a

Re: smartmake-like functionality has landed in mach

On 13-05-02 4:23 PM, Dave Townsend wrote: On 5/2/2013 3:45 PM, Nick Alexander wrote: On 13-05-02 3:09 PM, Josh Matthews wrote: According to http://mxr.mozilla.org/mozilla-central/source/build/dumbmake-dependencies#8, it is equivalent to the following: ./mach build -X chrome xpcom toolkit/lib

Re: Storage in Gecko

On 5/2/2013 4:13 PM, Lawrence Mandel wrote: - Original Message - Great post, Taras! Per IRC conversations, we'd like to move subsequent discussion of actions into a meeting so we can more quickly arrive at a resolution. Please meet in Gregory Szorc's Vidyo Room at 1400 PDT Tuesday, Ap

Re: Storage in Gecko

On Thu, May 2, 2013 at 4:36 PM, Gregory Szorc wrote: > We seemed to converge on a (presumably C++-based) storage service that has > named branches/buckets with specific consistency, flushing, etc guarantees. > Clients would obtain a handle on a "branch," and perform basic I/O > operations, includ

Re: Storage in Gecko

On 5/2/2013 4:40 PM, Kyle Huey wrote: On Thu, May 2, 2013 at 4:36 PM, Gregory Szorc > wrote: We seemed to converge on a (presumably C++-based) storage service that has named branches/buckets with specific consistency, flushing, etc guarantees. Clients woul

Re: smartmake-like functionality has landed in mach

On 05/03/2013 12:35 AM, Nick Alexander wrote: On 13-05-02 4:23 PM, Dave Townsend wrote: On 5/2/2013 3:45 PM, Nick Alexander wrote: On 13-05-02 3:09 PM, Josh Matthews wrote: According to http://mxr.mozilla.org/mozilla-central/source/build/dumbmake-dependencies#8, it is equivalent to the foll

Re: Storage in Gecko

Whatever you do, please, please, please make sure that everything is worker-friendly. If we can't write (or at least read) contents to that Key-Value store from a worker, we will need to reimplement everything in a few months. Cheers, David - Original Message - From: "Gregory Szorc" T

Re: Mac OSX 10.7+ lion style scroll bars landed on m-i

On Thu, May 2, 2013 at 9:23 PM, Stephen Pohl wrote: > This is a quick heads up that Mac OSX 10.7+ lion style scroll bars (bug > 636564) have landed on mozilla-inbound with > https://hg.mozilla.org/integration/mozilla-inbound/rev/0c513ba74137. Once > merged to mozilla-central expect them to appear

Re: Proposal for an inbound2 branch

On 2013-05-02 9:40 AM, Mike Hommey wrote: On Thu, May 02, 2013 at 09:21:57AM -0400, Ehsan Akhgari wrote: Also, they cannot be represented in git I doubt this is true. The bridging tools may well not support it, but there's nothing structural about multiple-head repository that would prevent th

Re: Proposal for an inbound2 branch

On 2013-05-02 9:29 AM, Neil wrote: Ehsan Akhgari wrote: Multiheaded repos are evil. They're very hard to deal with, and I don't think that buildbot can deal with them properly. Also, they cannot be represented in git, which means that they will break the git mirror. Why does mozilla-inbound

Re: Proposal for an inbound2 branch

On 2013-05-02 10:58 AM, Boris Zbarsky wrote: On 5/2/13 10:09 AM, Matt Brubeck wrote: The suggested workflow with inbound2 would lead to almost-identical multi-headed repos in developers' local clones anyway. Only temporary ones, until inbound and inbound2 merge. Using multiple mozilla reposi

Re: Storage in Gecko

On 2013-05-02 7:36 PM, Gregory Szorc wrote: On 5/2/2013 4:13 PM, Lawrence Mandel wrote: - Original Message - Great post, Taras! Per IRC conversations, we'd like to move subsequent discussion of actions into a meeting so we can more quickly arrive at a resolution. Please meet in Grego

Re: Proposal for an inbound2 branch

On Fri, May 03, 2013 at 02:43:36AM -0400, Ehsan Akhgari wrote: > On 2013-05-02 9:40 AM, Mike Hommey wrote: > >On Thu, May 02, 2013 at 09:21:57AM -0400, Ehsan Akhgari wrote: > >>Also, they cannot be represented in git > > > >I doubt this is true. The bridging tools may well not support it, but > >th

Re: smartmake-like functionality has landed in mach

On 2013-05-02 7:23 PM, Dave Townsend wrote: On 5/2/2013 3:45 PM, Nick Alexander wrote: On 13-05-02 3:09 PM, Josh Matthews wrote: According to http://mxr.mozilla.org/mozilla-central/source/build/dumbmake-dependencies#8, it is equivalent to the following: ./mach build -X chrome xpcom toolkit/l

Re: PHOTO FACIAL

Newlookdayspaandlaser provides the best treatment for laser skin rejuvenation in herndon. We customize skin rejuvenation program as per the requirement, skin type and the condition that a particular client is facing.Skin Rejuvenation Treatment at Herndon Virginia for Skin resurfacing and more

Re: Proposal for an inbound2 branch

On 2013-05-03 2:52 AM, Mike Hommey wrote: On Fri, May 03, 2013 at 02:43:36AM -0400, Ehsan Akhgari wrote: On 2013-05-02 9:40 AM, Mike Hommey wrote: On Thu, May 02, 2013 at 09:21:57AM -0400, Ehsan Akhgari wrote: Also, they cannot be represented in git I doubt this is true. The bridging tools m