This is fantastic, thank you *so* much!
On Wed, Jul 3, 2013 at 7:40 PM, bent wrote:
> Hi folks,
>
> I've finally uploaded my secure mail viewer addon to AMO so that updates
> will work someday soon. Here's the link:
>
>
> https://addons.mozilla.org/en-US/firefox/addon/bugzilla-secure-mail-viewe
On 2013-07-11 3:03 PM, Philipp Kewisch wrote:
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
wrote:
git rebase --interactive. It is /far/ more powerful than mq fo
On Thursday, 11 July 2013 at 18:02, Ian Hickson wrote:
> 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 u
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 land
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
> 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
Ed Morley wrote:
It has been our policy 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 RelE
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
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
wrote:
git rebase --interactive. It is /far/ more powerful than mq for this
use-case.
I even have a |git qreba
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
wrote:
git rebase --interactive. It is /far/ more powerful than mq for this
use-case.
I even have a |git qrebase| a
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
https://lists.
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 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? L
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 revie
On 07/11/2013 03:09 AM, Nicholas Nethercote wrote:
> On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden 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
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
conversa
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 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/
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 revie
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)
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
be
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 developer
> 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 q
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
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 eanut
On Thu, Jul 11, 2013 at 6:23 AM, Justin Lebar wrote:
> 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 someone can "ha
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 c
On 7/11/13 12:05 AM, Justin Lebar wrote:
On Wed, Jun 5, 2013 at 3:25 AM, Philipp Kewisch 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 interesting, lots of ni
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 again
self-reply. --1.
On 2013-07-11, at 09:56 , Rob Campbell wrote:
> On 2013-05-31, at 15:46 , Boris Zbarsky wrote:
[…]
>> 1) It does not show feedback requests. This may explain why some people
>> are routinely ignoring them….
>
> Good point. I filed:
>
> https://github.com/harthur/bugzilla-
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.
On 11/07/13 15:38, Rob Campbell wrote:
On 2013-05-29, at 18:58 , Justin Dolske 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
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 do
On 2013-07-11 3:06 AM, Robert O'Callahan wrote:
On Wed, Jul 10, 2013 at 6:09 AM, smaug 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,
ironically, waiting
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) th
On 2013-05-31, at 15:46 , Boris Zbarsky 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 suggestion
d
On 2013-05-29, at 18:58 , Justin Dolske 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 convention,
> but i
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...
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 (bein
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 th
On 2013-05-18, at 06:09 , David Rajchenbach-Teller 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 minimal
> versi
On 10/07/13 15:09, Boris Zbarsky wrote:
> And communicated via bzapi so bzexport can also warn.
BzAPI could add a flag based on a parsing of the name - but then, if
there was an accurate algorithm for parsing a name to extract absence
information, bzexport could use it directly.
Perhaps we could
On Thu, Jul 11, 2013 at 10:49 AM, Chris Peterson 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 the change in the
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.or
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 Bugzil
On 11/07/13 09:08 , Robert O'Callahan wrote:
On Wed, Jul 10, 2013 at 3:26 PM, Justin Lebar wrote:
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
On 11/07/13 12:09 , Nicholas Nethercote wrote:
On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden 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
On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden 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 *awful*.
I pers
On Thu, Jul 11, 2013 at 5:06 PM, Robert O'Callahan wrote:
> On Wed, Jul 10, 2013 at 6:09 AM, smaug 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,
>
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 ta
On Wed, Jul 10, 2013 at 2:48 PM, Jeff Walden 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.
> Establishing one-da
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
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
On Wed, Jul 10, 2013 at 3:26 PM, Justin Lebar wrote:
> 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 of insanity" a
On Wed, Jul 10, 2013 at 6:09 AM, smaug 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,
ironically, waiting for review.
Rob
--
Jtehsauts tshaei dS,o n"
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.
___
dev-
53 matches
Mail list logo
