Continuous Integration

Release Schedule

October 2015
S M T W T F S
« Nov    
 123
45678910
11121314151617
18192021222324
25262728293031

Branches

Twitter

Simply ship. Every time.

A special update, just for Talk Like A Pirate Day

09/19/2006

Tonight, with help from morgamic and sspitzer, we’ve published Firefox’s first ever “major update.”
This type of update is intended to pull people from (for instance) 1.5.0.7 to 2.0. We won’t be immediately publishing any major updates (including that particular update path). It includes the ability to display EULAs and allow users to ignore the major update, including forever (so they can stay on 1.5.0.x, if they wanted).
We’ll be doing a couple of tests:

  • We’ve published an update for build 2006091813, win32/en-US only; most people have already updated to today’s nightly, but if you’d like to try it out, you can download that build, run it, and check for updates. You should get offered a major update to “2.0mt1″ (“mt” stands for “major [update] testing”).
  • Within the next couple of days (hopefully tomorrow afternoon), we’ll run a clobber build on the 1.8 branch, for all platforms/en-US, and publish an update to those builds that is a major update (will likely offer itself as “2.0mt2″).

If you’d like to help test out the major update functionality, Seth, morgamic and I, along with millions of users, and at least a couple of pirates, would much appreciate it!

Ahead of the Release Curve IV: Defining the Curve

09/14/2006

In case you’ve only ever read this “blahg” via its RSS feed, the tagline reads “What does a Build Engineer do all day, anyway?”
I’ve been thinking a lot lately about the answer to that question.
When I think about what my answer actually is, day-in-day-out—doing builds, triaging broken builds, restarting automatic builds, respinning builds, making sure there’s enough space for builds, signing builds, staging builds, getting new places for people to get builds, fighting fires on the machines the builds are created on, making sure the builds… well… you get the idea—it all seems somewhat… repetitious.
(And the more I look back at that, actually somewhat depressing.)
But even though we, Rob, Coop, TR, and I, do work on those things, I’m pretty sure we all think about other things, especially the fourth or fifth time in a day you’ve logged into the same Tinderbox to kick it.
Part of this recent introspection about what we work on, what we want to work on, and what we should work on was prompted by a question Schrep posed to me a week or so ago: we had just finished a company-wide discussion of goals and missions and he asked off the cuff what the Build Team’s manifesto would be, if we had one.
Something along the lines of “What should we be thinking about in the day-to-day that prompts us to work on things that have perceptible, positive impact, not only for ourselves, but for everyone else?”
There are the obvious ones: doing builds, triaging broken builds, restarting… well… you know… but isn’t there more than that?
Should there be more than that?
If you’ve ever talked to Rhelmer or I right after a release, our reaction to the mere mention of the word “build” implies that there should be.
In trying to tackle the answer, the only thing I could think of was make a list. As I sat there, trying to brainstorm what the list should include, I found myself jotting down the things I think about all day (and sometimes worry about at night). Some of them had that dirty, five-letter b-word… but a surprising (to me) number had nothing to do with that.
As I sit here, counting the thirty-plus items on my laundry list, I wonder if anyone would be surprised that someone thinks about these aspects of a software project that stare back at me. Does anyone really care what the number of old builds we store says about us?
Or why bumping versions is a big deal?
Or what the deal with centralized build data stores is?
Ok, so maybe people wouldn’t be surprised.
But, still I wonder. I’ve been in situations where I’ve been asked “Hey, can you guys do X?” When my answer isn’t what they expect, it sometimes prompts what can be an involved conversation about why the answer wasn’t a simple and immediate “Yes.”
I think such conversations are useful in the long run.
But I can’t help think if there were a good answer to the question my “blahg’s” tagline poses, then maybe some of my weird answers to questions would make more sense to others sooner.
As a bonus, if I could distill the common themes behind those day-to-day answers, I might just have the makings of a manifesto that would at least frame our discussion for what unique qualities we bring to the “MozillaVerse” (or are the cool kids calling it “Mozillasphere” these days?)
Think of it as an attempt at a JoelOnSoftware knockoff, except… without all that annoying credibility and pestering about having created-Visual-Basic-for-Applications-but- before-it-was-called-that-because-I-only-worked-on-Excel-at-the-time getting in the way.
On the downside, I will admit: it is highly likely there will be fewer treatises on the speed of duck-typing.

Moving on up… to that de-luxe [storage array] in the sky

