The first day jitters are over, tho to be honest I didn’t really have any as I feel I know the Mozilla team already.

I first started interacting with them when I was with OSAF because as the build/release person for OSAF my job was to maintain the tools used and the vast majority of them turned out to be the same tools that Mozilla used. Little did I know that I would eventually inherit the care and feeding of some of them ;)

Now jump back to the present and I’m an employee of Mozilla and thankfully the culture hasn’t really changed, sure there are some “inside” differences and quirks, but I think they have done a good job at maintaining the same look-n-feel for folks no matter if your a mozilla.com person or a mozilla.org person.

For me the most fun was browsing the internal employee phonebook and seeing people who i’ve either admired or worked with on other projects – very cool :)

So forms have been filled out, subscriptions have been made and I think I’m plugged into all of the info sources I need to be wired into – now to figure out what the team needs to be solved and start learning.

Starting March 1st, 2010 I will be working for Mozilla and will be part of the Build/Release team.

I’ve had a great time at Seesmic and have helped and participated in the different challenges Loic has thrown at us but the server environment has moved from the realm of “how do we solve this” to a more normal production environment. Combine that with the fact that the Build team at Mozilla are working with mobile builds and have a build farm of over 600 servers, I just could not resist.

So I’m not leaving Seesmic for any specific reason, just moving to Mozilla because they are offering me a chance to help solve problems that just do not exist (that I know of) in any open build environment.

I still feel that the tools that Seesmic are creating to manage the personal social network environment are top notch and the design and developer team they have are going to continue to do amazing things.

I will get to enjoy them as a customer now :)

I was chatting with fritzy just now and we were discussing the iPad and I suddenly had this AHA! moment.

Given that the iPad will have an optional keyboard and given that you can activate it using wifi and don’t need another Mac to day and given the fact that Apple has really enhanced MobileMe – you now have the ecosystem required to allow the iPad to exist in a home with no other computers.

Think about it – you can turn on your iPad, enter your Apple ID (or sign up for one) and then your online and in the cloud – MobileMe will handle the backup/sync requirements to any iPhone you may have and all you need is WiFi or 3G.

If you do have other computers, that’s just gravy for the experience.

Wow!

To understand why the Build/Release process is what I consider the most important part of any project, I first have to define what I consider to be the parts of the Build/Release process.

Build/Release starts from when the first line of code is created and continues all the way to when a user installs and runs your application or accesses some part of your server or service. Yep, it’s inter-woven into all aspects of a project simply because if you don’t have quality steps all thru that process you end up with crap. It may be pretty shiny crap, but it’s still crap.

I find one of the better ways to visualize Build/Release is to work backwards from the customer and outline what it would take to research and solve any problem the customer is having. This often is classified by developers as bugs, but I’ve gotten more accustomed to thinking of them as Issues – because sometimes it’s not a coding defect that is causing the Issue, but rather a process or UX problem.

Your project, let’s call it twerzle has just been installed on your customer’s laptop and bang – they have a problem. What happens next depends on how prepared you were during the Release part of the Build/Release process.

• Do you have a support link or area on your project page
• Is the version number or other project identifier easily discovered or located
• Do you have a way for the user to give you the information you need without them having to be a digital forensics major?

These items will change from release to release, so you need to have outlined what steps are required to update your web site and secondary documentation – you do have a README file or CHANGES file and that information is accessible right? So our twerzle user has found your support link on the page they downloaded the app and that page also has what the latest version is so they don’t have to guess – what is next?

• Is this link a simple email box? Is someone assigned to answer the emails? Do you have an auto-responder?
• Is the link to a support forum? Has someone been tasked to monitor the forums? Is there a sticky-post showing the README contents?
• Is the link to an IRC forum – better hope you have 24hr coverage because that’s a fast way to an irked user if no one is around to answer them 24×7

So, community support methods and practices aside (that’s a whole other subject that I don’t even begin to understand fully), you now have a support request from a user and for the sake of our example, it actually contains a version number and a complete description of the problem. This is when you find out if you have a real Build/Release process.

