Re: Some data on mozilla-inbound

[Ben Hearsum]

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 to
>> developers than when it's busted at midnight California time.  More
>> than 3x, according to
>> http://oduinn.com/images/2013/blog_2013_02_pushes_per_hour.png.
> 
> See my "note 3" under the "Inbound uptime" section. I used exactly that
> graph to weight the inbound downtime and there wasn't a significant
> difference.
> 
>> - Getting agreement on a significant process change is really
>> difficult.  Is it possible to set up a repo where a few people can
>> volunteer to try Kats' approach for a couple of weeks?  That would
>> provide invaluable experience and data.
> 
> Yeah, there are plans afoot to try this, pending sheriff approval.

If you know what you want the repo to be called I'd advise filing a
RelEng bug about it now and we can get it done without being in the
critical path later on. You can also just ask for one of the twigs to be
customized
(https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectBranches).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Turning off Fedora 12 Talos tests on mozilla-central

[Rail Aliiev]

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 parallel since end of March on
Cedar and since April the 15th across all branches without any issues.

Ubuntu based machines use faster hardware that will improve end-to-end
times. Some of the machines used for Fedora will be re-imaged and used
for other platforms to improve capacity there.

We will still maintain some capacity of Fedora machines for the release
branches, some not-yet-ported-to-the-new-platform desktop unittests and
B2G emulator tests.

1. https://bugzilla.mozilla.org/show_bug.cgi?id=863903

-- 
Best regards,
Rail Aliiev
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Automatic tree clobbering is coming

[Ed Morley]

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Increasing the platform meeting's relevance for engineers

[Lawrence Mandel]

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? 

---
Since taking over management of the Platform meeting in February, my goal has 
been to make it more engineer driven and more relevant to the day-to-day 
activities of engineers. I think that there is value in having a forum for 
Mozilla's engineers to speak with one another on a regular basis. However, with 
the size of Mozilla's engineering base, creating a useful forum is a challenge. 

Some of the changes that we've made are:

- Engineers are once again doing the talking - Many of the technical updates 
were being given by project managers. No more. Updates for engineers, by 
engineers. So far, I think this has been successful in changing the tone of the 
meeting.

- More talk about work in progress - Reporting about completed work is great. 
However, we are now also talking about active projects. I think work that 
touches common sections of the code base or work that is likely to impact other 
teams is especially useful to flag.

- Identify topics that are stalled / need more attention - Over the last month 
I have seen a new focus on stability and orange factor issues. I have also seen 
a number of calls for help in identifying the source of issues.

- Invite other teams to speak with engineering - I invited Sheppy to join us to 
discuss documentation. I would encourage the invitation of other teams with 
which we collaborate to join the meeting for specific topics.

- Flag important discussions from across Mozilla's mailing lists - A number of 
people have commented to me that there are too many lists to track. This 
meeting is an opportunity to surface key online discussions to ensure they have 
the participation of the right people and reach a conclusion.

Some other suggestions are:

- A review of best practices and anti-pattens in order to build the technical 
vitality of the Mozilla engineering organization.

- More involvement by more people. The product and project sections of the 
agenda do not have a specific owner. You can bring up any related work wherever 
you think it makes sense. There are also the catchall sections "Key Issues" and 
"Roundtable" if you are not sure where your update belongs.

I want this meeting to be relevant for you. However, I am just a steward for 
this meeting. I need your help. Why do you attend the platform meeting? If you 
previously attended the meeting, why did you stop? Do you have ideas to make 
the Platform meeting more useful?

Thanks,

Lawrence
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Increasing the platform meeting's relevance for engineers

[Justin Lebar]

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 have to remember to go looking for it.

Since in-person attendance at the MoCo meetings is non-zero, it seems
clear that some people prefer being in live attendance.  That's
totally fine.  But at the very least, I think it's useful to recognize
that not everyone is willing or able to attend the meetings live, and
if we think what's going on there is important, we should make an
effort to broadcast it to a larger audience.