09/12/2006

You’d think 1.9 terrabytes of disk storage would be enough for Mozilla’s builds, but… it’s not.
In fact, with all the simultaneous releases going on lately, we’ve had to spend a lot of time babysitting the chronically under-spaced stage.m.o.
Fortunately, we now have a replacement and a plan to get us using it.
In addition to giving us another terrabyte of storage, we’ll be able to reclaim some diskspace on the current arrays, and provide better verification of builds going out to the mirror farm.
The plan is to migrate stage.m.o and ftp.m.o to differet machines this Thursday. The downtime will start at 6 pm PDT and end at midnight.
Details of the plans can be found on the Wiki, including changes for contributors posting builds (they should be minimal).
If there are any questions or concerns, please feel free to email build@mozilla.org with them.

PPL ASEL.

09/11/2006

Last Friday, after [*cough* too many *cough*] hours of flight time[due entirely to me dragging my own feet], I drove out to the Palo Alto Airport and took my private pilot checkride with FAA-designated pilot examiner Mike Shiflett.
The first part—the oral test—went smoothly… and quickly!
I then gathered the weather for the second part, the practical flight test. Everything looked great on paper, but after pre-flighting the plane and getting out to the runway, an almost-direct crosswind of 12-gusting-15 knots, made this part of the test more… interesting. Much more interesting.
But after ninety minutes of doing various types of takeoffs, landings, stalls, and flight maneuvers, the examiner flew us back to the airport.
I guess I managed to trick him into thinking I knew what I was doing.1
To celebrate, I flew a couple of close friends to O69 today for my first $100 hamburger.
Both being photo nerds, they took some pretty incredible pictures.2


________________________________

1 Yeeeessss Justin; I can finally safety for you.

2 … including a couple of me being… quite-a-dork.

Disgusting Little Urchins

09/05/2006

Is there a way for me to filter a cookie based upon a regex matched against the cookie name, for each webpage, without the “Do you want to allow this site to set this cookie?”-window popping up? For instance, say I never wanted cookies with /^__utmw+$/ to be set, even if I wanted other cookies from a site set?
A bit of Googling netted me this Netlib documentation, but seeing as it’s dated 1998, I have little faith that it was even ever implemented.* (If I’m remembering the last time I looked at this correctly, I’m pretty sure I even did a quick LXR search on that pref name, too…)
An extension would be fine too… and I think I even searched for one too, but… alas, I came up with nothing.
Any pointers?
*No, I didn’t bother trying this yet, since the effort to ask the LazyWeb is much lower than the effort that will be required to bang my head against the wall when it doesn’t work. I figure that’s precious time I could be spending fixing a Tinderbox… or something. ;-)

Subversive Subversion Conversion?

08/31/2006

Bug 347069, “Setup a production SVN server,” was recently RESOLVED as FIXED. This has spurred some confusion, so I wanted to answer some of the common questions we’ve received:

Is the Mozilla Project switching to Subversion?

There have been many discussions in the past few months about the version control system that the Mozilla project entrusts its code to. It’s safe to say there’s a desire from most of the community to thank CVS for taking good care of our source code—for the most part—and move into the 21st century.
Obviously, such a move is a big deal, and impacts the very core of the Mozilla Project: our source code. It’s not a decision to be made lightly, or by a limited subset of people. It’s a project-wide discussion.

The first part of these discussions has already taken place, and a set of Project’s requirements for a version control system has emerged. As they wiki page notes, some of these requirements are in conflict, so they represent a utopian ideal of version control systems.

But no decision has been made on which version control system to switch to, nor have any concrete plans (schedules, etc.) even been considered.

Why has a “production” Subversion server been setup?

As part of evaluating various options, we would want to test various systems out.
Subversion is an obvious contender and various other open source projects (Gnome, KDE, Apache) use it. The goal in filing the bug was to set up a production quality server to provide a place to experiment with setting up a robust infrastructure for not just Subversion, but another production-quality revision-control-system-that-is-not-CVS. Additionally, it allows us to gain some experience and insight into our (often implicitly expressed) requirements around things like authentication and clustering.

Please don’t get hung up on the word “production.” (More on that below.)

Its use merely means that we wanted this on a machine that wasn’t someone’s desktop and wanted to ensure that IT was included in its setup and evaluation, so their requirements for providing A-level service and support for a CVS-replacement could be (experimentally) gathered and added to the requirements list for a new revision control system.

