Mon 14 Jul 2014
Last week saw the latest face to face of the WebDriver Working Group held at Facebook. This meeting was important as this is hopefully the last face to face before we go to Last call allowing us to concentrate on issues that come up during last call.
This meeting was really useful as we were a number of discussions around the prose of the spec when it comes to conformance and usability of the spec, especially when given to implementors who have never worked on WebDriver.
The Agenda from the meeting can be found here
The notable items that were discussed are:
- Merge getLocation and getSize to single call called getElementRect. This has been implemented in FirefoxDriver already
- Describe restrictions around localhost in security section
- How the conformance test will look (Microsoft have a huge raft tests they are cleaning up and getting ready to upstream!)
- Actions has been tweaked from the original straw man delivered by Mozilla, hopefully see the new version in the next few weeks.
To read what was discussed you can see the notes for Monday and Tuesday.
Mon 14 Jul 2014
I have just released the latest version of Bugsy. This allows you to get comments from Bugzilla and add new comments too. This API is still experimental so please send back some feedback since I may change it to real world usage.
I have updated the documentation to get you started.
>>> comments = bug.get_comments()
"I <3 Cheese"
>>> bug.add_comment("And I love bacon")
You can see the Changelog for more details.
Please raise issues on GitHub
Thu 26 Jun 2014
I have updated Bugsy to now have the ability to search Bugzilla in a meaningful way. I have updated the documentation to get you started.
For example to search Bugzilla you would do
>>> bugs = bugzilla.search_for\
You can see the Changelog for more details..
Please raise issues on GitHub
Mon 16 Jun 2014
I have created a library for interacting with Bugzilla using the native REST API. Bugsy allows you to get bugs from Bugzilla, change what you need to and then post it back to Bugzilla. I have created documentation to get you started.
For example to get a bug you would do
bugzilla = bugsy.Bugsy()
bug = bugzilla.get(123456)
and then to put it back, or if there is no bug ID (like if you were creating it) then you would do
bug = bugsy.Bug()
bug.summary = "I really realy love cheese"
bug.add_comment("and I really want sausages with it!")
bugzilla = bugsy.Bugsy("username", "password")
bug.id #returns the bug id from Bugzilla
Searching Bugzilla is not currently supported but will definitely be there for the next version.
Please raise issues on GitHub
Thu 05 Jun 2014
The other week I tweeted I was noticing for that day we had 1 revert push to Mozilla Inbound in every 10 pushes. For those that don't know, Mozilla Inbound is the most active integration repository that Firefox code lands in. A push can contain a number of commits depending on the bug or if a sheriff is handling checkin-needed bugs.
This tweet got replies like, and I am paraphrasing, "That's not too bad", "I expected it to be worse". Personally I think this is awful rate. Why? On that day, only 80% of pushes were code changes to the tree. The bad push and the revert leads to no changes to the tree but still uses our build and test infrastructure. This mean that at best we can(on that day) only be 80% efficient. So how can we fix this?
Note: A lot of this work is already in hand but I want to document where I wish them to go. A lot of the issues are really paper cuts but it can be death by 1000 paper cuts.
Mach, the current CLI dispatch tool at Mozilla, passes the build detail to the build scripts. It is a great tool if you haven't been using it yet. The work the build peers have done with this is pretty amazing. However I do wish the build targets passed to Mach and then executed were aligned with the way that Chromium, Facebook, Twitter and Google build targets worked.
For example, working on Marionette, if I want run marionette tests I would do |./mach //testing/marionette:test| instead of the current |./mach marionette-test| . By passing in the directory we are declaring what we want explicitly to be built and test.. The moz.build file should have a dependency saying that we need a firefox binary (or apk or b2g). The test task in the moz.build in testing/marionette folder would pick runtests.py and then pass in the necessary arguments ideally based on items in the MozConfig. Knowing the relevant arguments based on the build is hard work involving looking at your history or at a wiki.
Working on something where it has unit tests and mochitests or xpcshell tests? It's simple to just change the task. E.g. ./mach //testing/marionette:test changes quickly to //testing/marionette:xpcshell. Again, not worrying about arguments when we can create sane defaults based on what we just built. I have used testing in my examples because it is simple to show different build targets on the same call.
The other reason declaring the path (and mentioning the dependencies in the same manner) is that if you call |./mach //testing/marionette:test| after updating your repo it will do an incremental build (or a clobber if needed) without you knowing you needed it. Manually clearing things or running builds just to run tests is just busy work again.
Reviews and Precommit builds/tests
Want a review? You currently either have to use bzexport or manually create a diff and upload it to the bug and set the reviewer. The Bugzilla team are working to stand up review board that would allow us to upload patches and has a gives us a better review tool.
The missing pieces for me are: 1)We have to manually pick a reviewer and 2) that we don't have a pre commit build and test step.
1) I have been using Opera's Critic for reviewing Web Platform Tests. Having the ability to assign people to review changes for a directory means that reviewing is everyones responsibility. Currently Bugzilla allows you to pick a reviewer based on the component that the bug is on. Sometimes a patch may span other areas and you then need to figure out who a reviewer should be. I think that we can do better here.
As for 2) don't necessarily need to do everything but the equivalent of a T-Style run would suffice I'm my opinion. We could even work to pair this down more to be literally a handful of tests that regularly catch bugs or make it run tests based on where the patch was landing.
Why does this matter, we have try that people can use and "my code works" and "it was reviewed, it will compile". Mozilla Inbound was closed for a total of 2 days (48+ hours) in April and 1 day (24hrs) in May. At the moment I only have the data on why the tree was closed, not the individual bugs that caused the failure, but a pre commit step would definitely limit the damage. The pre commit step might also catch some of the test failures (if we had test suites we could agree on for being the smoke test suite) which had Mozilla Inbound closed for over 2 1/2 (61+ Hours) days in April and over 3 days (72+ hours) in May.
Once the review has passed we still have to manually push the code or set a keyword in the bug (checkin-needed) so that the sheriffs can land it. This manual step is just busy work really that isn't really needed. If something has a r+ then ideally we should be queueing this up to be landed. This is minor compared to manual step required to update the bug with the SHA when it has landed, when it is landed we should be updating the bug accordingly. It's not really that hard to do.
Unneeded manual steps have an impact on engineering productivity which have a financial cost that could be avoided.
I think the main reason why a lot of these issues have never been surfaced is there is not enough data to show the issues. I have created a dashboard, only has the items I care about currently but could easily be expanded if people wanted to see other bits of information. The way we can solve the issues above is being able to show the issues.
Thu 01 May 2014
The Automation and Tools team at Mozilla has been working tirelessly to find some bugs that everyone can work on if you are stuck at home with rain. Our collection of good first bugs has been curated and has a number of really great mentors that can help get you started on the path to submitting a patch.
Wondering if it is worthwhile? My post last week asking for people to help on Marionette Good First Bugs has had 2 patches landed in Mozilla-Central and people looking at another 3 bugs. The list only had 9 bugs so that is more than half that are being picked up.
The best way to do things is look at our New Contributor page and get all the necessary things setup. Unfortunately some items might take a little work but its just something you need to do once.
Want to work on some bugs? We have a great list that you can choose from.
I look forward to seeing some great patches from you all!
Mon 28 Apr 2014
Recently David Heinemeier Hansson (dhh) wrote a blog post called "TDD is dead, long live testing". He describes how the TDD world has got mean spirited and perhaps the use of the technique was to break down the barriers of automated testing and regression testing but that is no longer the case. (I agree with this a little but there are a lot of angry people out there)
He then declares that he has had enough and declares that he does not write tests first and is proud of it.
This post has obviously had mixed reviews from people. A lot of the consultant types that I follow on twitter who are rather large advocates of TDD have said dhh shouldn't really be saying things like this. Their arguments have been around how hard it is to test rails applications because the underlying architecture doesn't allow it (Which distracts from the argument in my opinion!). The thing that David describes briefly is that we should not follow things dogmatically which is sound advice that everyone should follow. It's the same with best practises, don't follow them unless they make sense.
The amount of people who then started shouting from the roof tops that they don't test first and were proud of it grew quite quickly. I find this sentiment quite worrying. Why?
How do you trust a test that you have never seen fail?
If you have hundreds of thousands of tests that are run when you commit code you want there to be a very high probability that any regression will be caught. Writing tests after you have written the code can lead to a lot of tests that may never fail which take up huge amounts of resource that costs money. At the beginning of the year Mozilla would use ~200 computing hours per push to Mozilla Inbound (the main tree that holds the Firefox code). Thats A LOT of resource to be wasting on a test that you are not sure will ever catch anything. For what it is worth there a lot of tests in the Mozilla tree that may never catch anything but its hard to find them :(.
I know that you can't always write a test first, there are times where it is quite hard to do that, but making sure you have faith in your tests so that they actually do what you expect is the most important thing you can do.
dhh does say that not everything can be unit tested and I think this is the crux of his issue. He is, and a lot of other people, are getting hung up on labels for tests in my opinion. This then puts them off writing tests first. I have been a big fan of the way that Google labels their tests. This removes the dogmatic beliefs in TDD and describes them in how much work they are doing. This is the way we should be doing it!!!
So if you are going to not write a test first make sure that you are writing tests that you can trust and that your colleagues can trust too!
Fri 25 Apr 2014
I have been triaging Marionette ( The Mozilla implementation of WebDriver built into Gecko) bugs for the last few weeks. My goal is to drive the project, barring any unforeseen firedrills that my team may need to attend, to getting Marionette released.
While I have been triaging I have also been finding bugs that would be good for first time contributors to get stuck into the code and help me get this done.
So, if you want to do a bit of coding and help get this done please look at our list
I will be adding to it constantly so feel free to check back regularly!
Fri 21 Mar 2014
As the manager of the sheriffs I am always interested in how ofter the sheriffs, and anyone else, closes the tree. For those who don't know who the Mozilla Sheriffs are, they are the team that manage the code landing in a number of Mozilla trees. If a bad patch lands they are the people who typically back it out. There has been some recent changes in the way the infrastructure does things which has led to a few extra closures. Not having the data for this I went and got it (you can see the last year's worth of data for Mozilla-Inbound below)
no reason: 5 days, 12:13:31
total: 6 days, 3:13:09
no reason: 3 days, 19:30:21
total: 4 days, 17:51:39
infra: 1 day, 2:03:08
no reason: 4 days, 11:30:41
total: 5 days, 13:33:49
checkin-test: 1 day, 5:48:15
no reason: 5:05:59
total: 2 days, 15:42:37
checkin-compilation: 1 day, 13:05:52
checkin-test: 2 days, 16:43:53
infra: 1 day, 2:16:02
no reason: 0:30:13
total: 6 days, 13:46:11
checkin-compilation: 1 day, 23:49:34
checkin-test: 1 day, 12:32:35
total: 4 days, 5:42:17
checkin-compilation: 1 day, 8:27:27
checkin-test: 2 days, 15:17:50
total: 4 days, 20:59:41
checkin-test: 3 days, 10:41:33
no reason: 0:00:05
total: 4 days, 21:22:40
checkin-compilation: 1 day, 9:40:25
checkin-test: 4 days, 18:41:35
infra: 1 day, 19:11:36
no reason: 0:05:54
total: 8 days, 4:58:30
checkin-test: 1 day, 16:29:16
total: 2 days, 22:55:54
checkin-test: 1 day, 12:22:01
infra: 1 day, 5:37:14
no reason: 1:20:46
total: 4 days, 2:49:16
checkin-compilation: 1 day, 12:26:35
no reason: 0:00:16
total: 3 days, 3:34:07
checkin-test: 1 day, 0:37:55
total: 3 days, 3:38:24
I created a graph of the data showing Mozilla Inbound since we started using it in August 2012 till now.
The first part of the graph there wasn't any data for specific things but the sheriffs changed that in the middle of last year. I am hoping that we can get information like this, and other interesting back out info into a "Tree Health Report" in Treeherder (The TBPL replacement the Automation and Tools Team is developing).
Thu 13 Mar 2014
I have been a manager within the A*Team for 6 months now and I wanted to share what I have learnt in that time. The main thing that I have learnt is being a manager is hard work.
Why has it been hard?
Well, being a manager is requires a certain amount of personal skills. So being able to speak to people and check they are doing the tasks they are supposed to is trivial. You can be a "good" manager on this but being a great manager is knowing how to fix problems when members of your team aren't doing the things that you expect.
It's all about the people
As an engineer you learn how to break down hardware and software problems and solve them. Unfortunately breaking down problems with people in your team are nowhere near the same. Engineering skills can be taught, even if the person struggles at first, but people skills can't be taught in the same way.
Working at Mozilla I get to work with a very diverse group of people literally from all different parts of the world. This means that when speaking to people, what you say and how you say things can be taken in the wrong way. It can be the simplest of things that can go wrong.
Being a manager means that you are there to help shape peoples careers. Do a great job of it and the people that you manage will go far, do a bad job of it and you will stifle their careers and possibly make them leave the company. The team that I am in is highly skilled and highly sought after in the tech world so losing them isn't really an option.
Part of growing people's careers is asking for feedback and then acting upon that feedback. At Mozilla we have a process of setting goals and then measuring the impact of those goals on others. The others part is quite broad, from team mates to fellow paid contributors to unpaid contributors and the wider community. As a manager I need to give feedback on how I think they are doing. Personally I reach out to people who might be interacting with people I manage and get their thoughts.
But I don't stop at asking for feedback for the people I manage, I also ask for feedback about how I am doing from the people I manage. If you are a manager and never done this I highly recommend doing it. What you can learn about yourself in a 360 review is quite eye opening. You need to set ground rules like the feedback is private and confidential AND MUST NOT influence how you interact with that person in the future. Criticism is hard to receive but a manager is expected to be the adult in the room and if you don't act that way you head to the realm of a bad manager, a place you don't want to be.
So... do I still want to be a manager?
Definitely! Being a manager is hard work, let's not kid ourselves but seeing your team succeed and the joy on people's faces when they succeed is amazing.