I think if we need to find reasons to keep a meeting relevant, we need
to kill the meeting. Lawrence, you should just discontinue the meeting
for a few weeks and see if we really need it. I bet we wont.
I would much rather see us spend the time to curate what's important --
what platform peo
I'm not a developer and so apologize if my understanding is oversimplified or
naive.
I had been under the impression that C++ (previously) was not being used at
all, apart from Gecko itself, for security and stability reasons. Perhaps I am
mistaken or simply misunderstand the structures discuss
On 4/24/13 9:50 PM, Ehsan Akhgari wrote:
> No. But that's not what I was talking about. Whether something lands
> directly on try is a judgement call, and some people may be better at it
> than others. As someone who has stopped using try server as a rule
> (because of the excessive wait times t
On 4/22/13 12:54 PM, Kartikaya Gupta wrote:
> I looked at all the build.json files [4] from the 6th of April to the
> 17th of April and pulled out all the jobs that corresponding to the
> "push" changesets in my range above. For this set of 553 changesets,
> there were 500 (exactly!) distinct "buil
> One idea might be to give developers feedback on the consequences of a
> particular push, e.g. the AWS cost, a proxy for "time during which
> developers couldn't push" or some other measurable metric. Right now
> each push probably "feels" as "expensive" as every other.
For tryserver, I propose
On 2013-04-25 1:02 AM, David Ascher wrote:
The messaging around this should not be to tell people "always test
on try". It should be to help them figure out how to make better
judgement calls on this. This is a skill that people develop and
are not born with, and without data i
I can definitely tell you what I liked and disliked about these
meetings, and why I stopped going to them.
* Too many status updates. Putting the status updates in the wiki is
great. Reading over them when a lot of people are listening
synchronously is not. The KISS rule needs to be followe
On 2013-04-24 3:35 PM, Benjamin Smedberg wrote:
On 4/24/2013 3:13 PM, Justin Lebar wrote:
and last time I checked there's no way
to get notified when a meeting's notes are up (via RSS or e-mail or
whatever).
https://blog.mozilla.org/meeting-notes/archives/tag/mozillaplatform and
it shows up on
> The messaging around this should not be to tell people "always test on
> try". It should be to help them figure out how to make better judgement
> calls on this. This is a skill that people develop and are not born with,
> and without data it's hard an an individual to judge how good I'm at tha
On 2013-04-24 9:14 AM, Ben Hearsum wrote:
On 04/23/13 10:21 PM, Kartikaya Gupta wrote:
On 13-04-23 19:21 , Nicholas Nethercote wrote:
- The 'inbound was closed for 15.3068% of the total time due to
"bustage"' number is an underestimate, in one sense. When inbound is
closed at 10am California t
On 2013-04-23 1:17 PM, Ed Morley wrote:
On 23/04/2013 17:28, Kartikaya Gupta wrote:
On 13-04-23 00:39 , Ehsan Akhgari wrote:
How hard would it be to
gather a list of the total number of patches being backed out plus the
amount of time that we spent building/testing those, hopefully in a
style s
On 2013-04-23 12:05 PM, Justin Lebar wrote:
The ratio of things landed on inbound which turn out to busted is really
worrying
On the one hand, we're told not to push to try too much, because that
wastes resources.
On the other hand, we're told not to burn m-i, because that wastes resources.
+1 to meeting notes being mailed out or on a feed somewhere.
I generally avoid big meetings like the plague because the density of
discussion that I'm interested in is too low to warrant my full attention,
and I'm not great at context-switching to and from my own work either. I
usually just sit th
On 4/24/2013 3:13 PM, Justin Lebar wrote:
and last time I checked there's no way
to get notified when a meeting's notes are up (via RSS or e-mail or
whatever).
https://blog.mozilla.org/meeting-notes/archives/tag/mozillaplatform and
it shows up on the "projects" planet as well.
--BDS
_
- Original Message -
> One thing I love about the MoCo meetings is that if I don't go, I
> don't miss anything except the chance to ask questions: mbrubeck &co
> create detailed minutes (really, transcripts) of every meeting, which
> I can read on my schedule. He then e-mails the transcr
One thing I love about the MoCo meetings is that if I don't go, I
don't miss anything except the chance to ask questions: mbrubeck &co
create detailed minutes (really, transcripts) of every meeting, which
I can read on my schedule. He then e-mails the transcript out to
everyone, so I don't even ha
tl;dr
I would like to make the platform meeting more relevant for engineers. I have
already made some changes (see below) and am interested in your feedback on
what you would like to get out of this meeting. If you don't currently attend,
what would make this meeting relevant for you?
---
Sinc
On 23 April 2013 19:59:28, Chris Lord wrote:
Having just read up the replies, it seems that it's generally agreed
that this would be better as an opt-in feature. Is anyone tasked to
make it such? Is there a bug I can follow for it?
Bug 863091 (I've attached a patch, which will land soon).
Ed
_
Hi,
We are going to turn off Fedora 12 based Talos tests on mozilla-central,
mozilla-inbound and project branches and run them on Ubuntu 12.04
platform this Thursday. This includes both 32 and 64-bit platforms and
this work is tracked in Bug 863903 [1].
We have been using Fedora and Ubuntu in par
On 04/23/13 10:21 PM, Kartikaya Gupta wrote:
> On 13-04-23 19:21 , Nicholas Nethercote wrote:
>> - The 'inbound was closed for 15.3068% of the total time due to
>> "bustage"' number is an underestimate, in one sense. When inbound is
>> closed at 10am California time, it's a lot more inconvenient t
20 matches
Mail list logo
