Contributor Developments

During the next upcoming development cycles I plan to focus on developing and maintaining increased numbers of contributors  who help with Ubuntu Studio development.

For those who don't remember, I've mentioned it before, but most of the work we do developing Ubuntu Studio really isn't code intensive.  Therefore, you don't need to be a developer to actually help in quite large ways to Ubuntu Studio's development.

Contribute
Previously in an earlier post I noted that "most new contributors failed to have an impact" and a blog comment galvanized me to effect something that I had considered earlier.  In essence, I wanted a 'help wanted' wiki page.

But I felt that in order to be success this page would need certain qualities:

• it should display a focused list of topics needing help
• each topic should be very accessible to new contributors (i.e. not too difficult)
• each topic should have a nominal description (enough to explain without getting into the technicals yet)
• each topic would have a 'resources' link for further research into the topic
• each topic would have a contact link

By providing this scaffolding my expectation is that we will better support new contributors so they are more effective and continue contributing.

So I am very pleased to link to the Ubuntu Studio "Contribute to Development" wiki page.

Any suggestions on how to improve this page are most welcome.

QA ISO Image Testing
Another series of wiki pages that I want to create are themed around QA and testing.

The first one I have created is specific to the QA ISO image testing scheduled before each milestone.  I chose to address this issue first because it is our most ubiquitous demand and, with a low threshold to entry, an easy way for a new contributor to have a large effect immediately.

Why is it demanding?  QA ISO image testing is not difficult to perform, but the images need to be validated multiple times each cycle and completed in a short time.  In short, it is a relatively simple process but cyclic and time sensitive.

Increasing the number of people testing the QA ISO images means that we can react more dynamically and effectively to complete all the required test in the allotted time more easily.  Our goal should be to have enough people testing such that each person should only need to sign up for a single test at each milestone.

This first wiki page is an introduction to the QA ISO  testing process and intended to give a general overview of ISO testing with links to additional sources of information.

It is easy to get started contributing.  New contributors are encourage to visit the Ubuntu Studio QA ISO image page, pick the appropriate architecture, and sign up (account required)for available tests.  As images are available for testing an email will be sent with links to the image and testing instructions.  Sign up now!

Therefore, I am pleased to link to the Ubuntu Studio QA ISO image testing wiki page.

Again, any suggestions on how to improve this page are most welcome.

UDS-P: Day 4 and 5 or Efficacy is an Eight Letter Word

A confession, a transformation, and a few words of thanks all in this rapid fire post.

Is This Thing On?
This is a tricky bit here, trying to explain some personal feelings and stuff without getting all...like a Morrissey fan or something.  I kid!  Well, kinda.  But people who know me know that I'm a directly spoken person, without much artifice or guile, and tend to speak openly even about feelings many do not openly discuss.

So my first two days at UDS were overwhelming as I previously said.  So much going on and I really didn't know how I fit into all of it.  Metaphysically, where am I in the Ubuntu spectrum in relation to everyone else?

Becoming Ubuntu Studio Project Lead wasn't a path or ritual founded on merit, it was an abhorrence of a vacuum.  So I'm basically saying that I filled a void rather than earned the position.  It would be dishonest to say that I am without pride or ego and I was considerably bothered to feel that I was a suboptimal leader devoid of practical experience leading a project inside the Ubuntu ecosphere.

It led to a lot of soul searching.  I found it, my soul that is, in case anyone was worrying.

But I felt a sense of unworthiness being at UDS, especially after hearing many session where I lacked experience to understand all the concepts and considerations and I almost felt that someone would tap me on the shoulder at some point and tell me that I didn't belong and it would be best to go home.

I suppose I didn't show it, but I was unnerved when Jono made a point of telling me he wanted to discuss some things about Ubuntu Studio with me.  I'm brave enough to admit this now, not then, but I fretted...slightly.  Only slightly.

The third day, however, was a catalyst.

The Skin I'm In
What happened on the third day?  It wasn't a specific event, it was a confluence of a myriad of influences, sweepingly vast and pervasively small.  But mainly it was Kate Stewart.

Starting on Wednesday I began to attend session for release planning, the release team, and how to improve the process.  Ah!  The process.

Again, those who know me know that I am process driven, I need a plan.  If one is missing, I will either create it or instigate group development of one.  I don't crave attention, I'm happy to be part of a well organized team moving towards success, but without a well defined process I am quite unhappy and moved to action.

I learned quite a lot of information about releases and how they would be managed.  The inclusion I felt in turn engendered an amazing sense of efficacy.  I now felt that I could begin to potently effect the changes that I felt were necessary for Ubuntu Studio.

The fourth and fifth days did nothing to dissuade these feelings.  I began to work very late at night to work on additional blueprints, updating wiki pages with planning notes, and carefully evaluating the team's plan for Precise.  I was, and still am, extremely motivated.