It is important to note:

  • This server has a significantly lower SLA than most of the other IT services; basically, 9-5, M-F support. It is not considered required infrastructure. There is no oncall@ support for Subversion.
  • This server instance may get blown away and re-created multiple times. We will be playing with hook scripts, repository layout, and other options. We may decide to “start over” possibly multiple times, while exploring these options.
  • This server does not have any support services, such as Bonsai, LXR, Tinderbox coverage, fine-grained access control setup, or even backups!

Why Subversion first?

While there is a healthy debate about which system to switch to, I think everyone can agree that Subversion is one of the viable options.

Subversion was chosen as the first test system because some small portions of code that we rely on were in Subversion repositories (at OSL, for instance).

Additionally, members of the Subversion project came forward to offer assistance with deploying an initial setup, and we’ve successfully performed a test import of the Mozilla CVS tree into Subversion, thus meeting a (pretty important) initial requirement listed in our requirements.

What is this “production” Server going to be used for, then?

The server will be used for projects that have no dependencies on code in the CVS repository.

Currently, the guinea pig project is AMO3. Again, as they work on the project, we’ll undoubtedly play with the server’s options and possibly layout. Recreating the server is a likely outcome.

As this trial installation matures, we may solicit help in the form of testing from additional “segmented” projects to ensure that the infrastructure we’ve created/migrated meets the needs of other Mozilla projects/initiatives.

Can I get an account on the Subversion server?

If you’re working on a project that is on the SVN server (currently only AMO), testing it out, file an IT ticket indicating your username on the CVS server, and which project you’re working on.

If you’d like to help out by testing, please email which project you’d like to volunteer, where it is in the CVS repo, and what specific goals/requirements you’re trying to test out to build@mozilla.org.

Note that we’ll want to get AMO settled and other parts of the support infrastructure setup before we let more people into the sandbox, and that is likely to take at least a couple of months, especially given other priorities like Firefox 2.

Also, we’re likely to tend towards projects that allow us to get the most coverage of disparate requirements, to maximize the utility of this pilot testing project.

Hope that clears everything up! Feel free to post any other questions you may have.

And nothing else compares

08/30/2006

Some time ago, in a place far, far away in the blogosphere, I received a comment in response to a post rambling about aviation (and my admiration of it) that merely said “There is beauty in things done really well.”
I was wasting some time on YouTube the other day, and much like wasting time on Wikipedia, found the following video by just clicking a bunch of links.
It expertly captures the… well… the beauty in aviation executed… really well.

[Direct link, because <objects> get stripped, I guess]

I actually found this video through a bunch of random clicking from of a video that a friend of mine posted of his plane executing the ILS Runway One-seven-right Approach into KDEN.
Yes, I think it’s the spot-on music that really makes both of those videos.

“Isn’t [IRC] safe for the good children, Bobby?!”

08/25/2006

Edited to remove extraneous (y’know, productive, work-related) conversation:

11:28 < mento> say my name
11:29 < ss|work> mento: Where's the "bitch"? It's supposed to be "say my name bitch"
11:30 < mento> ss|work: yes, but this is a family channel, and i wouldn't want to upset any of the reeds
11:30 < ss|work> Ah...
11:30 < mento> ss|work: were this #camino, you better believe i would have exceeded your expectations of my vulgarity
11:31 < preed> mento: you obviously haven't seen #build around release time.
11:31 < preed> We move from TV-Y7 to TV-M
11:32 < mento> with all the D, S, L, and V that come with that rating
11:32 < preed> Mostly L and V.
11:32 < preed> I wish there were more S.
11:32 < preed> If there were more S, there'd maybe be less L and V.
11:32 < ss|work> preed: Lots of S in #foxymonkies.
11:32 < preed> but definitely plenty of D.

build_team++ redux

08/24/2006

I mentioned this at the weekly status meeting, but please help me in welcoming MoCo’s newest addition to the seemingly-always-strapped Build Team: TR Fullhart.
TR comes to us with years of experience in build automation and scripting, and should be a huge help in the efforts to “de-insanify” our build process and infrastructure.
Just the other day in #build, he said: < trf> really, I like scripting and programming, feel free to give me stuff
That’s what I like to see.1
If you have a sec, drop by #build, and welcome trf!
Glad to have you with us, TR!
________________
1 Anyone remember when their buglist was that small

Newer Posts
Older Posts