Given the version information for the issue, can you now go back and install a clean instance of that exact version? No, I am not talking about a developer having what they think is a clean checkout of the source. I am talking about being able to retrieve the exact distribution image and then being able to install it on a computer that has NO development environment. Yep, this step is where most projects fail as they depend on developers to reproduce issues. But that works only for coding defects – not for application usage or environment issues.

That is what the crux of Build/Release is, the ability to have all of the information that goes into a project’s distribution available to back-track and solve any issue a customer may have. What goes into this nebulous hand-waving bundle depends on a lot of details, but it almost always boils down to three items:

1. Reproducibility
2. Documentation
3. Deployment

Reproducibility means simply, do you have available all of the source code, the libraries, and the environment needed to build said source code available for each release you have made. If you do not, then you cannot truly reproduce a release and while you may be able to figure out what the problem is, you will not be able to fix it for that release. You will have to fix it in the trunk and hope that the code is the same and that the fix doesn’t break other things.

Documentation is all of the things that make up the how and why of the building and creation of a distribution. What versions of libraries are needed, what steps are to be taken, what tools and assumptions are being used and what the process is to bundle all of that into a distribution. Yes, here source code and scripts do count – as long as you include them in the distribution snapshot :)

Deployment is basically all of the above but from the point of view of non-developers. What is the process to deploy a new release for testing, how do you take the developer generated items and QA them. Once they are tested, what are the steps for deployment to the public. Do you have upgrade steps, are there extra tools and/or documentation that needs to be generated for upgrades versus new installs.

I realize I have only given a very short overview of what I consider a Build/Release process is but most of the time the above is what a lot of projects don’t do well for a lot of little reasons. I myself need to sit down and try and map out how I will communicate more details since it is so project specific.

Thanks for reading and I hope my bumbling attempt at communicating this process has come across in a useful manner.

Fritzy posted a comment that got me thinking about what exactly are “good habits” (aka Best Practices) for open source build/release projects and while I’m not going to outline them all here in this post, I do want to cover one item: the Release Candidate.

What is a Release Candidate? The Apache Incubator site has a guide that defines it as

Release Candidate

Collection of artifacts to be tested and voted on in order to release them. Sometimes folks use this term to refer only to a candidate source package.

and while that’s a rather dry wording, it does outline the most crucial piece – that it is a collection of artifacts (aka source files, images, etc.) that are to be considered for the next release. Those items are generated from a “frozen” source tree and used to test that the release candidate is ready for distribution.

In all but the extreme edge cases, a Release Candidate is a very specific thing that can only come about because the Developers and the QA team have decided that the current set of bug-fixes and/or new features are stable enough to be ready for consideration as the next release. This does not mean you can take the latest generated output from your continuous integration tool (or at worse case the tarball the developer was using as his test install) and move that to the web site and stamp a v2.0 sticker on it.

Only for the most basic of projects can you consider the developer version of a distribution to be ready for release – the vast majority of projects all have secondary information to be included and also will require additional changes to any number of support-related documents or sites. At the very least you need to create your ChangeLog to outline what has been fixed and what is new.

So a release candidate starts with what the developers have created, gets updated and massaged so that it contains the extra information that makes a distribution and then that part is tested in a non-developer environment. Once those tests are done can you consider it ready to be installed or distributed to the public.

The flip side is what things can cause a release candidate to not be considered – that in my opinion, is a very short list and depends on how the project defines “show stopper” so it’s hard to generalize into a post. The one item for me that is always an immediate veto is if it is discovered that code that isn’t part of a bug fix or a feature that was scheduled for the release is found to have been introduced. The reason why is really simple – how can you properly test code if you don’t have the bug notes or feature notes to guide you in testing.

That is basically a very fast overview of what I consider a release candidate to be. I’m going to work on an outline for what I think are the core tenets for any open source project and start a blog post series covering them.

thanks!