The primary focus of this meeting will be on team governance, as Cody Somerville is transitioning out of his role as primary project leader.  With that, we’ll be discussing changes to the Xubuntu Strategy Document.  However, there are still a few other topics to be discussed, and you can add topics to the agenda.

Hope to see you there!

Hello Xubuntu users!

As you may know, Thursday 22nd October we are releasing Xubuntu 9.10 Release Candidate. This is a very important milestone, as it will be very similar to final Xubuntu 9.10 (between them, only very critical fixes will be accepted).

For the 9.10 release we are having very little coverage of Xubuntu images and we would need a harder effort for the RC milestone.

To help, you will need an account in the ISO tracker [1]. This blog post is useful as starting guide:

http://tinyurl.com/yjujh6c

Also, one of the common complains about ISO testing is that, when the call for testing is done, it takes too long to download the ISOs for that candidate image.

Preparing today for that moment couldn’t be easier:

dl-ubuntu-test-iso is a script, available as part of the ubuntu-qa-tools, that downloads Ubuntu (+ Kubuntu, Xubuntu, etc) ISO images for testing purposes. The script uses rsync, which means that the second time you run it, it only downloads the changes to each ISO. So, if you use it today, and keep running it every day (or every couple of days), you will be already set up to help when the candidates images for RC start appearing.

You will need a configuration file to tell the script which images your interested in. I have prepared a configuration file for Xubuntu, and it is attached. You will only need to edit it to select which architecture you’re interested in. Save it in you home folder as .dl-ubuntu-test-iso

Once you have save the configuration file:

* If you’re running Karmic, you can install the ubuntu-qa-tools package directly.

$ sudo apt-get install ubuntu-qa-tools
$ dl-ubuntu-test-iso

* If you’re not running Karmic, get the ubuntu-qa-tools from its bazaar repository:

$ bzr branch lp:ubuntu-qa-tools
$ ./ubuntu-qa-tools/dl-ubuntu-

I’ve also been working on the documentation for Xubuntu 9.04, which has been rebased off of the Ubuntu 9.04 documentation for this release.  What this means is that I’ve been able to use bzr to merge in changes from the Ubuntu documentation as they happen, applying them directly to the current branch of Xubuntu documentation.  This is different from prior Xubuntu documentation efforts that had been based off of a much earlier set of Ubuntu docs.

In that sense, I was starting at a bit of a disadvantage – each release brings changes and updates, not only to X/K/Ubuntu itself, but also the associated documentation.  However, by using the current branch of Ubuntu docs as a starting point for this release, and merging in updates as they get applied to Ubuntu documentation, I’ve been able to leverage the ongoing contributions of the Ubuntu documentors and keep the Xubuntu docs more up-to-date.

Using this approach took a little bit of experimenting to find a good workflow for myself, but Bzr has proved to be a more-than-adequate tool for this particular scenario.  For example, the bzr command that I’ve used most frequently as of late involves merging in the specific changes from one Ubuntu documentation revision to another into the Xubuntu documentation branch.  To do that, I’ve just reviewed recent changes to Ubuntu documentation, navigated to my local folder of the Xubuntu documentation branch, and issued a command similar to this one:

bzr merge -r211..212 lp:ubuntu-doc

Here I’m telling bzr to merge in only the differences between revisions number 211 and 212 from the Ubuntu Documentation branch.  Merging in changes between specific revision numbers allows me to cherrypick – I can merge the changes that I want, and skip the changes that I don’t want.  This is helpful because Xubuntu docs will not include the Ubuntu Server Guide (my apologies to Adam Sommer, who has done a ton of great work on the Ubuntu Server Guide for this release), so I have skipped revisions that include updates to the Server Guide.  : /

If there are no conflicts between the merged files, bzr just identifies the changes as modified files – no problems.  Files that contain conflicts are identified by bzr, too, and it is up to me to resolve those conflicts.  Once fixed, I can then use bzr to mark the conflicts as resolved.  The process still requires some manual review on my part, but reviewing someone else’s changes is much easier than writing my own stuff, and gives me more time to focus on documenting the elements that are specific to Xubuntu.

I’m still writing additional documentation that is specific to Xubuntu, but have a little bit of time remaining before string freeze.  : )  At the end of next week, I am going to be travelling to Seattle to visit a friend and her husband, and also attend a documentation conference out there.  I’m going to focus on the Design Strategies, Content Development, and Open Standards tracks.  It should be a great time, and should make for a great learning experience, too.

To enable backports, go to your menu and select Applications > System > Software Sources.  You will be prompted to enter your password, and once the application is fully launched, click on the Updates tab, and place a check in the “Unsupported Updates (intrepid-backports)” box.  Once you’ve marked that box, click on the close icon.  You will be prompted to refresh your software sources, and new updates should then appear.  The upgrade to Xfce 4.4.3 should be included in that set of updates.

Of course, you could update your sources via the command line, too.  I need to run to the airport now, so I’ll leave well enough alone and assume that, if you’re interested in updating your sources list using the command line, you would know how to do so. 