Last time I checked the wiki isn't a canonical record of the
engineering meeting's contents, 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).

On a related note, I think the engineering meeting is a bad place for
having discussions or debating decisions.  Inevitably, many of the
people in attendance won't care about this particular issue, so we're
just wasting their time.  And similarly, at our current numeric and
geographic scale it's inevitable that people who do care about the
issue won't be in attendance at the meeting and thus won't be able to
participate.  I think therefore that discussions / debates are
better-suited for our newsgroups or for smaller meetings.

-Justin

On Wed, Apr 24, 2013 at 2:26 PM, Lawrence Mandel  wrote:
> 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?
>
> ---
> Since taking over management of the Platform meeting in February, my goal has 
> been to make it more engineer driven and more relevant to the day-to-day 
> activities of engineers. I think that there is value in having a forum for 
> Mozilla's engineers to speak with one another on a regular basis. However, 
> with the size of Mozilla's engineering base, creating a useful forum is a 
> challenge.
>
> Some of the changes that we've made are:
>
> - Engineers are once again doing the talking - Many of the technical updates 
> were being given by project managers. No more. Updates for engineers, by 
> engineers. So far, I think this has been successful in changing the tone of 
> the meeting.
>
> - More talk about work in progress - Reporting about completed work is great. 
> However, we are now also talking about active projects. I think work that 
> touches common sections of the code base or work that is likely to impact 
> other teams is especially useful to flag.
>
> - Identify topics that are stalled / need more attention - Over the last 
> month I have seen a new focus on stability and orange factor issues. I have 
> also seen a number of calls for help in identifying the source of issues.
>
> - Invite other teams to speak with engineering - I invited Sheppy to join us 
> to discuss documentation. I would encourage the invitation of other teams 
> with which we collaborate to join the meeting for specific topics.
>
> - Flag important discussions from across Mozilla's mailing lists - A number 
> of people have commented to me that there are too many lists to track. This 
> meeting is an opportunity to surface key online discussions to ensure they 
> have the participation of the right people and reach a conclusion.
>
> Some other suggestions are:
>
> - A review of best practices and anti-pattens in order to build the technical 
> vitality of the Mozilla engineering organization.
>
> - More involvement by more people. The product and project sections of the 
> agenda do not have a specific owner. You can bring up any related work 
> wherever you think it makes sense. There are also the catchall sections "Key 
> Issues" and "Roundtable" if you are not sure where your update belongs.
>
> I want this meeting to be relevant for you. However, I am just a steward for 
> this meeting. I need your help. Why do you attend the platform meeting? If 
> you previously attended the meeting, why did you stop? Do you have ideas to 
> make the Platform meeting more useful?
>
> Thanks,
>
> Lawrence
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Increasing the platform meeting's relevance for engineers

[Lawrence Mandel]

- 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 transcript out to
> everyone, so I don't even have to remember to go looking for it.
> 
> Since in-person attendance at the MoCo meetings is non-zero, it seems
> clear that some people prefer being in live attendance.  That's
> totally fine.  But at the very least, I think it's useful to
> recognize
> that not everyone is willing or able to attend the meetings live, and
> if we think what's going on there is important, we should make an
> effort to broadcast it to a larger audience.

Good point.

> Last time I checked the wiki isn't a canonical record of the
> engineering meeting's contents, 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).

The wiki does have point form information of the topics raised but is 
definitely not a transcript. The minutes are available as soon as the meeting 
is over. I can create a notification but only if you think that's helpful 
without the transcript.
 
> On a related note, I think the engineering meeting is a bad place for
> having discussions or debating decisions.  Inevitably, many of the
> people in attendance won't care about this particular issue, so we're
> just wasting their time.  And similarly, at our current numeric and
> geographic scale it's inevitable that people who do care about the
> issue won't be in attendance at the meeting and thus won't be able to
> participate.  I think therefore that discussions / debates are
> better-suited for our newsgroups or for smaller meetings.