I dreamed about making Ubuntu Studio better on both Saturday and Sunday nights.  I'm having trouble keeping focused on my regular job because I just want to work on Ubuntu Studio.

Thank You (Falettinme Be Mice Elf Agin)
Another aspect of what made the UDS a very, very moving experience was the people.

It was simply amazing seeing all the various peoples, from various locales from around the world, with their own various cultures, all working together harmoniously to make the world a better place.

And the personal contacts that I made during the week equally moved me.  I'm horrible remembering names and it became so important to me to remember people that I started to write down names as I learned them and some context to help me remember.  I usually don't do that, most times I smile and talk and before I have even turned away from the person I have already forgotten their name.

Not this time and certainly not these people.

Thank you Mark for Ubuntu.

Thank you Randall for being my roommate, explaining things to a UDS neophyte, and making me be social when it wasn't my first inclination.

Thank you Kate for making me feel included and explaining things when I had so many questions.

Also, thank you Jono for talking to me about Ubuntu and Ubuntu Studio.

There are many other people I will thank, but now right now.  But I will.

UDS-P - Day 2 and 3

So much has been happening that I really haven't had time to keep up with events, blog, and maintain other requirements in a timely manner, so I'm going to combine day 2 and 3 into a single post.

Day two was a pretty incredible day.  I was still adjusting to what a UDS is but starting to find my stride.  Again, the excitement and feeling of purpose is palpable.  It's a tangible manifestation that becomes another participating occupant in the room.

It is an understatement to say that exciting things are happening.

On Tuesday I began to find myself participating more in the sessions.  I'm not sure if it was because I found my rhythm, became more confident about my standing at UDS, or I was more passionate about these particular sessions.  Either way it felt good to have an impact and hopefully make an appreciable difference.

It didn't hurt that Tuesday morning started out by shaking hands with a millionaire astronaut either.  That doesn't happen very often for me ;)

This morning started out rewarding as well.  I ended up seated with a couple of the guys from Novacut and discussed audio settings in Ubuntu and Ubuntu Studio as they were concerned about proper audio support.  I really enjoyed that face to face interaction and collaboration.  It would be cool to keep that interaction and collaboration continuing.

I led the -lowlatency blueprint session this morning and I felt it went well.  Amazing, actually.  Several kernel guys showed up and really helped develop a proper action plan and will even help test the kernel.  Andy and Steve's support blew me away.  Others showed up as well and have expressed interest in helping not only with the kernel but also with Ubuntu Studio!  Brilliant!

I have met so many people over the past three days that I found it necessary to start logging the names, brief descriptions of the context, and any follow that I need to do.  So many contacts are being made with so many opportunities to make Ubuntu Studio better.  Capital!

Now that I've knocked out a couple of blog posts it's back to the session and after dinner I need to work on organizing some of those amazing things I'm supposed to be doing with Ubuntu Studio.

A Kernel for All Seasons

I have received quite a bit of feedback recently on the pursuit of a -lowlatency kernel for Ubuntu Studio and it appears that my efforts to concisely explain and document the requirements for such a kernel and available methodology of achieving it are deficient.  I will attempt to correct this state.

I will start with the reasons Ubuntu Studio desires a different kernel and the paths that lead to the current state.

Into My Own Thing
I would posit that most Ubuntu Studio users are mostly concerned with audio recording and as such they desire a stable, low latency.  Let's break "stable, low latency" down for easy consumption.

• Latency can be simply defined as the time between when a sound is generated and it is heard
• Low latency is desired because higher latencies (i.e. delay) can be confusing and throw off any sense of rhythm if the sound is heard later than you expect it
• Lastly, we want a stable latency because we want to avoid xruns (underruns or overruns in the buffer) which can introduce pops, clicks, digital distortion, and other unwanted noise into your music

Trying to record music in time with other music is unachievable if the latencies are too high.  An unstable latencies could introduce an unwanted and unpleasant artifact as a result of an xrun into that solo you spent weeks trying to get just right!

Additionally, numerous laptop users using Firewire audio interfaces have suffered from irq conflicts.