Interested parties can view the Xfce 4.4.3 changelog here.

We have yet to complete our agenda for the upcoming meeting, but one item that will be included is discussion of the new website.  I’ve passed along a draft project plan to Cody Somerville, and he seemed to like what I had prepared.  If we go by what I’ve prepared, we’ll have an internal team of Xubunteros to start things off, and will have an external team of interested, able parties to assist us once we’ve laid the ground work.  Again, I’ll be posting further details once we get that plan in order.

Of course, you could always just show up to the Xubuntu meeting to discuss it with us.  :]

In other news, we are considering using Yelp to display Xubuntu documentation, primarily to limit the discrepancies between common Xubuntu and Ubuntu documentation.  Of course, Xubuntu would still have its own set of Xfce/Xubuntu-specific documentation, but we would be able to base our documentation on the primary base of Ubuntu docs.  One part of the reason for this possible move is that Xubuntu doesn’t have very many system-doc contributors, and adapting the documentation from Ubuntu to Xubuntu is pretty time consuming, but there are technical and content-based reasons for the possible switch, too.

Why is it time consuming?  The root of the matter is that yelp uses special “ghelp” links within the documentation, but the Xubuntu documentation is currently presented in Firefox.  Firefox cannot display ghelp links, so we have to convert all of the ghelp links to accommodate our use of Firefox.  Of course, modifying links is not so difficult, but the linking differences also necessitate that a different structure be used for the documentation files.  In fact, the Xubuntu documentation currently gets validated as one large meta-document based off of the initial index.xml file, and this is not valid docbook.

Relying on Yelp and adapting our documentation later in the release cycle would also allow us to leverage the numerous contributions that are made by the hoards of crazy documentors that submit patches for the Ubuntu system documentation.  Going that route would make it so the Xubuntu docs would be more accurate and comprehensive in terms of the documentation’s relation to the final released product.  More accurate and comprehensive documentation == more awesome documentation.

As a final (seemingly unrelated, but nonethess important!) note, I’d just like to point out the great work that Cody Somerville and some of the other Xubuntu / Xfce contributors have been doing.  For one, Cody took over as the Xubuntu project lead in the early Spring, and has been doing some pretty remarkable work.  He’s not only doing a great job in terms of his own activities, but is doing a great job of enlisting and encouraging the help of others.  I would also like to thank Lionel Le Folgoc and Jérôme Guelfucci for their remarkable packaging and bug triage work.  It looks like Jmak is getting a good start on the artwork for this release, too.

Neato burrito.

One item is an update to the website.  Xubuntu.org is in need of a refresh!  We’ve had a couple of starts and stops on updating it over the last two releases, but nothing noteworthy ever came of it, so this time I’m putting together a project plan that will break the tasks down into smaller chunks with a clear plan for getting things in place.

I’m not going to guarantee that things will work like clockwork, and I’m not even sure who we’re going to get to help out with the website, but I figure that setting a plan with individual bits that people can do one-by-one is more likely to garner success than handing someone the keys to a base Drupal installation and saying, “Have at it!  Let us know when you’re done!”

I’m sure I’ll have more news on that once I’ve got the basic project plan in order, and (of course) we’ll be seeking out help with the website then, too.  If you think you might want to help out, please make a note of it – place a bookmark in the Firefox 3.0 of your mind.  :]  Or you can just read this blog aggregator thingy, and look for more info about the website project plan when I write about it.  Perhaps that would be better than trying to integrate Firefox 3.0 with your brain.

For now, though, work continues on adding poetic, beautiful content to the wiki, and a few documentation ideas are being tossed around amongst Xubuntu folks.  It’s kind of hard(y) to believe that the first Alpha release for Intrepid is less than a week away, but I suppose it’s how things go.

So, with all due respect to my Gnome- and KDE-using brothers and sisters, here they are:

1) Relative lightness – The Xfce desktop loads more quickly than Gnome or KDE desktops, and Xfce applications are built with an emphasis on lightness.  Xubuntu does have a handful of Gnome-based applications (and hence, some Gnome dependencies), but the developers avoid Gnome-lib heaviness where they can, and applications that require Gnome libraries have been only been chosen because they provide vital end-user functionality.

2) Xubuntu is extensible – I used to work at a deli when I was in college, and my boss used to tell me, “You can always add more, but you can never take away.”  He was referring to putting ingredients onto sandwiches, but his statement can also apply to Xubuntu.  You can use the breadth and depth of the Ubuntu repositories to add extra features and functionality that you may want, but the heavier Gnome or Mono libraries aren’t built into Xubuntu’s core, so you can also stick with the lighter choices if the default Xubuntu system suits your needs.

3) You know what you’re doing – Let’s say you’ve been using Ubuntu or Kubuntu for a while, and know your way around a Linux environment.  You know mv, cp, ls, grep, what a “.whatever” file is for . . .  So you don’t need a distro that’s going to hold your hand quite as frequently.  Xubuntu provides you with most of the same features of Ubuntu, but also doesn’t get in your way with a GUI for everything.  This may not be an advantage for some, but may not be a nuisance for those who are knowledgeable about their systems.