If this is in response to my comment about flagging mailing list discussions, I 
do this so that people are aware of the active discussions and have the links 
to comment. We have not spent much time discussing any of these items in the 
meeting itself.

Lawrence
> 
> -Justin
> 
> On Wed, Apr 24, 2013 at 2:26 PM, Lawrence Mandel
>  wrote:
> > 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?
> >
> > ---
> > Since taking over management of the Platform meeting in February,
> > my goal has been to make it more engineer driven and more relevant
> > to the day-to-day activities of engineers. I think that there is
> > value in having a forum for Mozilla's engineers to speak with one
> > another on a regular basis. However, with the size of Mozilla's
> > engineering base, creating a useful forum is a challenge.
> >
> > Some of the changes that we've made are:
> >
> > - Engineers are once again doing the talking - Many of the
> > technical updates were being given by project managers. No more.
> > Updates for engineers, by engineers. So far, I think this has been
> > successful in changing the tone of the meeting.
> >
> > - More talk about work in progress - Reporting about completed work
> > is great. However, we are now also talking about active projects.
> > I think work that touches common sections of the code base or work
> > that is likely to impact other teams is especially useful to flag.
> >
> > - Identify topics that are stalled / need more attention - Over the
> > last month I have seen a new focus on stability and orange factor
> > issues. I have also seen a number of calls for help in identifying
> > the source of issues.
> >
> > - Invite other teams to speak with engineering - I invited Sheppy
> > to join us to discuss documentation. I would encourage the
> > invitation of other teams with which we collaborate to join the
> > meeting for specific topics.
> >
> > - Flag important discussions from across Mozilla's mailing lists -
> > A number of people have commented to me that there are too many
> > lists to track. This meeting is an opportunity to surface key
> > online discussions to ensure they have the participation of the
> > right people and reach a conclusion.
> >
> > Some other suggestions are:
> >
> > - A review of best practices and anti-pattens in order to build the
> > technical vitality of the Mozilla engineering organization.
> >
> > - More involvement by more people. The product and project sections
> > of the agenda do not have a specific owner. You can bring up any
> > related work wherever you think it makes sense. There are also the
> > catchall sections "Key Issues" and "Roundtable" if you are not
> > sure where your update belongs.
> >
> > I want this meeting to be relevant for you. However, I am just a
> > steward for this meeting. I need your help. Why do you attend the
> > platform meeting? If you previously attended the meeting, why did
> > yo

Re: Increasing the platform meeting's relevance for engineers

[Benjamin Smedberg]

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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Increasing the platform meeting's relevance for engineers

[Bobby Holley]

+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 there, kind of frustrated, trying to avoid getting
involved in discussions that don't actually need my input (giving input is
entertaining, but the efficiency cost of weighing in is very high for large
meetings).

Even though I don't attend (and don't plan to), I'd very much like to have
a summary appear in one of my inboxes so that I can follow up on things
that interest me. My workflow is push-based rather than poll-based, and I
think that's shared by many other developers.

Good engineering decisions often require extremely close analysis of minute
details. This scales in an async/distributed model, but doesn't scale at
all when things are handled synchronously by large groups. This is why
Hixie refuses to join conference calls, for example.

Cheers,
bholley


On Wed, Apr 24, 2013 at 12:13 PM, Justin Lebar wrote:

> 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 have to remember to go looking for it.
>
> Since in-person attendance at the MoCo meetings is non-zero, it seems
> clear that some people prefer being in live attendance.  That's
> totally fine.  But at the very least, I think it's useful to recognize
> that not everyone is willing or able to attend the meetings live, and
> if we think what's going on there is important, we should make an
> effort to broadcast it to a larger audience.
>
> Last time I checked the wiki isn't a canonical record of the
> engineering meeting's contents, 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).
>
> On a related note, I think the engineering meeting is a bad place for
> having discussions or debating decisions.  Inevitably, many of the
> people in attendance won't care about this particular issue, so we're
> just wasting their time.  And similarly, at our current numeric and
> geographic scale it's inevitable that people who do care about the
> issue won't be in attendance at the meeting and thus won't be able to
> participate.  I think therefore that discussions / debates are
> better-suited for our newsgroups or for smaller meetings.
>
> -Justin
>
> On Wed, Apr 24, 2013 at 2:26 PM, Lawrence Mandel 
> wrote:
> > 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?
> >
> > ---
> > Since taking over management of the Platform meeting in February, my
> goal has been to make it more engineer driven and more relevant to the
> day-to-day activities of engineers. I think that there is value in having a
> forum for Mozilla's engineers to speak with one another on a regular basis.
> However, with the size of Mozilla's engineering base, creating a useful
> forum is a challenge.
> >
> > Some of the changes that we've made are:
> >
> > - Engineers are once again doing the talking - Many of the technical
> updates were being given by project managers. No more. Updates for
> engineers, by engineers. So far, I think this has been successful in
> changing the tone of the meeting.
> >
> > - More talk about work in progress - Reporting about completed work is
> great. However, we are now also talking about active projects. I think work
> that touches common sections of the code base or work that is likely to
> impact other teams is especially useful to flag.
> >
> > - Identify topics that are stalled / need more attention - Over the last
> month I have seen a new focus on stability and orange factor issues. I have
> also seen a number of calls for help in identifying the source of issues.
> >
> > - Invite other teams to speak with engineering - I invited Sheppy to
> join us to discuss documentation. I would encourage the invitation of other
> teams with which we collaborate to join the meeting for specific topics.
> >
> > - Flag important discussions from across Mozilla's mailing lists - A
> number of people have commented to me that there are too many lists to
> track. This meeting is an opportunity to surface key online discussions to
> ensure they have the participation of the right people and reach a
> conclusion.
> >
> > Some other suggestions are:
> >
> > - A review of best practices and anti-pattens in order to build the
> technical vitality of the Mozilla engineering organization.
> >
> > - More involvement by more 

Re: Some data on mozilla-inbound

[Ehsan Akhgari]

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.


True!


Should we be surprised when people don't get this right 100% of the time?


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 there, which I find unacceptable 
for day-to-day work), I always ask myself what are the chances that this 
thing that I want to push could bounce, and I test on try only when I 
can convince myself that the chances are slow.  All I was suggesting was 
give people a way to assess whether they're good at making these calls, 
and improve it if they're not.



Instead of considering how to get people people to strike a better
balance between wasting infra resources and burning inbound, I think
we need to consider what we can do to increase the acceptable margin
of error.


These are not either/or choices.


Note that we don't have enough capacity to turn around current try
requests within a reasonable amount of time.  Pushing to inbound is
the only way to get quick feedback on whether your patch works, these
days.  As I've said before, I'd love to see releng report on try
turnaround times, so we can hold someone accountable.  The data is
there; we just need to process it.

If we can't increase the amount of infra capacity we have, perhaps we
could use it more effectively.  We've discussed lots of ways we might
accomplish this on this newsgroup, and I've seen very few of them
tried.  Perhaps an important part of the problem is that we're not
able to innovate quickly enough on this front.


We've been asking for more infra capacity for as long as I can remember, 
and so far we've always had a shortage in that front (part of which is 
due to the continuous increase in development pace, which is a good 
thing), so I agree that the way to win this battle is to stop waiting 
for that magical day when we have "enough" capacity and stat using it 
more efficiently.  What I suggested could be a part of that.



People are always going to make mistakes, and the purpose of processes
is to minimize the harm caused by those mistakes, not to embarrass or
cajole people into behaving better in the future.  As Jono would say,
it's not the user's fault.


Nobody's blaming the user.  We should just empower them to make better 
choices.


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Some data on mozilla-inbound

[Ehsan Akhgari]

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 similar to
?


