preed's blah-blah-blahg

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.

Posted by preed at 11:05 PM | Permalink | Comments (10)

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.

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.

Posted by preed at 12:57 PM | Permalink

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.

Posted by preed at 9:14 PM | Permalink

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.¹

If you have a sec, drop by #build, and welcome trf!

Glad to have you with us, TR!

________________
¹ Anyone remember when their buglist was that small

Posted by preed at 5:36 AM | Permalink | Comments (2)

I honestly don't know why I even load Slashdot anymore.

I tried to make the change to kuro5hin when I tired (some years ago, now) of Slashdork's continued duplicates and awful spelling and grammar—talk about needing an editor—but it didn't take.

What do the cool kids read for their tech news fix these days?

(Do not say "Digg." Digg is on my s#!+ list for being the main reason I personally have had to do a bunch of extra [release] work due to people "digging" "news" that software has been released when it hasn't been... which brings into question the validity of anything that's "dugged." Also, there's no [easy] past tense of "digg.")

Posted by preed at 6:38 AM | Permalink | Comments (9)

For those of you watching balsa, our memory leak tinderbox, just a quick heads up that we'll soon be migrating to the virtualized balsa[s] very soonishly.

The new virtual memory leak tinderboxen names are balsa-trunk which, coincidentally enough, does trunkish builds, and balsa-18branch which does—you guessed it—Firefox 1.8 branch builds.

bz and I looked at the numbers for both the physical and virtual tinderboxen and they looked comparable/cogent/good. Because these are leak memory tests, the virtaulized versions of these tinderboxen don't seem to be affected by virtualization, which we expected.

If you'd like to take a gander at these new tinderboxen, check out the 1.8 branch page and the trunk tinderbox page.

(They're also publishing to the Seamonkey-Ports page, but for some reason, both physical- and virtual-balsa are in various states of unhappiness... which, on the one hand, is good news in terms of validating that the VMs are coherent images of the physical machines, but bad in that... they're both broken.)

Because physical-balsa is literally sitting on the colo floor and the ever-gallant IT peeps are tripping over the machine, we'll probably shut it down within the next few days. If there's a reason why we shouldn't, please let us know.

Posted by preed at 2:09 AM | Permalink

Tidbit the First:

The current Build Team Radars have been posted on wiki.m.o.

I did say radars—multiple—as we've published August's monthly radar, but also a longer term, quarterly radar.

Astute readers of the two scopes may notice that the monthly radars now have ETA dates, whereas they didn't before. You may also note that the quarterly radar has no specific dates, but has a ninth month outlook.

Being the aviation geek that I am, don't be surprised if your hear me start referring to these as the "[Monthly] Approach" and the "[Quarterly] Center" radars¹

rhelmer has been spending his days working on the Test-Only Tinderboxen. For those in a hurry, this was adding functionality to tinderbox to download a build and test it on a separate machine. These machines would have different characteristics than the build machines (namely, they wouldn't be VMs), and hopefully will give us more stable data.

Well, they're finally here! Look for columns ending in "test perf" on Linux and Windows on the 1.8 branch and trunk Tinderbox pages. And this is only phase one.

Thanks, rhelmer, for your hard work on this!

We made this change some time ago, but it may still be confusing: nightly builds older than about about 60 days now get moved to archive.m.o, and moved off of ftp.m.o.

If you're looking for older nightlies than you can find on ftp.m.o, check out archive.

Posted by preed at 11:23 PM | Permalink

While doing some testing today, we found a serious bug that will probably have to be addressed before Beta 2 ships.

It has to do with the migration code just barfing on large amounts of input.

As Rob Strong notes, it's currently unclear whether or not it's a blocker, but I wouldn't be surprised if it turned out to be. The attachments have some pretty disconcerting screenshots in them, as does the test URL noted in the bug.

I know sspitzer is working on investigating it more; expect a complete writeup soonishly.

Posted by preed at 10:10 AM | Permalink | Comments (3)