Explained more accessibly, the Firewire interfaces might share a bus with and compete against other devices for attention from the motherboard.  These Interrupt Requests (irq's) are prioritized and sometimes other items are more highly prioritized than the audio interface.  Not a completely correct analogy, but musicians would prefer that the audio was properly recorded over the mouse updating its position on the monitor.

Historically only the -rt (or -realtime) kernel would provide this functionality via Ingo's patch.  However, code from the -rt patch has been integrated into the main kernel tree and this particular functionality is now available in the => 2.6.39 -generic kernel.

You Can Make It If You Try
Sometimes you can define your path by defining where you can't go, so let's explore our constraints to see where our true direction lies. 

The largest constraint is that the process for building the Ubuntu Studio image is an automated process (or daemon called buildd, I believe) which can only use packages that are inside the official Ubuntu repository (also called archive). Again, using exclusion; we cannot use packages from PPA's (Personal Package Archives), or the kernel that guy made over there at another multimedia distro, or even a kernel from Debian. And even if Debian has a -rt kernel, Ubuntu will NOT sync that kernel into the repositories as Ubuntu rolls their own.

Therefore, our options are to use a kernel package from either the Main or Universe repository to build our image.

Next, the Ubuntu Kernel Team is NOT going to build and maintain an additional kernel.  I don't blame them, this is a lot of additional work and responsibility, especially for a rather small niche of highly expectant users, and the kernel team does enough already.  And since this kernel will be maintained by non-core-dev individuals, this package falls under the purview of MOTU and will reside in the Universe repository.

Therefore, this new kernel will be a community (i.e. Ubuntu Studio developers) supported kernel... in an Inception-like abstract, a community within a community.

Our path, in this context, is that the Ubuntu Studio developers are to build a kernel that will be archived in the Universe repository.


Dance to the Music
So the last movement of this piece is defining which kernel to built.

The -rt time kernel has some significant aspects, both good and bad.

GOOD - it can provide exceedingly good low latencies

BAD - it requires an invasive patch that isn't always available to align with Ubuntu's chosen kernel version, requires compiling some video drivers again

NEITHER - irq threading to prevent irq conflicts isn't an issue anymore as the -generic kernel now provides this functionality.

In my opinion, the -lowlatency kernel has exceedingly more positives than negatives.

GOOD - can be based on the Ubuntu kernel which keeps versions aligned, only requires compile time flag changes to build, doesn't require additional video driver building, provides good latencies

BAD - doesn't provide as good latencies as -rt

While we found that the -lowlatency kernel generally didn't perform quite as well as the -rt kernel we did establish that most testers found that latencies were more than acceptable.  Some hardware sets will be the exception, but we believe we will be able to adequately support the majority of users with this kernel.

Therefore, it seems the most practical decision is to move towards the -lowlatency for its performance, availability, and longevity

Summary
And this leaves us with Professor Plum with the candlestick in the library.  Kidding.

Hopefully, this post explains Ubuntu Studio's kernel considerations, the possible and tenable vectors for acquiring a kernel, and the decisions for choosing the -lowlatency kernel.

-lowlatency kernel for Ubuntu Studio

Just a quick note to mention that I will be hosting a session tomorrow, Wednesday November 2nd at 10:00 a.m. EST, for getting the -lowlatency kernel into the Ubuntu repositories.

This is currently important for Ubuntu Studio because this would allow us to ship a tuned kernel for audio recording as the default kernel.

This is a great time for those who are interested to get involved because we will certainly need community support for a variety of tasks to get this done.  These tasks will be defined and/or refined during the session and available afterwards in the blueprint in the Whiteboard section [1].

Everyone can attend the session via IRC [2] and can view the preliminary action plan and watch the changes live in the etherpad [3].

 This is a great opportunity for the Ubuntu Studio community and your involvement can directly affect the result.



[1] https://blueprints.launchpad.net/ubuntu/+spec/other-p-lowlatency
[2] freenode in #ubuntu-uds-Antigua4
[3] http://summit.ubuntu.com/uds-p/meeting/19798/other-p-lowlatency/

UDS-P - Day 1

Wow!  I'm sitting here waiting for my next session trying to find words to describe the first day of my very first day of UDS and cannot seem to complete that task.

Some words, themes, and descriptions comes easy.

It was slightly overwhelming.

The almost manic crush of people, the tangible sense of purpose, the driven pacing of schedules, and my almost complete ignorance of many of the session topics left me feeling battered, both physically and mentally.

After the Meet and Greet I was slightly reeling and needing respite, rest, and rejuvenation.  I intended to join the practice for the Ubuntu All Stars band but ended up going back to my room.

It was amazing.

I met an incredible number of people, many with whom I had conversed in IRC.  A greater, more dynamic, and multidimensional relationship has now been established with these people.

Networking has also been very rewarding and I met many more people that those I had previously known before.  In particular, some were particularly rewarding in acquiring a direction for my own tasks and goals.

And it was equally rewarding in meeting those who are extremely well known throughout the Canonical/Ubuntu ecosphere, even if the only exposure or experience with them was introductions and a handshake.

Hope, Thy Name is UDS
My first day has imbued me with a great sense of optimism, purpose, and responsibility.

I have received a great amount of relevant, explicit, and concise information and I feel that this has greatly improved the existing plan of action for Ubuntu Studio.

I feel that I have never had such opportunity to effect change as now and this has certainly strengthened the my sense of responsibility.

What I've Learned
Some simple lessons include bringing a smaller laptop with a better working battery, better preparation for session scheduling, and extremely comfortable shoes.

Less pedestrian, I have learned more about infrastructure and how Ubuntu builds this wonderful product.

But perhaps, that most important, I have learned a great deal about one of Jono's favorite words...community.  I hope to keep learning about it.