Not trivial, but not too difficult either. Do we have any evidence to
show that the try highscores page has made an impact in reducing
unnecessary try usage? Also I agree with Justin that if we do this it
will be very much a case of sending mixed messages. The try highscores
list says to people "don't land on try" and the backout highscores list
would say to people "always test on try".


It's worth noting that when I've contacted developers in the top 10 of
the tryserver usage leaderboard my message is not "do not use try", but
instead suggestions like:
* "please do not use -p all -u all when you only made an android
specific change"
* "you already did a |-p all -u all| run - on which mochitest-1 failed
on all platforms, so please don't test every testsuite on every platform
for the half dozen iterations you ran on Try thereafter" (at much as
this sounds like an extreme example, there have been cases like this)


Yes, this! ^

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 that.


Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Some data on mozilla-inbound

[Ehsan Akhgari]

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 time, it's a lot more inconvenient to
developers than when it's busted at midnight California time.  More
than 3x, according to
http://oduinn.com/images/2013/blog_2013_02_pushes_per_hour.png.


See my "note 3" under the "Inbound uptime" section. I used exactly that
graph to weight the inbound downtime and there wasn't a significant
difference.


- Getting agreement on a significant process change is really
difficult.  Is it possible to set up a repo where a few people can
volunteer to try Kats' approach for a couple of weeks?  That would
provide invaluable experience and data.


Yeah, there are plans afoot to try this, pending sheriff approval.


If you know what you want the repo to be called I'd advise filing a
RelEng bug about it now and we can get it done without being in the
critical path later on. You can also just ask for one of the twigs to be
customized
(https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectBranches).


We're planning to use the try server, I believe.

Cheers,
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Some data on mozilla-inbound

[David Ascher]

> 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 that.


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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Increasing the platform meeting's relevance for engineers

[Ehsan Akhgari]

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 "projects" planet as well.


It would be great if somebody syndicated that to the main Planet Mozilla 
(which is what most people read.)  For many of us, if something only 
shows up on one of these smaller planets (moons?), it never happened!


Cheers,
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Increasing the platform meeting's relevance for engineers

[Ehsan Akhgari]

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 followed, if it's more 
than 3-4 one line bullet points per category, you're probably giving too 
much information.  If you're listing tons of bug numbers with their 
summaries, you probably want to link to another wiki page for those who 
are interested in the details.


* The order of the meeting is extremely important.  I suggested to JP a 
while ago that we should begin the meeting with the roundtable section, 
in order to basically filter the stuff that is really interesting to 
engineers at first, so that we can leave after that part if the rest of 
the meeting is not interesting.  But if we stopped reading over status 
updates, a lot of that time would have been solved anyway.


* Agenda.  Be very strict about only talking about stuff that is on the 
agenda at least 10 minutes before the meeting, in order to let people 
know whether they're interested in attending.  I found out that at many 
times I merely attended to figure out _if_ something interesting is 
being discussed, which is a waste of time.


* Having minutes, but not decisions.  I think that discussing the active 
issues on mailing lists _could_ be useful if it's limited to 1-2 
minutes, but we should absolutely not use this meeting as a venue for 
making decisions since not all of the people with useful feedback might 
be attending, as previously noted.


* Have more interesting content for hackers.  I think that most of the 
content of the current meetings are project/product level updates, which 
are interesting to read in a wiki page, but not that interesting.  I 
would really like it a lot more if I could go up and say hey guys, by 
the way I added this cool class to MFBT recently which you can use to do 
this cool thing, or, hey, we're seeing this crash which we have a hard 
time reproducing, can anybody help out?


I'd definitely love to attend the meeting in the future to see if it has 
improved enough to make me a usual attendee again!  :-)


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Some data on mozilla-inbound

[Ehsan Akhgari]

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 it's hard an an individual to
judge how good I'm at that.


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.


The AWS cost would be the wrong measure, since it doesn't account for 
the amount of time that 100 other people spent grinding their teeth 
because they could not push.  :-)  But yeah, I agree with the general 
idea of a cost measure, I just can't think of what a good one would be 
(well, one better than the wall-clock time...)


Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Some data on mozilla-inbound

