On Fri, Oct 31, 2014 at 7:21 PM, Jonas Sicking wrote:
> Which use-case do you need "async" for?
>
> The "Adjust the scroll position down by 10 pixels atomically with the
> next reflow since I just added a 10 pixel element at the top of the
> page" use case could be supported using
>
> element.scr
Just my 2c:
On Fri, Oct 31, 2014 at 6:48 AM, Gregory Szorc wrote:
> a) Landing code to inbound, fx-team, aurora, etc
> b) Pushing to Try
>
I do (b) with |git push-to-try|. It's flakey sometimes, and I've always
been somewhat superstitious about using it to actually push to inbound - so
I tend t
Thanks for sending this email! Some responses below..
On 31/10/2014, 1:48, Gregory Szorc wrote:
a) Landing code to inbound, fx-team, aurora, etc
b) Pushing to Try
My workflow involves exporting patches from git as flat text files and
then using qimport/push from a single hg pseudo-unified rep
On 2014-10-31 1:48 AM, Gregory Szorc wrote:
I'm trying to learn more about how the people who use Git for
Firefox/Gecko development manage interacting with repositories that have
their canonical home in Mercurial (mozilla-central, Try, etc). I'm doing
this to ensure the replacement Try architectu
On 30/10/2014, 19:02, Jonas Sicking wrote:
Couldn't we simply change the defined behavior of element.scrollBy({
top: 50, behavior: "smooth" }) such that it sends the delta
coordinates to the composition thread, and adds the current scroll
position there instead of on the main thread?
FYI we fil
I use git day to day. I use hg primarily for landing code and "hg bzepxort".
On Fri, Oct 31, 2014 at 1:48 AM, Gregory Szorc wrote:
> I
> I'm interested in knowing how people feel about these "hidden hg" tools.
> Is going through a hidden, local hg bridge seamless? Satisfactory? Barely
> tolerabl
- Original Message -
> a) Landing code to inbound, fx-team, aurora, etc
> b) Pushing to Try
I have a script that handles pushing a range of commits to the repository of my
choice. This script is essentially:
for id in ${range}; do
git show --unified=3 --id=${id} --format="${stuff}"
On Fri, Oct 31, 2014 at 3:21 PM, Ehsan Akhgari wrote:
> In the current world, there are enough hg and git users that I think Mozilla
> should consider supporting both as first class citizens. The proper way to
> do that would be deploying a git push server which eliminates the need to do
> anythi
On 2014-10-31 10:43 AM, Dirkjan Ochtman wrote:
On Fri, Oct 31, 2014 at 3:21 PM, Ehsan Akhgari wrote:
In the current world, there are enough hg and git users that I think Mozilla
should consider supporting both as first class citizens. The proper way to
do that would be deploying a git push ser
I cannot live without moz-git-tools. Let me explain.
> a) Landing code to inbound, fx-team, aurora, etc
I use "git bz attach" to attach patches to bugzilla and use checkin-needed.
> b) Pushing to Try
I use "git push-to-try". This command needs a local hg repo, so I need to
update it every time w
On 10/31/2014 06:48 AM, Gregory Szorc wrote:
a) Landing code to inbound, fx-team, aurora, etc
> b) Pushing to Try
From what I recall, the default moz-git-tools way is to have a clone for
each repository. This implies that you need one hg work directory per
target branch.
I changed the moz-
Let me try to answer at a high level first. I use git for all of my
workflows and
when I collaborate with other people on my team, we use git and github.
See, for instance:
https://github.com/unicorn-wg/gecko-dev/tree/multistream_rebase
So, I primarily need to engage with hg for the following ta
Before I get to complaining (which I love to do), first let me say thank
you for all the amazing hard work you've put into improving the
developer experience! The improvements between when I started almost 4
years ago and now are nothing short of incredible.
I use git exclusively. The only time I
On 10/31/14 7:21 AM, Ehsan Akhgari wrote:
On 2014-10-31 1:48 AM, Gregory Szorc wrote:
> Short of
switching the canonical repositories to Git, what do you need to be more
productive?
I actually don't advocate switching our canonical repos to Git in the
short term (I strongly believe that is a
On 10/31/14 9:51 AM, Gregory Szorc wrote:
All problems in computer science can be solved by another level of
indirection. The problem here is that Git users need to push to the
canonical Mercurial repositories (inbound, try, etc). You will be
hearing me say this a lot in the months ahead, but "Au
On Thu, Oct 30, 2014 at 10:48 PM, Gregory Szorc wrote:
> I'm trying to learn more about how the people who use Git for Firefox/Gecko
> development manage interacting with repositories that have their canonical
> home in Mercurial (mozilla-central, Try, etc). I'm doing this to ensure the
> replacem
On 10/30/14 10:48 PM, Gregory Szorc wrote:
I'm trying to learn more about how the people who use Git for
Firefox/Gecko development manage interacting with repositories that have
their canonical home in Mercurial (mozilla-central, Try, etc). I'm doing
this to ensure the replacement Try architectur
On 2014-10-31 12:51 PM, Gregory Szorc wrote:
As has been said on this list before, switching canonical to Git just
isn't going to happen. Valid reasons have been given before. But here's
a new one: we don't need to.
I think it's fair to say that the pain point for Firefox Git developers
*today*
As of next week I intend to turn will-change on by default on all
platform. It has been developed behind the
layout.css.will-change.enabled;true preference since Firefox 31 and
has been enabled for certified FirefoxOS apps since 1.4[1] [2]. Blink
has already shipped this [3], IE lists the feature a
Generally speaking, I use git for everything except pushing to inbound and try,
and I use moz-git-tools to intermediate my interaction with hg.
> a) Landing code to inbound, fx-team, aurora, etc
For this, I keep around hg repos for the repos I care about, which is m-c and
inbound right now, the
On Friday 2014-10-31 14:17 -0400, Benoit Girard wrote:
> As of next week I intend to turn will-change on by default on all
> platform. It has been developed behind the
> layout.css.will-change.enabled;true preference since Firefox 31 and
> has been enabled for certified FirefoxOS apps since 1.4[1]
Yes, it's implemented in part 1-4 of my patch queue in bug 961871.
Here's how it works -but is subject to change at any time-:
- The following are all in untransformed CSS pixel unit. This makes
the implementation *much* simpler[1] and more predicable for web
authors[2].
- We look at the scrollpor
Can we make sure to log something to the web console when we choose to
dishonor will-change? That will help web developers to be able to
reason about why will-change doesn't give them the performance benefits
that they expect.
On 2014-10-31 3:36 PM, Benoit Girard wrote:
Yes, it's implemented
That's a good idea. Filed bug 1092320.
On Fri, Oct 31, 2014 at 3:48 PM, Ehsan Akhgari wrote:
> Can we make sure to log something to the web console when we choose to
> dishonor will-change? That will help web developers to be able to reason
> about why will-change doesn't give them the performan
On 30/10/14 22:48, Gregory Szorc wrote:
> I'm trying to learn more about how the people who use Git for
> Firefox/Gecko development manage interacting with repositories that have
> their canonical home in Mercurial (mozilla-central, Try, etc). I'm doing
> this to ensure the replacement Try architec
On 10/31/2014 08:00 AM, Nicolas B. Pierron wrote:
> On 10/31/2014 06:48 AM, Gregory Szorc wrote:
>
>> I'm interested in knowing how people feel about these "hidden hg"
>> tools. Is
>> going through a hidden, local hg bridge seamless? Satisfactory? Barely
>> tolerable? A horrible pain point? (I noti
On Fri, Oct 31, 2014 at 2:24 PM, Steve Fink wrote:
> On 10/31/2014 08:00 AM, Nicolas B. Pierron wrote:
>> On 10/31/2014 06:48 AM, Gregory Szorc wrote:
>>
>>> I'm interested in knowing how people feel about these "hidden hg"
>>> tools. Is
>>> going through a hidden, local hg bridge seamless? Satisf
On 10/31/2014 07:21 AM, Ehsan Akhgari wrote:
> And my workflow for landing code is like this:
>
> $ cd /path/to/src # this is a git repo
> $ git hg commit_id > /tmp/x
> $ cd /path/to/inbound # this is an hg repo
> $ hg pull -u
> $ hg qim /tmp/x && hg qpush && hg qfi -a && hg push
Sorry for the irr
> From: "Ehsan Akhgari"
> To: "Gregory Szorc" , "dev-platform"
>
> Cc: "Nicolas Pierron"
> Sent: Friday, October 31, 2014 10:21:09 AM
> Subject: Re: Git -> Hg workflows?
>
> In the current world, there are enough hg and git users that I think
> Mozilla should consider supporting both as first
On 10/31/2014 11:03 AM, Ehsan Akhgari wrote:
> On 2014-10-31 12:51 PM, Gregory Szorc wrote: All problems in computer
> science can be solved by another level of
>> indirection. The problem here is that Git users need to push to the
>> canonical Mercurial repositories (inbound, try, etc). You will b
Ehsan Akhgari wrote:
> The reason I and others go through this pain right now to avoid having
> to use hg more is increased productivity. [...]
For the record (and I'm currently a user of the git+github+moz-git-tools
cohort, so I'm me-too'ing here), I've occasionally tried the new hg tools,
sin
On Thu, 30 Oct 2014, Gregory Szorc wrote:
Hey ho,
Let me give you my views on this as a relative newcomer in the source tree. I
started at Mozilla early 2014 and as an old open source contributor to and
maintainer of dozens of projects for many years I am deeply accustomed to
using git and th
32 matches
Mail list logo
