In the beginning there was
fire buildbot. This was Wed, 13 Feb 2008 for the first commit in the repository buildbot-configs.
For context, at this time:
- python 2.5.2 was current (release Feb 21’st of that year)
- pip didn’t exist in anything resembling its current form (renamed from pyinstall to pip in Oct that year)
- python virtualenvironment was at v 1.0.1 (and was still hosted in svn)
- Firefox had released Version 220.127.116.11 (with 18.104.22.168 upcoming in March
- OSX 10.5 (Tiger) was current and did not yet support 64 bit. (source)
In picking buildbot as our tool we were improving vastly on the decade old technology we had at the time (tinderbox) which was also written in oft-confusing and not-as-shiny perl (we love to hate it now, but it was a good language) [see relevant: image of then-new cutting edge technology but strung together in clunky ways]
As such, we at Mozilla Release Engineering, while just starting to realize the benefits of CI for tests in our main products (like Firefox), were not accustomed to it.
We were writing our buildbot-related code in 3 main repositories at the time (buildbot-configs, buildbotcustom, and tools) all of which we still use today.
Fast forward 5 years and you would have seen a some common antipatterns in large codebases… (over 203k lines of code! ) It was hard to even read most code, let alone hack on it. Each patch was requiring lots of headspace. And we would consistently break things with patches that were not well tested. (even when we tried)
It was at a workweek here in 2013 that catlee got our group agreement on trying to improve that situation by continually running autopep8 over the codebase until there was no (or few) changes with each pass.
Thus began our first, attempt, at bringing our processes to what we call our modern practices.
This reduced, in buildbotcustom and tools alone our pep8 error rate from ~7,139 to ~1,999. (In contrast our current rate for those two repos is ~1485).
(NOTE: This is a good contributor piece, to drive pep8 errors/warnings down to 0 for any of our repos, such as these. We can then make our current tests fail if pep8 fails. Though newer repos started with pep8 compliance, older ones did not. See List of Repositories to pick some if you want to try. — Its not glorious work, but makes everyone more productive once its done.)
The one agreement we decided where pep8 wasn’t for us was line length, we have had many cases where a single line (or even url) barely fits in 80 characters for legit reasons, and felt that arbitrarily limiting variable names or depth just to satisfy that restriction was going to reduce readability. Therefore we generally use –max-line-length of ~159 when validating against pep8. (The above numbers do not account for –max-line-length)
Around this time we had also setup an internal only jenkins instance as a test for validating at least pep8 and its trends, we have since found jenkins to not be suitable for what we wanted.
Stay tuned to this blog for more history and how we arrived at some best practices that most don’t take for granted these days.