[Justin Lebar]

> 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 proposed bug 848589 to do just this.  I think it's
worth trying, but someone needs to implement it.

> Nobody's blaming the user.  We should just empower them to make better 
> choices.

Okay.

I guess what's frustrating to me is that we have this problem and
essentially our only option to solve it is to change users' behavior.
I totally believe that some people could use resources much more
efficiently, but it's frustrating if changing user behavior is our
only tool.

We keep talking about this every few weeks, as though there's some
hidden solution that will emerge only after ten newsgroup threads.  In
actuality, we very likely will need to do a bunch of different things,
each having a small impact.  And in particular, I don't think we'll
solve this problem without significant work from release engineering.
If that work isn't forthcoming, I don't think we're going to make a
significant dent in this.

On Thu, Apr 25, 2013 at 1:20 AM, Ehsan Akhgari  wrote:
> 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 it's hard an an individual to
>> judge how good I'm at that.
>>
>>
>> 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.
>
>
> The AWS cost would be the wrong measure, since it doesn't account for the
> amount of time that 100 other people spent grinding their teeth because they
> could not push.  :-)  But yeah, I agree with the general idea of a cost
> measure, I just can't think of what a good one would be (well, one better
> than the wall-clock time...)
>
> Ehsan
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Some data on mozilla-inbound

[Phil Ringnalda]

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 "builders". 111 of these had "-pgo"
> or "_pgo" in the name, and I excluded them. I created a 553x389 matrix
> with the remaining builders and filled in how much time was spent on
> each changeset for each builder (in case of multiple jobs, I added the
> times).
> 
> Then I assumed that any empty field in the 553x389 matrix was a result
> of coalescing. This is a grossly simplifying assumption that I would
> like to revisit - I know for Android changes we can detect that in some
> cases and only run the relevant tests; my assumption means the rest of
> the platforms are considered "coalesced" for these changes. I filled in
> these fields in the matrix with the average time spent on all the other
> builds for that builder in the matrix.
> 
> * A total of 228717299 seconds were spent on the 128777 entries in the
> matrix
> * After de-coalescing, a total of 373751505 seconds would have been
> spent on the 215117 entries in the matrix (an increase of 63%)
> * With coalescing, but removing all the backout pushes and pushes that
> were completely backed out, a total of 173027517 seconds were spent on
> 97623 entries (down 24% from actual usage)
> * With de-coalescing AND stripping backouts, a total of 292634211
> seconds would have been spent on the 168437 entries (an increase of 27%
> over actual usage)

Too many iffy things to say that those percentages are anything other
than numbers between 1 and 100, I'm afraid.

Not only do Android-only pushes only build Android, b2g-only pushes only
build b2g, and browser/-only pushes only build desktop, and jobs with
spidermonkey in the name are only built for pushes that touch js/src/.
You can tell the difference between coalescing and intentionally only
building one product by looking at self-serve, where a push that only
intended to build Android will only list the Android builds, while a
push that intended to build everything but had everything but Android
coalesced away will still show all the other builds, even though they
actually ran on a different push, so I presume there's a way to query
buildapi to find out whether a missing build was coalesced or just not
triggered at all.

Your range, April 6 - April 17, includes two full weekends (when
coalescing barely exists) but only a week and a half of weekdays, when
coalescing actually happens. It also includes the travel weekend before,
and a half week of a b2g workweek when b2g patches were first not
landing at all, and then landing on birch instead of inbound, dropping
coalescing, but because birch granted itself the second-highest possible
priority, coalescing could also have be more extreme on inbound while
birch was starving it of slaves.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Some data on mozilla-inbound

[Phil Ringnalda]

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 there, which I find unacceptable
> for day-to-day work), I always ask myself what are the chances that this
> thing that I want to push could bounce, and I test on try only when I
> can convince myself that the chances are slow.  All I was suggesting was
> give people a way to assess whether they're good at making these calls,
> and improve it if they're not.

