Building off the success and fun that was had with the Firefox 3 T-Shirt Design Contest Mozilla has just launched a new Community Store.
This store will let anyone upload shirt designs and print custom Mozilla shirts. If you've got good taste but designing isn't up your alley you're welcome to browse and customize the existing designs as well.
I don't think there are any localized shirts on the site yet but I'm sure they'll start popping up soon - and once one is designed anyone in your local community can order it. Zazzle, the company we're using, says they ship to 84 countries which isn't everyone but it's a good start.
I'm excited that localized shirts are finally available and I'm looking forward to some great designs.
Looking over what I've written about Verbatim I realize that I've never talked about the overall plan on here. Even though we're well into it at this point it doesn't hurt to review.
The original plan for Verbatim was to branch Pootle and continue to merge code between the branch and trunk as features were developed. As we developed code we realized this just creates more work for developers and makes users have to choose between two branches. A better method is just to have everyone commit to trunk and write the code in such a way that any site specific code is maintained in configuration files which is what the current plan entails.
Step 1: Branch Pootle. Wynand created the Mozootle branch as a place for Mozilla developers to commit. For the record, Verbatim is the name of the project, Mozootle is the name of the actual branch in the repository; effectively, they are interchangable.
Step 2: Develop Mozootle. We used Bugzilla to track our changes and there are still plenty to do but the first milestone is closed at this point.
Step 3: Merge Mozootle to Trunk. This is the stage we're currently at. The translate.org.za team has been reviewing the changes in Mozootle and planning out the merging strategy. There is a fast moving wiki page tracking issues with the merge right now. Our current goal is to resolve these and merge in the next couple days.
Step 4: Continue development on Trunk. The plan after the merge is for all developers to continue committing code into the Pootle trunk. What "development" means is a post in itself so I'll cut this off here.
In hindsight the whole branching and merging process seemed necessary at the time but it doesn't feel like we gained much. Next time I think we'll just skip the branch.
SQLite only supports a simple set of data types and the only one that really matters is "INTEGER PRIMARY KEY" so you can have it auto-increment. In fact, by default, I can declare the columns as anything I want and it doesn't even throw a warning.
sqlite> CREATE TABLE t2(c1 wtf, c2 yomama);
sqlite> INSERT INTO t2 VALUES(1, 'blah');
sqlite> SELECT * FROM t2;
1, blah
This is all documented and explained so I can't complain to much but it's still an interesting concept.
I got the chance to try out the latest version of Shredder last night which recently celebrated it's Alpha 3 release fixing an impressive number of bugs. Among the heap of bugs is our very own bug 262319; "sort by thread fails to resort on new message." Two weeks shy of celebrating it's fourth birthday it was squashed and a fix was checked in.
A few straggling bugs aside[1] proper message sorting has been achieved and the ThreadBubble extension is no longer needed.
The latest version, ThreadBubble 0.8, is compatible with Thunderbird versions up to 3.0a2pre and I expect it will be the last version released. Maybe I'll work on a Firefox extension next...
Anyway, thanks to everyone who tested, used, and gave feedback about ThreadBubble. :)
[1] This is kind of a joke - the parent bug is actually a meta bug for all threaded view issues and I don't know how many of those are confirmed or are relevant to what ThreadBubble fixed. I do know I filed bug 461100 last night which is a new problem with the threaded view as far as I can tell.
I think any good manager will tell you that looking back over the choices you've made is an important step to improvement. In an effort to improve myself (and help anyone in a similar situation) I wrote this post with a few thoughts about branching an open source project (in this case branching Pootle to make Verbatim). My goal is not to criticize anyone's past decisions, including mine, but just to review the pros and cons and what I would do differently in the future. So, a few thoughts late on a Friday:
When I started the planning for branching Pootle I was very focused on scalability (or lack thereof) and most of my initial goals were to improve that including replacing flat files with mysql, creating a cacheable URL structure, etc. In hindsight, I should have realized that this project wasn't going to be getting nearly the traffic load some of our other sites were getting and my priorities were out of order. What I should have been thinking about was usability and interface improvements. Due to my lack of foresight the project launched with enhancements in both areas but I think the time we spent on scalability was premature and the user interface suffered.
Whether it's writing more comments than code or making sure meetings have agendas I'm a huge fan of communication. When branching a project, particularly when there are plans to merge the branch back into trunk, communication is vital. I think our meetings are productive but communication on a smaller scale is still a struggle. Both Pootle and Verbatim ended up writing the same code in a few cases which could have easily been avoided. In this particular case the timezones can make it difficult to synchronize but it's something I'll work at more in the future.
Something we have done a good job with is making a schedule and updating it with new developments. I really want to expand our effort here though. I think one of the difficulties of someone joining a project like this is direction; what are the goals of the project and how are we getting there? Several of us have talked about it on IRC and we all have a good general idea but for someone that isn't as involved it's hard to follow. Once we get over the next big hump (replacing jToolkit) I think this will begin to fall into place with smaller bugs/features revealing themselves and providing a way for volunteers to get footholds on the project as a whole.
Lastly, it might be obvious, but if you're planning on maintaining the branch or merging back to trunk make sure you get along with the lead developers. I'm fortunate to work with the Pootle developers who clearly care deeply about the project. From talking to them it's obvious they have the end users' best interests in mind and are excited that we can all work together to improve the end product. And really, that's what open source is all about and it's great to be a part of it.