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!

What Google is doing is something I’ve been waiting a long time to happen, for some company to beat back the large corporations who are straddle both sides of the fence in the world of content – they are both producers and delivery agents (and also in some cases control the delivery method.)

We really need companies to become tighter in focus – be a delivery pipe and a good one; be a content producer and a good one; be a receiver or client and a good one but just don’t be all three. I’m looking at you now Comcast and Apple.

When we have multiple choices of pipes and can move our phones, netbooks or computers from one to the other without penalty then we can have a proper marketplace of competition.

Ok, that’s the only non-geek podcast I’ll do for another year :)

I had to double check that date since it sure doesn’t seem like 6 years have gone by :)

At first I was thinking that this idea has already been tossed under the bus by many folks who thought about creating open versions of Friend Feed and I even thought that in a way it’s already being proposed by the Laconi.ca (aka Status.net) crew and the OMB protocol but I realized that I was focusing on how I would implement such an animal and not how to enable data transfer, which is after all the core part of what an API offers.

After realizing I was giving the thought some serious short shrift so I sat and chewed on it and came up with an idea and also an immediate concern:

First the idea, it should be a gateway that allows for sending/receiving of items using one of the many existing excellent examples of data APIs

• Activity Streams
• Atom Pub
• RSSCloud
• Open Social  

Any one of the above would make an excellent gateway API interface as they allow for all of the elements that exist in a Twitter item.

The one immediate concern I have is about identity. As a gateway, the system would need to understand how to map identity from/to the incoming and target network so that a proper flow of the conversation can happen.

The good thing is that recently a lot of work has happened recently on just that item :) and I think that the newer Web Finger and the existing OpenID options could work because already quite a few of the larger data silos allow for mapping of OpenID to their internal systems. The protocols above also all, if I remember correctly, have some method of storing enough metadata to allow for the incoming item to maintain it’s integrity even if on delivery some items are lost – the gateway would be able to remember the transaction even if the target mangles some of it.

With the proper storage of metadata then other protocols like Salmon can be used to track the conversation across all of the “jumps”.

I think the important part is to not create yet another data silo that has to be maintained and polled just to allow for all parts of the conversation to maintain itself – rather I would love to see this as something that could be used to enable each unique identity to maintain the information required and become the master of their own conversations. Of course large sites could offer internal proxies to their own user base who don’t wish to implement their own, but it would also allow power users to do so and then the other gateways and exchanges points become secondary backups and the whole thing becomes a lovely distributed system.

Just some quick thoughts that I wanted to get down before I go to sleep

Second, the endpoints used to access an API are, at most, 1/3 of what makes up an API – the most important part of an API is the data passed to and also from those endpoints to do the tasks that the endpoints enable.

So sure WordPress and Tumblr have a Twitter-compatible API but what happens when Twitter changes how one of the endpoints work, like they did when they recently changed how since_id works or even how re-tweets work. At best the other sites will be able to make similar changes but the worse case scenario is that they won’t or cannot make the changes and then things start to get ugly. Anyone remember RSS 0.93? or even the blog related API’s to make posts from clients – all suffered from fragmentation.

That is not to say I am not excited to see the API pattern used by Twitter is being more widely adopted, it’s a well thought out and functional API – I just think that crowning it the King of micro-blogging APIs is a bit premature until the *whole* API, data formats and all, is documented.