According to the high level plan, we're currently on step 4. The Mozilla branch has been merged back into Pootle's trunk and work on the branch has been discontinued.
While writing code it became apparent that the framework Pootle was built on, jToolkit, had some shortcomings that were making it difficult to work with (not to mention development had been stopped on it since 2006). The decision was made to migrate the back end of Pootle from jToolkit to Django. This wasn't something I had counted on when I originally made the time line for Mozilla using Pootle but it was a necessary delay. During the transition, forward progress, at least on the Mozilla side, was halted. In November and December, the translate.org.za team did some fantastic work and completely replaced jToolkit.
Thanks to a lot of work from everyone and a bunch of unit tests the django based system reached parity with the old system rapidly. The Pootle team is expecting to release a new version around the end of this month. At that time I'll upgrade our alpha version and re-enable the features I've had to disable. I'm expecting the upgrade to solve a lot of the scalability problems we've been having and then we can start advertising our install more and expanding the projects it works with.
Once I do the upgrade Mozilla will be running a stock version of Pootle which I expect to continue from this point forward. Any patches Mozilla contributes back will be generic enough to be useful to anyone and will land on trunk.
We've created a 2009 idea/goal wiki page which will be distilled into a project road map. There are some exciting features coming down the pipeline, bringing a lot of improvements (particularly with the user interface) with them. As an added bonus, the new Django framework will allow us to progress faster with new features and it will be easier for more people to contribute code.
Thanks for your patience.
Add-on statistics have been intermittent for a couple months and are just recently getting the attention they need.
Our current process is to count download statistics once per day and update ping statistics once per week (update pings are a sampling of the complete set). The reliability of the script generating these statistics has been falling as our data size has grown and we've had several bugs filed regarding the numbers it's produced. Most of the time they are relatively small fixes and the script continued to limp along.
Currently we're facing questionable results in both sets of statistics (bug 468570 for update pings, bug 472538 for download counts). I've been debugging the update pings script and despite solving some problems we're continuing to see the script fail to run properly.
Parallel to AMO development, Daniel Einspanjer has been working on a larger statistics parser that will aggregate data from many Mozilla sites into a dashboard with easy visualizations. It turns out he's already processing the AMO logs and pulling out more data than us more often and in less time.
With a system like that available it doesn't make sense for us to continue to develop (and, in this case heavily modify) our local statistics scripts. With that in mind, our next steps are:
Verify the results we (used to) get with the AMO scripts match those of the new system
Create a transformation script to push the data from Daniel's project to the AMO database
Turn off the AMO scripts
Back fill statistics through at least November 15th, 2008 to replace our flailing stats. If the comparisons in step 1 reveal miscounting from before that we'll back fill as far as we need to.
These steps will let us meet the immediate goal of getting the statistics we offer now to be reliable and complete. In the future we can look at pulling additional data from the new metrics system. The target date to switch to the new system is the end of next week, Jan 31 2009. Once we make the switch we can evaluate how long the parsing takes and give an estimate of how long back filling will take. As always, let me know if there are any concerns.
Update 2009-02-02: We compared the scripts' results and found a discrepancy among add-ons that have significant external download numbers. The current stats script verified the GUID matches and then counted the update. The new stats script verified the GUID and the version before counting the update. This means if a specific version isn't hosted on AMO the new script doesn't count it. I think the current method of verifying only the GUID is more useful to authors and the new script is being changed. That means we'll have to re-run and re-compare the numbers (a single day is taking about 5 hours now). Other numbers are showing early promise. I'll continue to update as we progress.
The Android platform comes with a great market available for browsing and
downloading applications. Comments are easy to read, the permissions the
application is requesting are clearly explained, and installing is a snap and
happens in the background. Overall it’s a breeze to use. However, it’s got a
large gap in it’s model that I haven’t seen addressed anywhere - there are no
automatic updates for the applications.
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.