Mozdev.org

Our Drupal installation has been upgraded to version 5.19 to address a security vulnerability. Let us know if you encounter any problems.

I was a little ambitious in my plans for last week, but I did get a couple things done before I went on vacation. Primarily it was getting notifications sent to our projects that don't support 3.5 yet, but do support at least 3.0. I was also able to fix a bug in our XPI parsing and did some research into a misconfigured old project.

This week I plan on getting the wiki upgrade process finalized using the Drush tool and get any final impressions before performing the upgrade.

This week was mostly spent looking over Firefox 3.5 support, compiling stats, and fixing bugs. I was able to get a little bit of time in on the wiki upgrade, but didn't finalize the upgrade procedure yet.

• Compiling high-priority, low-effort tasks for new sysadmin
• Firefox 3.5 upgrade planning; put together blog on current support at Mozdev and trying to compile lists of projects and extensions to contact about upgrading
• Improving page rendering time on Mozdev pages by ensuring that links/styles/scripts are ordered properly in the head tag
• Cleaning up our supported applications pages to make the extension totals clearer
• Wiki upgrade - switched from using the custom module update script I was using to drush; still has some bugs to iron out

This coming week I'd like to make sure the projects who need Firefox 3.5 support get notified early in the week and then I plan on finalizing the wiki upgrade process so we can have projects test out the changes. The upgrade seems to be working well on the projects and pages I tested, so we can probably move forward with the upgarde in the near future (the next week or so).

Firefox 3.5 is right around the corner, and developers are getting ready by updating their addons as quickly as possibly. At Mozdev, we see a lot of projects are currently working towards Firefox 3.5 support, with some of them claiming full support.

First, let's look at overall support for Firefox versions at Mozdev. We currently have 159 active projects with 415 extensions supporting Firefox; 55 of those projects have released 175 extensions at Mozdev which is what we will use for our stats below.

First we have a breakdown of the Firefox versions supported:

Other 8%

<2* 6%

2* 15%

3.0* 41%

3.5* 29%

We can clearly see here that Firefox 3 and 3.5 support is strongest at Mozdev (70%), but we still have 30% (!!) of extensions that don't support a current release.

Of the 29% that support Firefox 3.5, the breakdown is like this:

Alpha 75%

Beta 10%

Final 15%

This is a good bit different from what AMO is seeing, with 81% of their most popular extensions being ready for Firefox 3.5. I'm sure this is because Mozdev doesn't have the sheer number of addons that AMO does and our release system isn't used as much.

Mozdev is excited about the upcoming Firefox 3.5 release; let us know if there's anything we can do to help improve our tools to make it easier to get your extension pushed out for this great software!

Last week's highlights include download graphs being rolled out to project overview pages and an update/test of our wiki.

• Fixed a bug in mirror bytes transferred calculations which capped the transfers at 4GB
• bug#20841 - added download stats to project overview pages
• Fixed bug with hash verification failing in file management tool
• Wiki upgrade progress with adding additional Drupal modules, default configuration, and testing of other sites

This week I'd like to do some more testing of the wiki upgrade for our projects and researching to see if there's anything Mozdev can do to help with or prepare for the Firefox 3.5 update.

I've been working on bug#18975 trying to make wiki editing easier. Our interpretation of that is:

1. using HTML for markup instead of "wiki syntax" (ie, not Mediawiki, the Text_Wiki syntax we were using, or Mindtouch wiki that MDC switched to)
2. Add a featureful WYSIWYG editor to make editing HTML content easier
3. Maintain an easy way for linking to other pages

Our progress on this can be found on our dev server; an example page is here:
http://www.vebzom.org/drupal/wiki/MozdevDocs

A snapshot of data was made today and most projects' wikis were upgraded on our dev server. Please check it out and let us know what's broken or you like/don't like.

A few notable changes/improvements:

• CamelCase words are no longer linked. You must link via [[Square Brackets]] to pages
• Table of Contents are added via an HTML comment: <!--tableofcontents-->
• Geshi code highlighting is only supported by editing the source and adding a <blockquote> tag

That's all I can think of right now; let us know what you think!

Mozdev has added download graphs to all project pages. This should give project owners a better idea of how frequently users are downloading their projects' files.

We have also added graphs for both downloads and bytes transferred for our mirrors and regions.

If you have any suggestions for improvements to the graphs, feel free to add them to bug#20841. In the mean time, go check out your downloads!

Last week was mostly spent updating our mirror stats to track download sizes for mirrors and regions (so we have some estimate of how much traffic our mirror network pushes) as well as working on our Drupal wiki update.

• Started tracking download size per-mirror, per-region, and for each mirror/region combo
• Added per-region graphs and download size graphs for our mirror stats
• bug#18975 - Working on wiki upgrade to re-save content as HTML instead of wiki-syntax so we can use a WYSIWYG editor to make changes. The re-saving/conversion to HTML is going well; I'm currently trying to enable the new modules we would like to have after the upgrade and have them configured properly.

This week I hope to have the wiki upgrade process completed so I can begin testing with the hosted wikis we currently have. I'd also like to upgrade our project overview page to include download stats which should just be a matter of consolidating my previous work on the mirror stats into that page.

Ever since released our file release system (including secure updates and installations of .xpi files) we've planned on improving the support of hashes. We didn't originally realize that md5 was no longer on the list of hashes, and with sha1 having its own share of problems recently, the need for stronger hashes was increased.

So finally we have dropped support for md5 as well and support only the stronger hash mechanisms (sha1, sha256, sha384, and sha512). We still auto-detect the hash type by the length of the hash submitted in the file management tool, so the procedure is exactly the same. Any existing md5 hashes are still in our system and presented by our secure install links but are considered deprecated.

