3 ms·

When I was in college (so like... almost as long ago as this bug was filed, yikes!) I spent a lot of time volunteering for Mozilla. I started out doing bug tria

When I was in college (so like... almost as long ago as this bug was filed, yikes!) I spent a lot of time volunteering for Mozilla. I started out doing bug triage for their QA team, which involved things like making sure it was in the proper Bugzilla component and had sane steps to reproduce and so on. Even this was very enlightening, as someone with absolutely zero real world experience. Seeing how a large scale project was run, watching how the "real" devs worked through fixes and features. Introducing concepts like diffs and patches and CI/CD (it was nightly builds in those days so not actually Continuous, but moving in the right direction). Later on I figured out how to build the apps, which was a bear, especially on Windows. Firefox, Thunderbird, and the whole Mozilla Suite which was still a thing back then, with integrated browser, mail, HTML editor etc. And finally contributed some bug fixes of my own. Nothing significant, we're talking like fixing typos and misaligned icons, but it still felt incredible to be shipping code that literal millions of people would use. All of this was immediately useful in my first job out of school. I started out doing IT support and QA at a startup but quickly found they had no build and deploy automation. Someone would push to SVN and you might not find out for days that it broke the build. I got them set up with a build server using what I had learned from Mozilla (Buildbot? Cruisecontrol? Hudson? Been too long) that would do a build on push and email the team if it couldn't compile or failed tests. Was pretty fun having a bunch of seasoned developers ask me "how the hell does our IT guy know about all this shit?" I was able to carve out a DevOps role for myself before that term existed, thanks to everything I learned playing with Mozilla in my free time. This is a roundabout way of saying I totally agree, hacking on Mozilla projects is a great way to get real world experience :)

db48x 3y ago
They used Tinderbox back then. It was definitely considered to be “continuous integration”, because the build machines never stopped. They continually rebuilt the software, starting a new build whenever the previous one finished. It just took hours to run a build, and more hours to run the tests, so there was no way to go faster. I too got a big head start by volunteering for Mozilla.
Delfwood 3y ago
> Cruisecontrol? I had forgotten about CruiseControl. Long ago, I had a gig for an avionics developer in a team whose technical lead had gotten deep into agile and had mostly sane practices (sources control, build scripts and automated tests were not a given back them). Still, we had a colleague that was often a bit to quick to commit broken builds or failed tests to the trunk. One day, I stumbled upon this program - CruiseControl - designed to automate build and test tasks. I had no notion that continuous integration was a thing. As a practical joke, I setup a VM, installed Cruise Control, gave access to our subversion server and created some jobs using existing Ant tasks, just to email blast the team when a broken build was committed. It got positive results way beyond the initial intent (mainly by eliminating "build worked on my machine"). Two years later, all SW projects of the company had been moved to Hudson.

db48x 3y ago

They used Tinderbox back then. It was definitely considered to be “continuous integration”, because the build machines never stopped. They continually rebuilt the software, starting a new build whenever the previous one finished. It just took hours to run a build, and more hours to run the tests, so there was no way to go faster. I too got a big head start by volunteering for Mozilla.

Delfwood 3y ago

> Cruisecontrol? I had forgotten about CruiseControl. Long ago, I had a gig for an avionics developer in a team whose technical lead had gotten deep into agile and had mostly sane practices (sources control, build scripts and automated tests were not a given back them). Still, we had a colleague that was often a bit to quick to commit broken builds or failed tests to the trunk. One day, I stumbled upon this program - CruiseControl - designed to automate build and test tasks. I had no notion that continuous integration was a thing. As a practical joke, I setup a VM, installed Cruise Control, gave access to our subversion server and created some jobs using existing Ant tasks, just to email blast the team when a broken build was committed. It got positive results way beyond the initial intent (mainly by eliminating "build worked on my machine"). Two years later, all SW projects of the company had been moved to Hudson.