4) Reasonably well-documented – A handful of folks have done a lot of work to bring the full-scope of Ubuntu’s quality documentation to Xubuntu for the 8.04 release.  The Xubuntu wiki is undergoing an overhaul, too.  Long-gone are the days (version 6.10…) when Xubuntu’s documentation wasn’t even updated between releases, so the information that you need to get going is available right from your Xubuntu system.  (Now if we could just do more work on Xfce’s own documentation…)

5) Easy to contribute to, valued contributions – The Xubuntu development team is small, which means it’s easy to get involved and contribute.  Have you been hacking away on Ubuntu artwork, but haven’t been getting your contributions into the releases?  Xubuntu has one person who works on all artwork – why not collaborate as part of a small artwork team?  If you are a budding MOTU, you can help package updated Xfce components.  If you are a Drupal nerd, you can help out with the Xubuntu website.  I understand that all projects need help, but Xubuntu could be an option that is right for some people.

6) Hacker ethic – Yes, Gnome and KDE have more community support than Xfce.  Gnome development forges ahead with a large developer and userbase and the support of several large corporations behind it, and KDE has its own large and thriving community.  Yet Xfce is developed by a handful of hackers who have day jobs, and they’ve still managed to create a technically sound desktop environment.  I think that is pretty cool.

7) Hackability – Although I am not a hardcore coder myself, I’ve heard from numerous experienced developers that the Xfce code base is clean and good.  If you are interested in coding, why not get involved in a project that has a clean codebase, and would appreciate your help?  If are interested in Python application development, take a look at the pyxfce bindings for creating Xfce applications in Python.

8.0) An easy transition – The transition to the Xfce environment on Xubuntu is an easy one, particularly for users of Gnome.  The Xubuntu default settings (particularly in regards to the menu bar setup) have been configured in a way that is similar to Gnome’s setup, and Thunar (the Xfce file manager) looks and works in a manner that is very similar to Nautilus, the Gnome file manager.

8.04) Xubuntu has a logo with a cute mouse in it.

I’m not going to pretend to say that Xubuntu has all of the functionality that is present in the Gnome and KDE desktops of Ubuntu and Kubuntu – Xubuntu can’t mount Samba shares by default, and I’m sure that other people can point out other areas where the Xfce desktop in Xubuntu is currently lacking.  But for everyday computing tasks, for users who have lower-powered hardware, for developers who want a system that uses less-resources on their well-powered hardware . . . Xubuntu is a worthwhile option.

Also, I know it’s not much notice, but tomorrow (Wednesday, 2008-03-26) Jono Bacon is leading a Xubuntu-focused meeting in the #ubuntu-meeting channel on the Freenode IRC network.  The meeting will be held at 1900 UTC (2pm Chicago time).  We’re going to discuss Xubuntu’s mission and strategy, and discuss how to pull in some additional development and packaging help.  The Xubuntu team has had a bit of turnover as a result of some internal disputes over default package selection recently, and we think that coming to some kind of a consensus on our project goals will help focus our efforts and help put some of the conflict to rest.

I feel like Xubuntu is moving in a good direction, though.  Cody Somerville looks to be the person who will be leading the project, and he has a good idea of what Xubuntu is about, is technically proficient, and knows how to argue a point rather than getting mixed up in a bunch of jibba jabba.  All good qualities to have in a project leader.  (Cody also made that wiki menu bar on the Xubuntu wiki.)  As much as anyone pays attention to a wiki, perhaps having a well-set wiki with clear paths to help people start getting involved will help things along a little bit, too.

I’m preparing an interblags post that will contain 8.04 reasons for why Ubuntu and Kubuntu users should consider using Xubuntu (it might be more like 8.04 reasons why I like Xubuntu . . . I’m not sure), but it’s not ready yet.  I only have 7.04 reasons so far.  My post should be Hardy, not Feisty.

1) http://www.debian.org/doc/devel-manuals#policy
2) http://www.debian.org/doc/devel-manuals#devref
3) http://www.debian.org/doc/devel-manuals#maint-guide
4) https://wiki.kubuntu.org/PackagingGuide
5) https://wiki.kubuntu.org/PbuilderHowto
6) https://wiki.kubuntu.org/PackagingGuide/Lists/DocumentationResources

He sent them out to the mailing list in advance of a packaging session that’s being held this Sunday at the College of DuPage, in Glen Ellyn, Illinois.

I’m not sure how much we’ll be able to cram into our session that day, but it should be a good start for those of us who aren’t familiar with packaging at all.  As someone who has primarily been focused on assisting with documentation, hopefully some day I’ll at least know how to package the set of docs that we create. 

One thing that stands out to me in the second article, though, is the point about release notes. We didn’t have release notes ready for the final Beta and RC of Xubuntu 7.10, and the final release notes for 7.10 weren’t put together until after the official release. We need to do better with that. I guess I’ll be studying up on what makes good release notes.