Wednesday, May 9, 2012

UDS-Q Day 1

I'm starting this series of posting a little late, but it's time for  the Ubuntu Develop Summit for Quantal Qeutzal in Oakland, California!  :)

UDS-Q

I'm excited about attending my second UDS, not the least of which is because I was going to give a presentation Ubuntu Studio during the Plenaries in front of several hundred people.

However, in contrast to UDS-P, I didn't have a particular goal giving the event an overarching direction.  I went to UDS-P in Orlando, Florida with a major goal of building support to get the -lowlatency kernel into the repositories (which happened).  This time I was going with the flow.

Incidentally, an unusual outgrowth of last year's UDS is that I spent quite a bit of time re-introducing myself.  Last UDS I had a beard while this year I reverted back to my normal appearance.

Keynote

It all started off with Mark's keynote speech.  Some of what he spoke about was the HUD, Ubuntu for Android, Ubuntu TV, and the theme for this release.

It was all quite inspirational and it is clearly a very exciting and creative time to be using and working on Ubuntu.  I see that amazing and pervasive things are happening and Ubuntu 12.04 was just the start of it.

What followed next was the blur of many sessions and even more people.  Luckily a few serendipitous meetings stand out for me and Ubuntu Studio.

-lowlatency Kernel

One such meeting resulted in the suggestion that I should attempt to get the Ubuntu Kernel Team to maintain the -lowlatency kernel instead of the Ubuntu Studio team.

The main reason is that the patch to make the changes to the configuration files is very small (a purported "2 lines") and could easy be made into a build option which all could be completely automated.  Every security patch would happen concurrently as the main kernels are updated and without any additional effort.

In contrast, the Ubuntu Studio team needs to manually update the -lowlatency kernel, which is not an inappreciable amount of work, for each security update.  And these sometimes lag a bit due to scheduling.

Although further discussion about the archive reorganization might effect this issue, it seems that obvious blockers do not exists.

This would be a major improvement to remove a significant responsibility and time commitment from our small team.

JuJu Studio

I view things differently than others, quite often seeing things in abstract ways.  I want to disintermediate (oh crap, I realize I've been using this term wrong :P ) the desktop from between the user and their applications.  I want our creative users to have transparent and direct access to their tools to avoid hindering the creative process.

After learning about JuJu and Charms, and seeing how excited Jorge Castro was about them, I wondered if they might help Ubuntu Studio users.

My poor explanation is that JuJu is a framework to deploy and manage web infrastructures and Charms are the recipes defining which actions are necessary.  Think of this as packaging a formula for a string of applications and settings in order to accomplish a specific goal.  Brilliant!

That's what I want to do with work flows and Ubuntu Studio.

For example, let's say that a user wants to record his band.  A typical example might be to open qjackctl, start jackd with certain settings, open Ardour, start with a particular template, open particular effects, set typical settings on said effects, and finally make the typical audio connections.

Could a user employ Studio JuJu to run a "record my band" charm to accomplish the same, repetitive, deterministic steps each time?

I hope so.  I'll be talking to Jorge or someone on his team.

Automated Studio Testing

Often I cannot find session that I immediately know relates to Ubuntu Studio and I pick a session that interests me.  Many times it turns out that it does.

One such session made me aware that the Ubuntu Studio team would probably benefit from some of the tools used by the QA team to perform automated testing on ISO images.

Automating the standard ISO testing of the Ubuntu Studio presents a chance to dramatically reduce the work load on the team, which would afford us more time to do further, deeper testing.  This should result in greater overall quality for our users.

I hope to discuss this with Gema Gomez during the week.

finis

So, a call to my wife and kids (love and miss you all), followed by almost three hours of residual (non-Canonical/Ubuntu) work that I was unable to complete before coming here, and I wrap the day up and look forward to the next.

2 comments:

Anonymous said...

The studio idea is very fine. "Atypical example might be to open qjackctl, start jackd with certain settings, open Ardour"

Bluntly speaking, your tools need decent names and conventions. A studio edition needs to appeal beyond a limited geek circle.

Scott Lavender said...

@anonymous,

to be blunt as well, some of your criticism is fair but i would also say it displays a certain "remote" perspective.

i cannot control the application names as i an not the upstream developer of them. it sees implied by your comment that you think i (or our team) has named them or can change their names; this leads me to think you are not familiar with open source software. am i reading too much into your comment?

i am unsure what is meant by 'decent conventions'.

i do agree, however, with appealing towards an extended non-geek circle. this is a long term goal that is certainly achievable, but will require appreciable consideration, work, and testing before it has a chance to be successful.

cheers.