Coworking

I've been working for Canonical for around four years now, and for the vast majority of that time I've worked out of a room in my house. You need to have a certain style of discipline to work effectively from home and I like to think that I have that.

More recently I've been feeling a little down about work in general. I think it is because I am insulated and tend to get a lot of information from blogs, a number of feeds, twitter, identi.ca, facebook and email lists. A lot of the information that I then get exposed to is often from the vocal minority, and this can be a little draining.

Last Friday I started spending some of my work day at the distiller lab. I have to say it has been great for my general state of mind. Today is my forth day in a row spending some time here and so far, so good.

Wikkid Wiki

As with any creation being released, I'm writing this with some trepidation. I'd like to announce the first release, 0.1, of Wikkid Wiki.

What is it?

Wikkid is a wiki that uses the Bazaar DVCS as an underlying storage model. Wiki pages are text files in a branch.

Why another wiki, surely there are enough already?

There is the obvious reason, because I felt like it. But this is not the primary reason. Since I started working for Canonical I've come to appreciate the whole culture of free, libre, and open source software more. During the day I work on Launchpad. Primarily in the area of integrating the Bazaar DVCS. Launchpad doesn't have a wiki integrated, and it is my plan to see wikkid be the wiki that is integrated.

I have to admit to having very strong opinions myself on what I wanted for wikis in Launchpad. I've tried to encapsulate that in the vision below. Since no one else was looking at it, I took it upon myself. Discussions started last year between a small group of Launchpad developers, but there was no traction. At the start of March I started writing the Bazaar backed wiki. It needed a name though. Thankfully after trying several I got the perfect name from Aaron Bentley - wikkid.

The wikkid vision

• Any wikkid wiki can be branched locally for off line editing.


• Any branch can be viewed using wikkid - not limited to branches created through wikkid


• A local wikkid server can be run using a Bazaar plugin


• Local commits use the local users Bazaar identity


• Wikkid can be configured to operate in a stand alone, public facing mode where it has a database of users


• Wikkid can be integrated as a library into other python applications


• Wikkid uses standard wiki markup languages - not inventing its own

What does Wikkid Wiki offer?

Right now, wikkid offers basic page editing, rendering and browsing.

• ReST is the default wiki format


• Creole 1.0 is also supported (as long as the first line is "# creole")


• source files are syntax highlighted using pygments


• you get to see your gravatar for your local Bazaar identity


• no page locks are used, but instead a three way merge


• conflicts due to concurrent editing are shown for the user to resolve

Where to from here?

Well here is just the beginning. The TODO file is quite long already, and
that is just a simple brain dump.

Things that I want to have done for 0.2 include:

• Change the underlying server from twisted.web to WSGI


• Change the generated URL format


• Add the stand-alone user database code, along with sessions and logins and email validation


• Add a view to show changes for a page


• Allow the reverting of any historical change


• Daily build of trunk into the wikkid developer's PPA

Ideally for the 0.2 release I'd like to provide everything that is needed for
wikkid to be deployed as a stand-alone, public facing, wiki.

Wow, how can I help?

Wikkid uses Launchpad for colaboration and project tracking -
https://launchpad.net/wikkid.

• You can get a copy of trunk using 'bzr branch lp:wikkid'


• File bugs for any issues you find playing with it


• Join the development and discussion mailing list


• If you feel so inclined, you could implement a feature or fix a bug, push the branch to Launchpad and propose the merge


• Come and chat in #wikkid on freenode, nothing fires developers up like having encouraging users

Launchpad code update

We've been very busy over the last couple of months with lots of changes that most people will never notice.

Reduced latency

Branches pushed to Launchpad are now immediately available over http to anonymous readers of the branch, which includes the loggerhead code browser.

Code review email changes

When proposing a branch for review the initial emails and subsequent comments will now come in order. Previously if someone commented before the script that generated the diff was run, the comment would be emailed out first, now it isn't.

Teams requested to review now get email

Everyone in the team that is requested to review will get email now. This is a blessing for those that want it, and almost a curse for those that aren't interested. Launchpad adds a number of email headers to help users with filtering of email. Here is an example from an email I received:


X-Launchpad-Message-Rationale: Reviewer @drizzle-developers
X-Launchpad-Notification-Type: code-review
X-Launchpad-Project: drizzle


Since it was a team that was requested to review, there is the @drizzle-developers added to the X-Launchpad-Message-Rationale. If I was personally asked to review, the header would just say Reviewer.

Build branch to archive

This was the original name of the feature, but it is more about recipes now. A recipe is a collection of instructions on how to build a source package. We are still testing this internally, but I'm hoping to get this enabled on edge very soon. This will be extended to add daily builds.

What does this really mean?

Lets say you want to have a daily build of a project, like gwibber. You would then create a recipe that uses trunk as a base branch, merge in the packaging info, and say "Please build this every day into my PPA". And Launchpad will.

Trivial bugs

This is just a quick note really. One thing I've been trying to do more and more is to address simple bugs in a more timely manner.

I use the tag "trivial" to indicate to me that the bug is very simple to fix. By this I mean that I should be able to have the fix and the test all written in under an hour, and normally under 30 minutes.

Personally I'm (hopefully) fixing one trivial bug a day in addition to other work. This way the simple bugs get some attention, and I get the feeling of accomplishing something when other things are in the pipeline that take longer to get completed.

My scheduling of trivial bugs is somewhat arbitrary. Often the most recently commented on trivial bug will get my attention.