Re: Excessive inbound bustage
then it's fine to land it on m-i without try. Maybe because I usually work on core, and such confidence is hard to reach there, but I'd like to think at least a try run that check if the patch builds on all platform and a full test run on at least one platform is not too much sacrifice of ones time. Personally I think that my time is cheaper than everyone's time. It is slow. It is annoying, but holding up ALL the other patches/developers is expensive hence a risky option. So I suggest everyone to be very conservative about that confident feeling. I'm all for auto landing, but with all the intermittent bugs we have it's not easy I guess. On Mon, Apr 20, 2015 at 11:47 PM, Eric Rescorla e...@rtfm.com wrote: I think perhaps part of the question is what the purpose of m-i versus try is. My general algorithm is that you should get your patch to the point where you have tested it locally and have reasonable confidence that there are no portability issues and then it's fine to land it on m-i without try. And if you think there are likely to be portability issues or you don't want to/can't run tests locally you should push to try. In answer to the question of why I avoid try, the answer is simple: it's slow. With that said, I think the right fix isn't to make try faster (though that would also be good) but to make autolanding work. That way people could just fire and forget without inconveniencing others if their patch failed. -Ekr On Mon, Apr 20, 2015 at 1:54 PM, Aaron Klotz akl...@mozilla.com wrote: Do I have terrible timing when it comes to landing patches, or has inbound been closed due to bustage far too often over the past couple of months? At first I thought maybe it was the former, but now I'm believing that it is the latter. As of late, when I check to see if inbound is open, I just assume it is going to be closed before I even check its status. I can only infer that patches are not being tested extensively enough on try. To me this is symptomatic of a problem: What is it about try that we are avoiding it, and what can we do to improve the situation? ___ 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: RFC: Navigation transitions
On Tue, Apr 21, 2015 at 10:02 AM, Christopher Lord cl...@mozilla.com wrote: http://chrislord.net/?p=273preview=1_ppp=0afe20d87f I haven't reviewed it completely, but it seems at the very least you should use media queries rather than require separate stylesheets. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On 2015-04-21 12:20 PM, Eric Rescorla wrote: On Tue, Apr 21, 2015 at 12:14 PM, Ms2ger ms2...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/2015 06:07 PM, Eric Rescorla wrote: On Tue, Apr 21, 2015 at 8:39 AM, jmath...@mozilla.com wrote: On Tuesday, April 21, 2015 at 3:03:37 AM UTC-5, Gabriele Svelto wrote: On 21/04/2015 08:25, Gabor Krizsanits wrote: Maybe because I usually work on core, and such confidence is hard to reach there, but I'd like to think at least a try run that check if the patch builds on all platform and a full test run on at least one platform is not too much sacrifice of ones time. Personally I think that my time is cheaper than everyone's time. It is slow. It is annoying, but holding up ALL the other patches/developers is expensive hence a risky option. So I suggest everyone to be very conservative about that confident feeling. I agree; since I work mostly on patches that are relevant for FxOS/B2G I always run a try build across all architectures before to ensure it doesn't break anything else. Somehow I was under the impression that everybody did that. Gabriele I think this should be standard procedure for anyone working on platform. A push to try for a base set of builds (mac, linux, win, b2g ics) plus a good set of tests (usually for me it's mochitests) covers things. Once those mostly complete I can mark the bug with check-needed and walk away, tree drivers will handle the landing when inbound is open and green. Isn't the point of inbound supposed to be that it's safe to land even without 100% confidence? Here's the guidance from the Wiki: without 100% doesn't mean with 10%, which is what it feel like nowadays. Tryserver time is machine time; inbound bustage is people time, and the latter is much more expensive. I agree that it shouldn't be 10%. Hopefully once we have the autolander this will be a non-issue. It would be a huge help if someone made a little tool which would show you how often one specific person breaks inbound. I would definitely like to know whether I'm closer to 10% or 100% myself. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On 4/21/2015 12:50 PM, Andrew Halberstadt wrote: This could be effective, but if not implemented with care it could also be very de-motivating, especially for a well-intentioned contributor. Is this really an issue though, given the time and effort required to earn sufficient commit access to push to inbound? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On 21/04/15 02:41 PM, Chris Peterson wrote: On 4/21/15 11:27 AM, Ehsan Akhgari wrote: I agree that it shouldn't be 10%. Hopefully once we have the autolander this will be a non-issue. It would be a huge help if someone made a little tool which would show you how often one specific person breaks inbound. I would definitely like to know whether I'm closer to 10% or 100% myself. Something like the Try High Score ranking for inbound backouts would be straightforward to automate: https://secure.pub.build.mozilla.org/builddata/reports/reportor/daily/highscores/highscores.html This could be effective, but if not implemented with care it could also be very de-motivating, especially for a well-intentioned contributor. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 03:11:36PM -0400, Andrew Halberstadt wrote: On 21/04/15 03:02 PM, Aaron Klotz wrote: On 4/21/2015 12:50 PM, Andrew Halberstadt wrote: This could be effective, but if not implemented with care it could also be very de-motivating, especially for a well-intentioned contributor. Is this really an issue though, given the time and effort required to earn sufficient commit access to push to inbound? It's the patch author that is on the hook for bustage, not the pusher. Any contributor can land a patch on inbound by setting 'checkin-needed' on the bug. I'd say its more on the pusher than the patch author actually. But contributors aside, it could be de-motivating for employees too. If I break inbound, I already feel really bad about it.. no need to rub it in my that's probably a mistake, as said up thread if you never break it you are probably using try too much. You shouldn't feel bad about expected things. face :). If there are employees who are blatantly abusing inbound and don't seem to care about other people's time, perhaps a private e-mail to them and/or their manager would be a more appropriate response. I think most people would rather adjust there usage of try before things need to escalate to that level. Trev -Andrew ___ 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: Change coming to ftp.mozilla.org
This form has some issues. There are required sections of Downloading with scripts and other programs that only make sense for developers of the script or download tool. - Which protocols do you use ? (no idea whatever mozregression uses) - Please describe what your scripts/programs/scrapers do - If you are scraping directory listings, an API to lookup files would be The above are all required but my input on them would skew the results as I don't actively develop those tools. Kevin On Tue, Apr 21, 2015 at 1:29 AM, Nick Thomas ntho...@mozilla.com wrote: ftp.mozilla.org has been around for a long time in the world of Mozilla, dating back to original source release in 1998. Originally it was a single server, but it’s grown into a cluster storing more than 60TB of data, and serving more than a gigabit/s in traffic. Many projects store their files there, and there must be a wide range of ways that people use the cluster. This quarter there is a project in the Cloud Services team to move ftp.mozilla.org (and related systems) to the cloud, which Release Engineering is helping with. It would be very helpful to know what functionality people are relying on, so please complete this survey to let us know: http://bit.ly/1K0Ix0a Thanks, Nick Thomas (Mozilla Release Engineering) ___ 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: Excessive inbound bustage
On 21/04/15 03:02 PM, Aaron Klotz wrote: On 4/21/2015 12:50 PM, Andrew Halberstadt wrote: This could be effective, but if not implemented with care it could also be very de-motivating, especially for a well-intentioned contributor. Is this really an issue though, given the time and effort required to earn sufficient commit access to push to inbound? It's the patch author that is on the hook for bustage, not the pusher. Any contributor can land a patch on inbound by setting 'checkin-needed' on the bug. But contributors aside, it could be de-motivating for employees too. If I break inbound, I already feel really bad about it.. no need to rub it in my face :). If there are employees who are blatantly abusing inbound and don't seem to care about other people's time, perhaps a private e-mail to them and/or their manager would be a more appropriate response. -Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On 4/21/2015 1:11 PM, Andrew Halberstadt wrote: On 21/04/15 03:02 PM, Aaron Klotz wrote: On 4/21/2015 12:50 PM, Andrew Halberstadt wrote: This could be effective, but if not implemented with care it could also be very de-motivating, especially for a well-intentioned contributor. Is this really an issue though, given the time and effort required to earn sufficient commit access to push to inbound? It's the patch author that is on the hook for bustage, not the pusher. Any contributor can land a patch on inbound by setting 'checkin-needed' on the bug. I don't think there is an official policy on this, but I won't land a patch on behalf of a contributor without either building it myself or a green try push. IIRC I have been asked by the sheriffs to provide a try push if I've requested a push via flagging checkin-needed. I think that it's only fair that when asking somebody else to use their creds to push to inbound, patch authors should first do their best to demonstrate that their patch builds. Do we need to (or should we) formalize this? But contributors aside, it could be de-motivating for employees too. If I break inbound, I already feel really bad about it.. no need to rub it in my face :). If there are employees who are blatantly abusing inbound and don't seem to care about other people's time, perhaps a private e-mail to them and/or their manager would be a more appropriate response. Sure, a valid point. A public shaming is not necessary. - Aaron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On 21/04/2015 08:25, Gabor Krizsanits wrote: Maybe because I usually work on core, and such confidence is hard to reach there, but I'd like to think at least a try run that check if the patch builds on all platform and a full test run on at least one platform is not too much sacrifice of ones time. Personally I think that my time is cheaper than everyone's time. It is slow. It is annoying, but holding up ALL the other patches/developers is expensive hence a risky option. So I suggest everyone to be very conservative about that confident feeling. I agree; since I work mostly on patches that are relevant for FxOS/B2G I always run a try build across all architectures before to ensure it doesn't break anything else. Somehow I was under the impression that everybody did that. Gabriele signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
Very briefly: On 21/04/15 12:43, skuldw...@gmail.com wrote: 1. User downloads a browser (be it Firefox, Chrome, Opera, etc.) securely (https?) from the official download location. 2. Upon installation a private key is created for that browser installation and signed by the browser's certificate server. This makes checking in with the browser maker a necessary prerequisite for secure connections. That has problems. 3. When the user later connect to a server that support automatic encryption, the browser sends a (public) session key that the server should use, this key is signed with the browser installation key, the server can verify the signature and that this key is not modified by checking the certificate server. What you just built is a unique identifier for every browser which can be tracked across sites. 4. The server exchanges it's session key with the browser. 5. A secure/encrypted connection is now possible. Except that the browser has not yet identified the site. It is important for the user to check the site is genuine before the user sends any important information to it. The benefit is that there is no server side certificates needed to establish a encrypted connection. They are needed if the user wants to have any confidence in who they are actually talking to. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On 2015-04-21 6:43 AM, skuldw...@gmail.com wrote: I know, not that well explained and over simplified. But the concept is hopefully clear, but in case it's not... For what it's worth, a lot of really smart people have been thinking about this problem for a while and there aren't a lot of easy buckets left on this court. Even if we had the option of starting with a clean slate it's not clear how much better we could do, and scrubbing the internet's security posture down to the metal and starting over isn't really an option. We have to work to improve the internet as we find it, imperfections and tradeoffs and all. Just to add to this discussion, one point made to me in private was that HTTPS-everywhere defangs the network-level malware-prevention tools a lot of corporate/enterprise networks use. My reply was that those same companies have tools available to preinstall certificates in browsers they deploy internally - most (all?) networking-hardware companies will sell you tools to MITM your own employees - which would be an acceptable solution in those environments where that's considered an acceptable solution, and not a thing to block on. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tuesday, April 21, 2015 at 3:03:37 AM UTC-5, Gabriele Svelto wrote: On 21/04/2015 08:25, Gabor Krizsanits wrote: Maybe because I usually work on core, and such confidence is hard to reach there, but I'd like to think at least a try run that check if the patch builds on all platform and a full test run on at least one platform is not too much sacrifice of ones time. Personally I think that my time is cheaper than everyone's time. It is slow. It is annoying, but holding up ALL the other patches/developers is expensive hence a risky option. So I suggest everyone to be very conservative about that confident feeling. I agree; since I work mostly on patches that are relevant for FxOS/B2G I always run a try build across all architectures before to ensure it doesn't break anything else. Somehow I was under the impression that everybody did that. Gabriele I think this should be standard procedure for anyone working on platform. A push to try for a base set of builds (mac, linux, win, b2g ics) plus a good set of tests (usually for me it's mochitests) covers things. Once those mostly complete I can mark the bug with check-needed and walk away, tree drivers will handle the landing when inbound is open and green. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 8:39 AM, jmath...@mozilla.com wrote: On Tuesday, April 21, 2015 at 3:03:37 AM UTC-5, Gabriele Svelto wrote: On 21/04/2015 08:25, Gabor Krizsanits wrote: Maybe because I usually work on core, and such confidence is hard to reach there, but I'd like to think at least a try run that check if the patch builds on all platform and a full test run on at least one platform is not too much sacrifice of ones time. Personally I think that my time is cheaper than everyone's time. It is slow. It is annoying, but holding up ALL the other patches/developers is expensive hence a risky option. So I suggest everyone to be very conservative about that confident feeling. I agree; since I work mostly on patches that are relevant for FxOS/B2G I always run a try build across all architectures before to ensure it doesn't break anything else. Somehow I was under the impression that everybody did that. Gabriele I think this should be standard procedure for anyone working on platform. A push to try for a base set of builds (mac, linux, win, b2g ics) plus a good set of tests (usually for me it's mochitests) covers things. Once those mostly complete I can mark the bug with check-needed and walk away, tree drivers will handle the landing when inbound is open and green. Isn't the point of inbound supposed to be that it's safe to land even without 100% confidence? Here's the guidance from the Wiki: https://wiki.mozilla.org/Tree_Rules/Inbound Integration repositories are no replacement for Try. You still need to test your patches before pushing. (This doesn't mean that you need an all-platforms try run for every patch. But it does mean that you should do enough testing so that you rarely cause red or orange on the integration repository. But breaking it rarely is ok. Never missing a plane means you're spending too much time in airports; never breaking the tree means you're running too many tests before landing.) -Ekr ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 3:29 PM, Robert O'Callahan rob...@ocallahan.org wrote: Right. Someone just needs to collect the data *privately* and then notify people or take other remedial action. Personally, I'd much rather keep an eye on the leaderboard and police myself, rather than waiting for somebody to send me an email about it. I might be being too conservative too, and I'd like to aim to be exactly at the mean. :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 4:06 PM, L. David Baron dba...@dbaron.org wrote: I think it would be good to have metrics on rates at which different people break inbound, partly because I think the system works better when people use a similar amount of care to each other (as opposed to some people being less careful and breaking inbound a lot, and others being very careful and doing lots of try runs). The metrics are useful to give customized advice to different developers, as opposed to providing general advice (use try more to avoid breaking inbound / use try less to avoid wasting resources) that's wrong for many people. + 1 I'd find it very useful to know where I fall on the scale of breaking inbound too often vs. using too much Try resources, and adjust my practices accordingly. I suspect many others would too. Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 3:22 PM, Bobby Holley bobbyhol...@gmail.com wrote: It's not about making mistakes - it's about being mis-calibrated with respect to the rest of the development community. And it's not about shaming - it's about making people (both the developer and others) aware of these mismatches so that they can be corrected. And this can surely be done via private channels, without public shaming and the potential negatives people have listed elsewhere in the thread, right? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
I think it would be good to have metrics on rates at which different people break inbound, partly because I think the system works better when people use a similar amount of care to each other (as opposed to some people being less careful and breaking inbound a lot, and others being very careful and doing lots of try runs). The metrics are useful to give customized advice to different developers, as opposed to providing general advice (use try more to avoid breaking inbound / use try less to avoid wasting resources) that's wrong for many people. I think it would also be useful to extend the try high scores to all trees, so that it counts inbound (etc.) landings and backouts. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tuesday, April 21, 2015 at 2:11:43 PM UTC-5, Andrew Halberstadt wrote: On 21/04/15 03:02 PM, Aaron Klotz wrote: On 4/21/2015 12:50 PM, Andrew Halberstadt wrote: This could be effective, but if not implemented with care it could also be very de-motivating, especially for a well-intentioned contributor. Is this really an issue though, given the time and effort required to earn sufficient commit access to push to inbound? It's the patch author that is on the hook for bustage, not the pusher. Any contributor can land a patch on inbound by setting 'checkin-needed' on the bug. But contributors aside, it could be de-motivating for employees too. If I break inbound, I already feel really bad about it.. no need to rub it in my face :). I think we're being bit too sensitive here, I'm sure we can all handle a little public shaming on stuff like this. :) If you find yourself on the top of a list like list, and you feel a bit bad about it, good. Learn from it, push to try more often. That's the whole point. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
We now throttle requestAnimationFrame for offscreen iframes
Hi all, Bug 1145439 has landed, which means that we now throttle requestAnimationFrame for offscreen iframes. This should give us significant benefits in terms of CPU and energy usage for pages with iframes that do animation - think HTML5 ads. One test, on areweflashyet.com, showed a 50% improvement in CPU usage for both the content and chrome processes when the iframe is scrolled offscreen, compared to the same situation without throttling. This behavior is allowed by the spec, but of course spec compatibility and web compatibility are two different things. (Not to mention there could be bugs!) If you notice any odd behavior that could be a result of this change, please file it and block bug 1145439. Thanks! - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 03:11:36PM -0400, Andrew Halberstadt wrote: On 21/04/15 03:02 PM, Aaron Klotz wrote: On 4/21/2015 12:50 PM, Andrew Halberstadt wrote: This could be effective, but if not implemented with care it could also be very de-motivating, especially for a well-intentioned contributor. Is this really an issue though, given the time and effort required to earn sufficient commit access to push to inbound? It's the patch author that is on the hook for bustage, not the pusher. Any contributor can land a patch on inbound by setting 'checkin-needed' on the bug. But contributors aside, it could be de-motivating for employees too. If I break inbound, I already feel really bad about it.. no need to rub it in my face :). If there are employees who are blatantly abusing inbound and don't seem to care about other people's time, perhaps a private e-mail to them and/or their manager would be a more appropriate response. I don't think it's really a problem from that perspective. OTOH, it's something that is not necessarily easy to quantify accurately, because oftentimes, things are backed out that are *not* involved in bustage (just because there are several candidates and they're all backed out at once to unbust more quickly), although I guess they're relanded unchanged right afterwards. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Wed, Apr 22, 2015 at 7:11 AM, Andrew Halberstadt ahalberst...@mozilla.com wrote: But contributors aside, it could be de-motivating for employees too. If I break inbound, I already feel really bad about it.. no need to rub it in my face :). If there are employees who are blatantly abusing inbound and don't seem to care about other people's time, perhaps a private e-mail to them and/or their manager would be a more appropriate response. Right. Someone just needs to collect the data *privately* and then notify people or take other remedial action. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 3:05 PM, Mike Hoye mh...@mozilla.com wrote: On 2015-04-21 4:56 PM, jmath...@mozilla.com wrote: I think we're being bit too sensitive here, I'm sure we can all handle a little public shaming on stuff like this. We should not do this. There aren't a lot of things that will rot organizational morale and make people risk-averse faster and more permanently than publicly shaming people who make mistakes. It's not about making mistakes - it's about being mis-calibrated with respect to the rest of the development community. And it's not about shaming - it's about making people (both the developer and others) aware of these mismatches so that they can be corrected. When try high score came out, we noticed that a huge amount of try infrastructure was being used by b2g devs on |-p all -u all| try runs for code that wasn't run on 95% of the jobs they were triggering. When we inquired about it, it turns out that these devs were targeting devices that weren't supported by try syntax, and were told to just use full try runs for now. Once the problem was in plain view, it got fixed much more quickly than it probably would have otherwise. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 03:31:28PM -0700, Bobby Holley wrote: On Tue, Apr 21, 2015 at 3:29 PM, Robert O'Callahan rob...@ocallahan.org wrote: Right. Someone just needs to collect the data *privately* and then notify people or take other remedial action. Personally, I'd much rather keep an eye on the leaderboard and police myself, rather than waiting for somebody to send me an email about it. I might be being too conservative too, and I'd like to aim to be exactly at the mean. :-) I was about to write this and something similar to what Bobby said to Nick, but he beat me to both. Trev ___ 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: Excessive inbound bustage
On Tue, Apr 21, 2015 at 3:43 PM, Ryan VanderMeulen rya...@gmail.com wrote: Seeing how often I get pushback from people over backouts, I wouldn't agree with this premise, FWIW. People, remember to *thank* the person who backs out your code. Just like you should thank people for finding your bugs. Better now than later. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On 4/21/15 5:26 PM, Mike Hommey wrote: ... - the biggest backout rate for those authors is 48.8%. The suspense is killing me. Is it Ehsan?! ;-) ;-) Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 10:39 PM, Justin Dolske dol...@mozilla.com wrote: On 4/21/15 5:26 PM, Mike Hommey wrote: ... - the biggest backout rate for those authors is 48.8%. The suspense is killing me. Is it Ehsan?! ;-) ;-) Clearly not: On Tue, Apr 21, 2015 at 8:26 PM, Mike Hommey m...@glandium.org wrote: by raw number, ehsan is 2nd with 47 backouts... but he also landed 594 changesets, so his rate is only slightly above the median. ;-) Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
AsyncPanZoom enabled for one Nightly - 4/22/2015 - Windows E10S only
To get some feedback on AsyncPanZoom we are enabling it on tonight's nightly, for Windows only. It will be re-disabled in the next nightly. For those unfamiliar, APZ makes scrolling responsive by pre-rendering more content than what is visible in the viewport [1]. This lets us present it asynchronously without blocking on the content thread. To use APZ you just need E10S, and to scroll with a mouse wheel or a trackpad/touchpad. (Arrow or page dn/up keys do not trigger APZ.) We're interested in any significant behavior changes with APZ, and especially any situations in which we can't pre-render content fast enough. In this case you might see blank white areas of the screen while scrolling (aka checkerboarding). Please file any sites you find this way against the paint-fast bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1154825 If needed you can flip the APZ pref manually with layers.async-pan-zoom.enabled. It requires a browser restart. If you want to test whether you have APZ working, I've made a test site that will jank normal Firefox pretty badly [2]. With APZ+E10S, it should scroll fine. [1] https://wiki.mozilla.org/Platform/GFX/APZ [2] http://users.alliedmods.net/~dvander/apzc.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
I personally have no objection to my name being publicly visible on the list. I don't care either way about the ability to see other people's names, as long as I know where I stand. Oh, and if we want to remain anonymous, I'm sure we can all be randomly affected city names or whatever. This will give us a bit of recognition (hey, I'm better than Moscow this week), plus the ability to leak our nicknames to whomever we want. Cheers, David On 22/04/15 00:45, Nick Fitzgerald wrote: I imagine that we could show mean/median/percentiles/whatever, but you're right that if you want to specifically compare with another person you can't have anonymized data. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 3:32 PM, Nick Fitzgerald nfitzger...@mozilla.com wrote: And this can surely be done via private channels, without public shaming and the potential negatives people have listed elsewhere in the thread, right? How, exactly?I want the ability to see where I match up against my peers. Names are important here, and anonymization does a disservice to my interpretation of the data. Seeing names on try score of people I know are doing similar kinds of work is very helpful to gauge my relative usage. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On 4/21/2015 4:56 PM, jmath...@mozilla.com wrote: I think we're being bit too sensitive here, I'm sure we can all handle a little public shaming on stuff like this. :) If you find yourself on the top of a list like list, and you feel a bit bad about it, good. Learn from it, push to try more often. That's the whole point. Seeing how often I get pushback from people over backouts, I wouldn't agree with this premise, FWIW. -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 3:39 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Tue, Apr 21, 2015 at 3:32 PM, Nick Fitzgerald nfitzger...@mozilla.com wrote: And this can surely be done via private channels, without public shaming and the potential negatives people have listed elsewhere in the thread, right? How, exactly?I want the ability to see where I match up against my peers. Names are important here, and anonymization does a disservice to my interpretation of the data. Seeing names on try score of people I know are doing similar kinds of work is very helpful to gauge my relative usage. I imagine that we could show mean/median/percentiles/whatever, but you're right that if you want to specifically compare with another person you can't have anonymized data. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 02:50:43PM -0400, Andrew Halberstadt wrote: On 21/04/15 02:41 PM, Chris Peterson wrote: On 4/21/15 11:27 AM, Ehsan Akhgari wrote: I agree that it shouldn't be 10%. Hopefully once we have the autolander this will be a non-issue. It would be a huge help if someone made a little tool which would show you how often one specific person breaks inbound. I would definitely like to know whether I'm closer to 10% or 100% myself. Something like the Try High Score ranking for inbound backouts would be straightforward to automate: https://secure.pub.build.mozilla.org/builddata/reports/reportor/daily/highscores/highscores.html This could be effective, but if not implemented with care it could also be very de-motivating, especially for a well-intentioned contributor. Here are a few crude stats, gathered over the last 25271 changesets, assuming my pattern matching worked properly: - 1438 changesets were backed out (~5.7%) - 123 of those backouts were for changes whose authors have less than 10 changesets in the range. The total number of changesets from those authors all grouped together is 405, so ~30.4% backout rate for people with few patches. There are 83 authors in this category. - there are 214 authors with 10 changesets or more in the range. - the median backout rate for those 214 authors is 7.7%. - the average backout rate for the same authors is 10.5%. There are 76 authors above average. - there are 27 of those authors above 20% backout rate. - there are 11 of those authors above 30% backout rate. - the biggest backout rate for those authors is 48.8%. I took 10 changesets as an arbitrary limit below which the rate is not really interesting. Note authors are determined by email address and are not deduped (if people are using different email addresses, they count as multiple authors) To give an example why I took the backout rate instead of the raw number: by raw number, ehsan is 2nd with 47 backouts... but he also landed 594 changesets, so his rate is only slightly above the median. Also, the biggest backout rate if counting all authors is 100%: a few people have had one patch landed and backed out. That being said, the median and average above are only considering authors with 10 and more changesets in the last 25271 for whom there *was* a backout. If taking everyone into account, the median backout rate is... 0. The average is ~6.7%. And for what it's worth, excluding sheriffs and b2gbumper, the biggest number of changesets pushed by someone without a backout in the last 25271 changesets is 126. There are only 38 authors, of the total 827 with more changesets pushed. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Wed, Apr 22, 2015 at 09:26:12AM +0900, Mike Hommey wrote: On Tue, Apr 21, 2015 at 02:50:43PM -0400, Andrew Halberstadt wrote: On 21/04/15 02:41 PM, Chris Peterson wrote: On 4/21/15 11:27 AM, Ehsan Akhgari wrote: I agree that it shouldn't be 10%. Hopefully once we have the autolander this will be a non-issue. It would be a huge help if someone made a little tool which would show you how often one specific person breaks inbound. I would definitely like to know whether I'm closer to 10% or 100% myself. Something like the Try High Score ranking for inbound backouts would be straightforward to automate: https://secure.pub.build.mozilla.org/builddata/reports/reportor/daily/highscores/highscores.html This could be effective, but if not implemented with care it could also be very de-motivating, especially for a well-intentioned contributor. Here are a few crude stats, gathered over the last 25271 changesets, assuming my pattern matching worked properly: - 1438 changesets were backed out (~5.7%) - 123 of those backouts were for changes whose authors have less than 10 changesets in the range. The total number of changesets from those authors all grouped together is 405, so ~30.4% backout rate for people with few patches. There are 83 authors in this category. - there are 214 authors with 10 changesets or more in the range. 214 authors with 10 changesets of more in the range *and* at least one of them backed out. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote: In order to encourage web developers to move from HTTP to HTTPS, I would like to propose establishing a deprecation plan for HTTP without security. I think server side SSL certificates should be deprecated as a means to encrypt a connection. Ideally this is what should happen: 1. User downloads a browser (be it Firefox, Chrome, Opera, etc.) securely (https?) from the official download location. 2. Upon installation a private key is created for that browser installation and signed by the browser's certificate server. 3. When the user later connect to a server that support automatic encryption, the browser sends a (public) session key that the server should use, this key is signed with the browser installation key, the server can verify the signature and that this key is not modified by checking the certificate server. 4. The server exchanges it's session key with the browser. 5. A secure/encrypted connection is now possible. I know, not that well explained and over simplified. But the concept is hopefully clear, but in case it's not... This is today's server certificates system but in reverse. This concept does not replace https as it is today, but does allow free encrypted connections. Web designers, hosting companies etc only need to ensure their server software is up to date and are able to support this. The benefit is that there is no server side certificates needed to establish a encrypted connection. The browser/client installation certificate can easily be changed each time a browser is updated. And can be set to expire within a certain number of months. Not sure what to call this concept. Reverse-HTTPS maybe? RHTTPS for short? Traditional serverside certificates are still needed, especially the green bar ones. And free basic ones like StartSSL gives out are still of use, to allow old browsers to use HTTPS, and to support a fallback in case a browser certificate has expired (and still allow a secure connection). The issue today (even with free certificates like StartSSL gives out) is that webmasters ans hosting companies have to do a yearly dance to update the certificates. And not all hosting companies support HTTPS for all their packages. Sites that make some profit can probably afford to pay for the extra HTTPS feature and pay for a certificate. Myself I'm lucky in that my host provides free HTTPS support for the particular package I have (though not for the smallest package). My concept has a flaw though. Browser makers need to set up their own certificate server to sign the generated browser installation keys. And server software (Apache, nginx, etc.) need to support a type of RHTTPS so they can send a session key to the browser. The benefit though is that servers do not need a certificate installed to create a encrypted connection. Further security could be built on top of this where the server or client or both have authenticated certificate (so that there is not only a encrypted connection but also identified server and client) A concept like RHTTPS would allow a slow migration with no direct need for webmasters nor browser users to change anything themselves, with zero cost to webmasters/hosters nor the end users. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RFC: Navigation transitions
Hi people, I've spent the last week or so articulating some thoughts on navigation transitions. This is something I've thought about before (as I'm sure a lot of us have), but seeing Google's proposal encouraged me to get it written down. I'm not a huge fan of all aspects of their proposal, so I've made my own: http://chrislord.net/?p=273preview=1_ppp=0afe20d87f I think my proposal is simpler to understand and simpler to implement (indeed, I've made a small library that partially implements this outside of the browser - currently this only works in Gecko browsers though), though more limited than Google's proposal on the surface. This is geared towards making simple transitions (sliding, fading) very easy to implement, but without precluding more complex multi-part animations. I'd appreciate any feedback (even if it's You're an idiot and this is not how we go about this) before taking this any further. Cheers, --Chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On 2015-04-21 3:30 PM, Aaron Klotz wrote: Sure, a valid point. A public shaming is not necessary. I think people may have misunderstood what I suggested. How about a tool that lets you login through Persona and then tells you (and only you) how well you're doing? :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/2015 06:07 PM, Eric Rescorla wrote: On Tue, Apr 21, 2015 at 8:39 AM, jmath...@mozilla.com wrote: On Tuesday, April 21, 2015 at 3:03:37 AM UTC-5, Gabriele Svelto wrote: On 21/04/2015 08:25, Gabor Krizsanits wrote: Maybe because I usually work on core, and such confidence is hard to reach there, but I'd like to think at least a try run that check if the patch builds on all platform and a full test run on at least one platform is not too much sacrifice of ones time. Personally I think that my time is cheaper than everyone's time. It is slow. It is annoying, but holding up ALL the other patches/developers is expensive hence a risky option. So I suggest everyone to be very conservative about that confident feeling. I agree; since I work mostly on patches that are relevant for FxOS/B2G I always run a try build across all architectures before to ensure it doesn't break anything else. Somehow I was under the impression that everybody did that. Gabriele I think this should be standard procedure for anyone working on platform. A push to try for a base set of builds (mac, linux, win, b2g ics) plus a good set of tests (usually for me it's mochitests) covers things. Once those mostly complete I can mark the bug with check-needed and walk away, tree drivers will handle the landing when inbound is open and green. Isn't the point of inbound supposed to be that it's safe to land even without 100% confidence? Here's the guidance from the Wiki: without 100% doesn't mean with 10%, which is what it feel like nowadays. Tryserver time is machine time; inbound bustage is people time, and the latter is much more expensive. Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJVNndkAAoJEOXgvIL+s8n279YIAJ+t5zHBzNGUuPCUmvG85s4Z b45iDaMbE06OfN4mNGOc1zAU61qonNszqLmLatzrK03BQXoqCRJRGRiWoHAQnOLN zHUS2u6T/UA6REbFBJyJmOqFx7Xd93RnbFUHOPLc/zQcUNwobr8pm/tjnfPxLuju X0cdtFtSr1O0a968+q/BYpbARH4KTJhJGxSoVtaKIQx4Gp3xPW3TZwiTT3OdtLeW AGFQj2TOoAEOyxUvyawfMbAr5WPe6dwPdlE0GH8L+mDmSZERo15KBz44SywK719y 0cE1+yw13pVb8CNA1uKY6rDqWxiIYxPs4CEvM3KFMulb0HZl/vh7qCMtDZ+GuHY= =D0/Q -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tue, Apr 21, 2015 at 12:14 PM, Ms2ger ms2...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/2015 06:07 PM, Eric Rescorla wrote: On Tue, Apr 21, 2015 at 8:39 AM, jmath...@mozilla.com wrote: On Tuesday, April 21, 2015 at 3:03:37 AM UTC-5, Gabriele Svelto wrote: On 21/04/2015 08:25, Gabor Krizsanits wrote: Maybe because I usually work on core, and such confidence is hard to reach there, but I'd like to think at least a try run that check if the patch builds on all platform and a full test run on at least one platform is not too much sacrifice of ones time. Personally I think that my time is cheaper than everyone's time. It is slow. It is annoying, but holding up ALL the other patches/developers is expensive hence a risky option. So I suggest everyone to be very conservative about that confident feeling. I agree; since I work mostly on patches that are relevant for FxOS/B2G I always run a try build across all architectures before to ensure it doesn't break anything else. Somehow I was under the impression that everybody did that. Gabriele I think this should be standard procedure for anyone working on platform. A push to try for a base set of builds (mac, linux, win, b2g ics) plus a good set of tests (usually for me it's mochitests) covers things. Once those mostly complete I can mark the bug with check-needed and walk away, tree drivers will handle the landing when inbound is open and green. Isn't the point of inbound supposed to be that it's safe to land even without 100% confidence? Here's the guidance from the Wiki: without 100% doesn't mean with 10%, which is what it feel like nowadays. Tryserver time is machine time; inbound bustage is people time, and the latter is much more expensive. I agree that it shouldn't be 10%. Hopefully once we have the autolander this will be a non-issue. -Ekr ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
