Asa Dotzler wrote:
Testing the only Firefox platform that isn't on the above list? Wouldn't
it be smarter to test on Windows 7 or some combination of Windows
machines where almost all of our users are?
If we've got the resources for it, sure.
___
On Wed, Jul 10, 2013 at 3:26 PM, Justin Lebar justin.le...@gmail.comwrote:
If I can propose something that's perhaps different:
1) Write software to figure out who's slow with reviews.
2) We talk to those people.
We've done this before too.
But we should just do it again --- the definition
jmaher wrote:
Can you explain what would need to be done for Android to get into
this mode? It might be difficult to make this work with our current
solution for automated tests.
This proposal is just to affect how content is rendered, by setting that
pref. If it's a XUL UI it should render
We can't have a rigid rule about 24 hours. Someone requesting a review from
me on Thursday PDT probably won't get a response until Monday if neither of
us work during the weekend.
But I think it's reasonable to expect developers to process outstanding
review requests (and needinfos) at least once
On Wed, Jul 10, 2013 at 2:48 PM, Jeff Walden jwalden+...@mit.edu wrote:
Reviewer-side: I've lately tried to minimize my review turnaround time
such that I get things done, roughly FIFO, before I get a review-nag mail.
I can approximately do that, while keeping up with most of my coding.
Gijs Kruitbosch wrote:
On 02/07/13 17:34 , Paul Rouget wrote:
The Firefox OS Simulator is a XulRunner instance run
from Firefox. Two processes, two windows, two different
version of gecko.
It would be very useful if we could display the simulator
as part of Firefox. Inside a tab.
With
On Thu, Jul 11, 2013 at 5:06 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, Jul 10, 2013 at 6:09 AM, smaug sm...@welho.com wrote:
One thing, which has often brought up, would be to have other automatic
coding style checker than just Ms2ger.
See
On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden jwalden+...@mit.edu wrote:
Establishing one-day turnaround time on reviews, or on requests, would
require a lot more polling on my review queue.
You poll your review queue? Like, by visiting your Bugzilla
dashboard, or something like that? That's
On 11/07/13 12:09 , Nicholas Nethercote wrote:
On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden jwalden+...@mit.edu wrote:
Establishing one-day turnaround time on reviews, or on requests, would require
a lot more polling on my review queue.
You poll your review queue? Like, by visiting your
On 09/07/13 21:29, Chris Peterson wrote:
I've seen people change their Bugzilla name to include a comment about
being on PTO. We should promote this practice. We could also add a
Bugzilla feature (just a simple check box or a PTO date range) that
appends some vacation message to your Bugzilla
On 10/07/13 23:14, Taras Glek wrote:
I tried to capture feedback from this thread in
https://wiki.mozilla.org/Code_Review
I just did a pass over that page to highlight the key points.
Gerv
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On Thu, Jul 11, 2013 at 10:49 AM, Chris Peterson cpeter...@mozilla.com wrote:
Can you describe your patch queue-like workflow using git? git rebase -i
lets you reorder commits, but how do you quickly do the equivalent of hg
qpopping and qpushing a bunch of commits?
What I normally do is make
On 2013-05-18, at 06:09 , David Rajchenbach-Teller dtel...@mozilla.com wrote:
Hi everyone,
As part of the ongoing effort to make (Chrome) Workers useful for
platform refactorings, we have been working on a lightweight module
loader for workers (bug 872421). This loader implements a
One thing I've been thinking about is /why/ people are slow at reviews.
Someone who usually has a long review queue has told me that he hates
reviewing code. I realized that we don't really have a place at Mozilla for
experienced hackers who don't want to do reviews. Should we? Could we do
On 7/11/13 7:59 AM, Gervase Markham wrote:
Hey, if we had a PTO app that tracked all absences, we could integrate
with it...
sigh
Just in case you were talking about the moco PTO app, it doesn't track
absences for non-MoCo employees, and even for employees it does not
track non-PTO absences
On 2013-05-29, at 18:58 , Justin Dolske dol...@mozilla.com wrote:
On 5/29/13 3:09 PM, Ehsan Akhgari wrote:
Typically when you use the terminal to open an application on Mac, the
application is opened in the background.
Mmm, indeed. Someone told me long ago this this was a platform
On 2013-05-31, at 15:46 , Boris Zbarsky bzbar...@mit.edu wrote:
On 5/24/13 10:50 AM, Justin Lebar wrote:
Consider for example how much better harthur's fileit and dashboard
tools [1] [2] are than bugzilla's built-in equivalents.
Wasn't fileit integrated into the New Bug page? That search
On 11/07/2013 12:59, Gervase Markham wrote:
On 09/07/13 21:29, Chris Peterson wrote:
I've seen people change their Bugzilla name to include a comment about
being on PTO. We should promote this practice. We could also add a
Bugzilla feature (just a simple check box or a PTO date range) that
On 2013-07-11 3:06 AM, Robert O'Callahan wrote:
On Wed, Jul 10, 2013 at 6:09 AM, smaug sm...@welho.com wrote:
One thing, which has often brought up, would be to have other automatic
coding style checker than just Ms2ger.
See https://bugzilla.mozilla.org/show_bug.cgi?id=875605, which is,
On 7/11/2013 9:23 AM, Justin Lebar wrote:
One thing I've been thinking about is /why/ people are slow at reviews.
Someone who usually has a long review queue has told me that he hates
reviewing code. I realized that we don't really have a place at Mozilla for
experienced hackers who don't
On 11/07/13 15:38, Rob Campbell wrote:
On 2013-05-29, at 18:58 , Justin Dolske dol...@mozilla.com wrote:
On 5/29/13 3:09 PM, Ehsan Akhgari wrote:
Typically when you use the terminal to open an application on Mac, the
application is opened in the background.
Mmm, indeed. Someone told me long
On 7/11/13 9:23 AM, Justin Lebar wrote:
One thing I've been thinking about is /why/ people are slow at reviews.
Here are some possible reasons I've encountered myself:
1) Feeling overwhelmed because you have too many reviews pending and
therefore just staying away from your list of reviews.
self-reply. --1.
On 2013-07-11, at 09:56 , Rob Campbell rcampb...@mozilla.com wrote:
On 2013-05-31, at 15:46 , Boris Zbarsky bzbar...@mit.edu wrote:
[…]
1) It does not show feedback requests. This may explain why some people
are routinely ignoring them….
Good point. I filed:
On 2013-07-10 6:27 PM, Mark Côté wrote:
On 2013-07-10 2:18 PM, Boris Zbarsky wrote:
On 7/10/13 1:58 PM, Mark Côté wrote:
The BMO team is again considering switching to ReviewBoard, which should
fix this problem
How does ReviewBoard address this?
Again, what we have in the bug is diff 1
On 7/11/13 12:05 AM, Justin Lebar wrote:
On Wed, Jun 5, 2013 at 3:25 AM, Philipp Kewisch mozi...@kewis.ch wrote:
git rebase --interactive. It is /far/ more powerful than mq for this use-case.
I even have a |git qrebase| alias for this.
https://github.com/jlebar/moz-git-tools
Looks very
While I think your observations are useful, I think (hope!) you are a
massive outlier and I don't think we should design a policy based on the
assumption that your review commitments are in any way normal.
I would be totally OK with a policy that explicitly applies to everyone
except you. Or, we
On Thu, Jul 11, 2013 at 6:23 AM, Justin Lebar justin.le...@gmail.comwrote:
Someone who usually has a long review queue has told me that he hates
reviewing code. I realized that we don't really have a place at Mozilla
for
experienced hackers who don't want to do reviews. Should we?
I think
The way I work is that review and needinfo requests go to my inbox and I
process them with high priority. I can and do ignore them there temporarily
if I need to. Given I use my inbox as a to-do list, that approach seems
perfect for me.
Rob
--
Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus
On 7/11/13 11:37 AM, Robert O'Callahan wrote:
While I think your observations are useful, I think (hope!) you are a
massive outlier
Somewhat. My list was based on not only what makes my reviews slow but
what I've heard people mention as making reviews slow.
I do agree we shouldn't design a
Can you describe your patch queue-like workflow using git? git rebase -i
lets you reorder commits, but how do you quickly do the equivalent of hg
qpopping and qpushing a bunch of commits?
qpop qpush is a nop, of course; what do you want to in-between
those two commands?
I have a |git
On Thursday 2013-07-11 00:14 -0700, Robert O'Callahan wrote:
We can't have a rigid rule about 24 hours. Someone requesting a review from
me on Thursday PDT probably won't get a response until Monday if neither of
us work during the weekend.
But I think it's reasonable to expect developers to
It has been our policy [1] to discourage builds/tests run in automation
from relying on resources outside of the build network, to avoid
non-deterministic failures across the board and to reduce noise in
performance tests.
As of Saturday, this policy will be enforced by the RelEng firewall
On 2013-07-11 7:59 AM, Gervase Markham wrote:
On 09/07/13 21:29, Chris Peterson wrote:
I've seen people change their Bugzilla name to include a comment about
being on PTO. We should promote this practice. We could also add a
Bugzilla feature (just a simple check box or a PTO date range) that
That last thing was another item I found useful in the previous life. When
requesting a review from somebody, people could see this person currently has
X items in their review queue. You can ignore that information, but it's
there and it may help. It's still probably simpler for the
On 2013-07-11 11:26 AM, Philipp Kewisch wrote:
On 7/11/13 12:05 AM, Justin Lebar wrote:
On Wed, Jun 5, 2013 at 3:25 AM, Philipp Kewisch mozi...@kewis.ch wrote:
git rebase --interactive. It is /far/ more powerful than mq for this
use-case.
I even have a |git qrebase| alias for this.
I may have a skewed view of things, but I personally have not had problems
getting prompt code reviews. I also don't have a problem talking to my
reviewers about what I'm hacking on. I'm hesitant to throw a bunch of
technology at this problem, if it's a social issue. Code reviews are a
On 07/11/2013 03:09 AM, Nicholas Nethercote wrote:
On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden jwalden+...@mit.edu wrote:
Establishing one-day turnaround time on reviews, or on requests, would
require a lot more polling on my review queue.
You poll your review queue? Like, by visiting
On 7/11/13 8:24 PM, Jeff Walden wrote:
On 07/11/2013 03:09 AM, Nicholas Nethercote wrote:
On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden jwalden+...@mit.edu wrote:
Establishing one-day turnaround time on reviews, or on requests, would require
a lot more polling on my review queue.
You poll
On 7/11/2013 8:55 AM, Boris Zbarsky wrote:
On 7/11/13 11:37 AM, Robert O'Callahan wrote:
While I think your observations are useful, I think (hope!) you are a
massive outlier
Somewhat. My list was based on not only what makes my reviews slow
but what I've heard people mention as making
On 7/11/13 2:41 PM, Chris Pearce wrote:
Maybe you need to start farming out reviews to other/newer members of
the teams you work on?
Oh, that's been happening. A lot.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 7/11/13 8:00 PM, Ehsan Akhgari wrote:
On 2013-07-11 11:26 AM, Philipp Kewisch wrote:
On 7/11/13 12:05 AM, Justin Lebar wrote:
On Wed, Jun 5, 2013 at 3:25 AM, Philipp Kewisch mozi...@kewis.ch
wrote:
git rebase --interactive. It is /far/ more powerful than mq for this
use-case.
I even have
On 07/11/2013 11:00 AM, Ehsan Akhgari wrote:
On 2013-07-11 11:26 AM, Philipp Kewisch wrote:
On 7/11/13 12:05 AM, Justin Lebar wrote:
On Wed, Jun 5, 2013 at 3:25 AM, Philipp Kewisch mozi...@kewis.ch
wrote:
git rebase --interactive. It is /far/ more powerful than mq for this
use-case.
I even
Milan Sreckovic wrote:
That last thing was another item I found useful in the previous life. When requesting a
review from somebody, people could see this person currently has X items in their
review queue.
Even better would be if Bugzilla could compute their median review
turnaround for
I may still be missing something, but afaict mq git rebase -i hg
qcrecord (from the crecord extension.) This is speaking as someone who
hasn't used git rebase -i much, but people who have seem to agree with me
after seeing a qcrecord/qcrefresh demo.
qcrecord is, as far as I'm aware (it's
As a result of a discussion a few of us had today at the Toronto work week
about the use of appcache on the web (and if we should fix it), I did a quick
scan of the sites using appcache in Alexa's top ~50,000 websites (only includes
the landing page at a given URL).
Of the search, 16 sites
On Thu, 11 Jul 2013, Marcos Caceres wrote:
As a result of a discussion a few of us had today at the Toronto work
week about the use of appcache on the web (and if we should fix it), I
did a quick scan of the sites using appcache in Alexa's top ~50,000
websites (only includes the landing
46 matches
Mail list logo
