Please use TryChooser

Recently there were some improvements to the trychooser and the landing of those changes led to a couple of bugs[1][2] being discovered and quickly fixed.  It is thanks to those who are regularly using the trychooser that we are able to find bugs quickly and also continue to improve the tryserver.

Right now there are over 350 backed up test/talos requests for the tryserver and when I checked our report for trychooser usage it shows that the average number of users pushing with a try syntax has fallen below 50% where it used to be closer to 60%.

I encourage you to please use the trychooser syntax as much as possible. If you do not need every single try result for your patch, do not just push to try and use up all the resources needlessly. Take a moment to insert some try syntax into your commit message.

See https://wiki.mozilla.org/Build:TryChooser for details and http://people.mozilla.org/~lsblakk/trychooser/ for a simple try syntax builder.

Thanks in advance.

Impending TryChooser change you should know about

On Monday November 29th there will be a bug fix landed on the TryChooser that will change how you use it:

Removed: -m,--mobile argument for requesting mobile platforms.
ALL platform selections will use the -p,--platform argument (as requested by developers)

This change is part of a larger back-end change which will improve try by making new platforms or test/talos suites added to mozilla-central dynamically available to tryserver. This also means the Mozmill test suite will be enabled for try when this patch lands on Monday.

I will update the TryChooser wiki and the trychooser syntax web helper. If anyone is using other tools to help with using trychooser, please update accordingly.

What will be useful once this lands is a way to give a user-friendly, and dynamically-generated, list of what platforms/talos/test options are available to try. Any ideas?

Playing with Audio Visualization

After Dave's blog post put out the call for 50 visualizations using the new Audio API in Firefox 4 I decided it was time to stop thinking about learning processing and its .js version and time to start doing things with it.  So I took a few hours on Saturday to poke at the code that Dave put up and after a lot of shots in the dark I came up with this but I was disappointed in how simple my results seemed after so much time spent.  Today I went back to the book and learned a few more processing tricks which inspired me to hack on the audio visualizations again.

For my second attempt I really tried to understand more what the javascript functions were doing, how the actual audio data was being generated, and in what form it was being passed to the processing draw() function.  I found a couple of pages on the Mozilla Developer Network that helped me understand the API a bit better.  On my second attempt to visualize audio data I could really make it do what I wanted. The next round of learning I would like to do in this area is how to work with user interaction better. To respond with audio and video to user movements and key press events.

Second attempt at audio visualization

I'm really glad Dave put out the challenge, and that I made the time to teach myself something new.

Get more green with TryChooser!

Our fabulous intern Anamaria Stoica has been working hard the past few months helping to pull data from buildbot's scheduler DB that allows us to learn all sorts of new information about how the release infrastructure is being used, and how it could be optimized. Among other things, she's generated an end-to-end report so we can see at a glance how long the complete build cycle for any push to mozilla-central took.  Now, on top of that, she's added a way to see who is using the awesome new TryChooser syntax.

In the coming weeks I'll be emailing folks who are using try but not the TryChooser syntax and encouraging them to give it a shot. In my stock email letter I will say something along the lines of:

When you use the TryChooser syntax to make requests for only what you need, you allow precious CPU cycle time to be used elsewhere by those who need it.

This is helpful for two reasons:

1. Those testing fixes to blockers of the next beta/rc/release can get try results quickly and get their code landed on trunk
2. Overall wait times for try results are reduced

What's interesting in looking at the reports though is that more of the pushes to try that use TryChooser are green. Here's a snapshot of those who are using TryChooser:

The number of build requests is an aggregate of all the builders triggered so all build types, platforms, test and talos builders run on that push.

Now for comparison, here's a snapshot of folks not using the TryChooser:

I have no way of knowing from this snapshot which of those pushes were intentionally not using the TryChooser and perhaps trying to get all 176 possible builds. Some of them may be using custom mozconfigs as a way to kill off unwanted builds (p.s. you get burning with that).

If you haven't tried it yet, please give TryChooser a go and see if getting a smaller set of builds (ie: what you need, not just the default) and perhaps getting more green on you try pushes gives you a boost.

Try What You Want

Last week bug 473184 saw some progress when we landed the try_parser which allows devs to put in their hg commit comments what try builds they would like on a particular push. This is a first step towards a two-part goal: 1) giving devs more self-serve tools for try and 2) lowering try wait-times.

Now you can try what you want instead of just pushing and getting the default set (currently default is all opt & debug builds, all unittests, no talos).  You will get less emails and only the results you're looking for and everyone wins when you only ask for what you need since it will make more machines available for other builds.

To use this fabulous new TryChooser in your commit message (soon to be available in a committed config file as well) you do the following:

• You've got your patch ready to try
• Set the commit comment to what you would like to run on try
• In this case, let's say you want a linux opt build, no mobile, no unittests, and only talos tp4 results

hg commit -m "Patch to fix a pixel placement try: --build o --p linux --m none --u none --t tp4"

• Push to try
• What happens? 'Linux tryserver build' builder is created and runs your opt linux build. If the build completes successfully then the talos tests are triggered and once the test-master gets the notice of the change it will read the hg commit comments and only kick off the one builder for tp4 'Rev3 Fedora 12 tryserver talos tp4' 
• You get a total of 3 emails and have used very little compute time - you rock!

please go to http://wiki.mozilla.org/Build:TryChooser for complete info and options as well as some answers to questions you make have and take the TryChooser out for a spin.

No really, it *is* easy to test your Python code

This week is all about getting custom selection for tryserver submissions (bug 473184) ready for public consumption. The plan is to have a custom scheduler that calls a function which parses a commit comment (and later, the option of an .info file instead) and then only schedules the builders which have been requested. This will be awesome for our build machine resources since it will mean that if you don't want a particular platform/test/talos suite it will never even get triggered.

In today's work on the parser I wrote python unittests for the first time. I remember doing some unittests in school but that was way back when we used Java. The python unittest module is really awesome and easy to get up and running. Once I had my tests passing I then ran the coverage tool on both the test suite and the parser to see how I did in covering all my bases:

This tool is Frickin' Awesome! I can see at a glance that I need another test to see what happens if someone wants a subset of mobile build platforms.

Tomorrow I'll be getting my coverage even higher and then starting to stage this scheduler and see how it handles our large amount of possible builders to choose from. Keep your ears open - selecting your try build configuration is right around the corner.

Disposable Project Branches - aka Twigs

Hey Firefox Developers - Want a place that's kind of like Tryserver but all yours for a short period of time?  Release Engineering now has 3 'disposable' branches set up in our build automation that you can use for testing a mozilla-central clone or a clone of your own m-c-based repo.  I call them Twigs because they are for temporary, small projects.

The Twigs (maple, cedar, and birch) each have their own tinderbox pages, run the full suite of unittests, and give you talos results by default.  Like Tryserver, they also allow you to override the mozconfig with a custom mozconfig so that you could kill off platforms you are not interested in results for.  Doing so will give you a cleaner tree and will allow our build and test resources to be used where they are most needed.

To use a branch simply grab a twig from the bookings page, file an IT bug to have your repo cloned over to your selected twig repo and then start pushing to the twig's repo to see your builds start.  At the moment one small glitch is that the first push doesn't get you any builds (bug 562026) - so you need to push twice on a fresh repo clone and the second set will get picked up by the hg poller.

I look forward to hearing if this setup helps you out.