Last week was a short week due to holiday and sick kids. This week looks better (despite the sick kid this morning). I didn't manage to get to working on Drupal patterns for upgrading wiki configurations, but did manage to improve our file management tools and tracking of downloads for our mirror system.

• Noted that we can move our primary mirror to a new server (off of our development server)
• Fixed cache problem on recently uploaded files. This affected "download" files that were updated and improperly cached in our system. The result was files wouldn't be downloadable until they were mirrored.
• Fixed problems with duplicate GUIDs in extensions. It was difficult to tell if a GUID was different previously; we now force GUIDs to be lowercase for all new extensions.
• Improving support for supported file hashes (more in a separate blog post)

I'd like to put some more mirror and regions graphs up now that we're tracking download sizes as well as number of downloads. I'm also planning on getting to those Drupal patterns and trying to do something about a drush plugin for patterns.

• Finally fixed drupal cron execution which prevented subscription notifications from being sent
• Finished converting some parts of hovercraft repository to mercurial by moving source code and updating pages to link to new location (custom project's drupal enhancements, irc bot config, and now mirror compose scripts)
• Cleaned up hovercraft project to reflect that it's not longer an installable distro and is just a code store; cleaned up duplicate/old bugs and moved relevant ones to the Mozdev project
• Fixed problem with drupal staging server SMTP override code when installed in production
• Research into Drupal roll-out methods for bug#18975 - it currently looks like the Patterns project should be able to allow us to simplify rolling out updates to our Drupal sites once we have a drush plugin to run them.
• Developed a method for enforcing certain Drupal modules for our installation to make sure we can perform upgrades properly
• Started researching upgrade to Drupal 6 - should be doable since all required modules are available now

This week has had a slow start due to the Memorial Day holiday on Monday and a sick day yesterday. Today has so far been spent debugging file release problems and in other site support and I hope to move on to developing Drupal patterns for upgrading our wiki configuration soon.

I spent time last week on all kinds of different projects; most of them being backend-type projects that will make administration and development a little nicer.

• Fixed cron execution for Drupal which was preventing subscription messages to be sent out (among other tasks)
• Added ability to disable users - This was implemented primarily to disable accounts when people request us to without loosing their history
• Minor updates to pending project management
• Converted Hovercraft's PHP component from CVS to hg. This will make it easier for developers to develop in branches with better visualization tools.
• Initial support for hg subdirectories (ie, a project can have multiple repositories); see hovercraft project for an example
• Investigating Drupal 6 upgrade

This week I'd like to migrate our mirror composition to our new VM at OSUOSL as well as refocusing on our roadmap for new tasks.

Here at Mozdev, we want to see more add-ons for Firefox Mobile (aka Fennec), so we are teaming up with Mozilla Europe to make a challenge. The task is straightforward. You need only at this time to propose porting your existing add-on to Fennec, or write a new one, with a commitment to finishing it (or at least having a solid proof-of-concept) in time for the Mozilla Maemo Danish Weekend on 30-31 May.

REQUIREMENTS

(We are on a tight schedule and have logistics constraints, so apologise for the deadline and geographical restrictions)
- Write a short proposal stating what your add-on name and current install location, why you think it would be useful to mobile browser users, and how you plan on going about implementing it. Send it to brian@mozdev.org by Friday 15 May, at 12:00 CET.
- This challenge is only open to developers living in Europe.
- The challenge open to current Mozdev project owners, and other developers who host their projects elsewhere.

PRIZE

- 10 developers will be chosen, and Mozilla Europe will sponsor your travel and hotel expenses to attend the Mozilla Maemo Danish Weekend.
- Entries will be judged by Mozdev representatives.

USEFUL RESOURCES

http://wiki.maemo.org/MozillaMaemoDanishWeekend
http://www.mozilla.org/projects/fennec/1.0b1/releasenotes/
https://wiki.mozilla.org/Mobile/Fennec/Extensions
https://wiki.mozilla.org/Mobile/Fennec/Architecture
http://starkravingfinkle.org/blog/tags/mobile/
http://www.mozdev.org/projects/applications/Fennec.html
https://addons.mozilla.org/en-US/fennec/

• bug#20466 - edit-in-place has been tested in IE and deployed to production for testing. If you're interested in helping out with testing, feel free to get in touch with us (comment or feedback).
• Fixed drupal subscription problem occurring for approx. last 2 weeks
• For project requests, we now allow existing project owners to submit auto-approved project requests and confirmation emails now contain a link to confirm submission (rather than requiring an email response). The admins also have an RSS feed for tracking pending project status. We're hoping this is just another step to lower the barrier for getting a project set up at Mozdev.

This week I'd like to continue writing testing and writing docs for edit-in-place.

One of the primary goals of Mozdev recently has been to make using our services easier. We recognize that using CVS for everything can be quite a burden, and we've been planning on addressing this for some time. One thing we feel could help new projects get off the ground faster is to remove the burden of using CVS for managing their web site.

Our edit-in-place implementation tries to stay out of the user's way as much as possible. Once you're logged in to your project, hovering over certain regions highlights them to mark that they're editable. We're using mozile for our editing component along with a custom saving plugin to save each region independently and commit it to CVS. We also have custom commands for uploading images and adding new pages to your project.

This still needs some testing, so if you're interested in trying this out for your project, let us know. You'll need to be using the standard Mozdev theme and should be be using only static content in your web pages (any dynamic content in the pages will be removed when the changes are saved).