Hmm, I know VCALENDAR and can hack-parse html …

So 3 hours later and I have a very basic program that reads the Schedule wiki page, sucks out all of the tables that represent the daily schedules and generates a .ics ready for importing into your favourite calendar program.

Requires Python 2.6 or 2.5 with ElementTree installed: generate_summit_calendar.py

enjoy!

\o/

This was an interesting task because it involved a little bit of each job in the RelEng world at Mozilla:

I had to update the puppet manifest which we use to distribute files and manage configurations for the build farm so the signing keystore and configuration file would get to all of the production build servers. I also had to write a small Python program to make the actual call to Jarsigner because if we just called it from within the Buildbot step, the output would include the keystore passwords and that appears on the build server’s web page – not good.

I also had to drill deep into the various parts of the Mozilla Buildbot configuration and custom code because the Android build was new and just different enough from the other mobile builds that it wasn’t just a cut-n-paste solution.

And all of this I was doing the Mozilla way for the first time and let’s just say they have some unique custom code :)

But today the first half of the task was completed and that allows the nightly signed builds to be made public. What remains is to remove some work-arounds (for the packaging and tests) and then to start building the steps required to generate a release version of Fennec for Android.

Note: If you run into any configure or make issues you may need to install some of the from-source tools I had already in place from my work to get Mozilla Firefox to build from source. I’ve covered that in detail on my Mozilla wiki page.

I used the current source tarball from the MCabber site – make sure you get the MCabber source tarball and also the Loudmouth library tarball.

Extract both into your favourite working/source tree setup

tar xf loudmouth-1.4.3+gitb5a9de5b.20100413.tar.bz2

tar xf mcabber-0.10.0.tar.bz2

Build the Loudmouth library. Note: I put all of my source installed libs into /opt that way I can set LDFLAGS and CPPFLAGS to point to anything non-OSX that i’ve installed.

cd loudmouth-1.4.3+gitb5a9de5b

./configure –prefix=/opt LDFLAGS=”-L/opt/lib” CPPFLAGS=”-I/opt/include” –with-ssl=openssl

make

sudo make install

Switch over to the MCabber directory and build it

cd mcabber-0.10.0

./configure –prefix=/Users/bear

make

make install

and that’s it – you now have a console XMPP Client!

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.

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 :)

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!

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.

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!

Two days ago the very popular and useful Identi.ca site was updated to version 0.9rc3 along with other Status.net sites. This is not the issue, Identi.ca has always been the proving ground for new features and as the open source arm of the project you have to expect some bugs.

What is the issue is that this release candidate (that is what the “rc” part of 0.9rc3 means) contained a lot of new code to deal with how the internal queues are managed.

Let me repeat that:

a release candidate contained new code that was not a simple bug fix

So now the entire XMPP stream has been taken offline to deal with the integration issues between the code and their XMPP server.

Come on guys, surely you have a QA and/or DevTest server? Why the hell are you continuing to introduce new code into release candidates.

Oh, and why don’t you just rollback the change?

And yes, before I get flamed and yelled at that “It is *free* so you have no right to complain” let me point out that if they offered a pay version, I would pay. Also since they have custom users and, I believe, even corporate installs, they should have better QA. It really is that simple.

If you had asked me 6 months ago how things were going I probably would have given a mixed *shrug* as I was still in the middle of dealing with my father-in-law and his rapidly declining health and, to be honest, I was glad to 1) have a job and 2) have a house so that we (Elaine and myself) didn’t have even more things to worry about. But then right at the end of summer he passed on and now, after dealing with that event, things are sure looking different.

Two years ago we suddenly found out that most of us at OSAF were out of a job but that turned into a chance to join my first-ever startup – Seesmic. Now as I approach my second year at Seesmic I’m looking forward to see what happens next both personally and professionally.

The work i’ve done with XMPP and Python have really payed off, the rest of the world (well, ok, the web part of it) have really caught on to realtime data flow and XMPP is playing a big role in that and Python remains a good language to code in for both XMPP and other back-end apps.

So yea, big changes have happened and more to come I’m sure, but as long as I’m enjoying what I do (which I am) and as long as I keep my skills fresh, I don’t see any reason to not just keep moving along and enjoying this amazing field I call a career!