I'm curious about what you think the wait times are, and what wait times
you would find acceptable.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rethinking the amount of system JS we use in Gecko on B2G

[Caspy7]

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 discussed here.

Anyway, I just wanted to suggest that in the future, once asm.js has come to 
greater maturity (and of course GGC & Lazy bytecode gen), perhaps these workers 
could be compiled to asm.  This would keep the security of JS while having high 
performance and not require a rewrite.
Again, apologies if my underlying assumptions or understandings are errant.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Increasing the platform meeting's relevance for engineers

[Doug Turner]

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 people should/must read.  Someone started a Reddit 
subgroup r/MozillaTech.  This subgroup is much more relevant to the work 
that my team is doing than the public Platform Meeting.


So, let's focus on getting technical information to the platform team 
using something like r/MozillaTech.  We can ask the smaller, more 
focused, staff meetings to report on r/MozillaTech (or similar) any 
interesting news.


(btw, mbrubeck... thank you so much for making the MoCo meeting 
accessible to the dozens of people that read it instead of watch/listen 
to it.  I am pretty sure you've saved hundreds of engineering hours.)



Justin Lebar wrote:

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 have to remember to go looking for it.

Since in-person attendance at the MoCo meetings is non-zero, it seems
clear that some people prefer being in live attendance.  That's
totally fine.  But at the very least, I think it's useful to recognize
that not everyone is willing or able to attend the meetings live, and
if we think what's going on there is important, we should make an
effort to broadcast it to a larger audience.

Last time I checked the wiki isn't a canonical record of the
engineering meeting's contents, 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).

On a related note, I think the engineering meeting is a bad place for
having discussions or debating decisions.  Inevitably, many of the
people in attendance won't care about this particular issue, so we're
just wasting their time.  And similarly, at our current numeric and
geographic scale it's inevitable that people who do care about the
issue won't be in attendance at the meeting and thus won't be able to
participate.  I think therefore that discussions / debates are
better-suited for our newsgroups or for smaller meetings.

-Justin

On Wed, Apr 24, 2013 at 2:26 PM, Lawrence Mandel  wrote:

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?

---
Since taking over management of the Platform meeting in February, my goal has 
been to make it more engineer driven and more relevant to the day-to-day 
activities of engineers. I think that there is value in having a forum for 
Mozilla's engineers to speak with one another on a regular basis. However, with 
the size of Mozilla's engineering base, creating a useful forum is a challenge.

Some of the changes that we've made are:

- Engineers are once again doing the talking - Many of the technical updates 
were being given by project managers. No more. Updates for engineers, by 
engineers. So far, I think this has been successful in changing the tone of the 
meeting.

- More talk about work in progress - Reporting about completed work is great. 
However, we are now also talking about active projects. I think work that 
touches common sections of the code base or work that is likely to impact other 
teams is especially useful to flag.

- Identify topics that are stalled / need more attention - Over the last month 
I have seen a new focus on stability and orange factor issues. I have also seen 
a number of calls for help in identifying the source of issues.

- Invite other teams to speak with engineering - I invited Sheppy to join us to 
discuss documentation. I would encourage the invitation of other teams with 
which we collaborate to join the meeting for specific topics.

- Flag important discussions from across Mozilla's mailing lists - A number of 
people have commented to me that there are too many lists to track. This 
meeting is an opportunity to surface key online discussions to ensure they have 
the participation of the right people and reach a conclusion.

Some other suggestions are:

- A review of best practices and anti-pattens in order to build the technical 
vitality of the Mozilla engineering organization.

- More involvement by more people. The product and project sections of the agenda do not have a 
specific owner. You can bring up any related work wherever you think it makes sense. There are also 
the catchall sections "Key Issues" and "Roundtable" if you are not sure where 
your update belongs.

I want this meeting to be relevant for you. However, I am just a steward for 
t