Almost, But Not Quite, Entirely Unlike Tea

Tales of belonging, public speaking, and discourse.  And not a Nutrimatic Drinks Dispenser in sight.

Ubuntu Membership
I've begun my application for Ubuntu Membership on my wiki.ubuntu.com personal wiki page.

Other than the status it provides I'm not sure that I will see much benefit, but I've been encouraged by a few key individuals to complete this and therefore I shall.  When good guidance is proffered I am not one to question it.

However, I am reminded that there is one definitive benefit from membership that I do desire; syndication on Planet Ubuntu.  It is this medium that I expect to leverage and bring Ubuntu Studio more to the fore of mass consciousness.  Oh, aye!

But given my personality I feel compelled that my application not only demonstrate, but also embody, the concept of thoroughness.  And although I probably have enough done and probably should start the process proper, I feel I still need to develop a few more aspects of my application.

Since other tasks are being juggled concurrently I would expect completion by this weekend.  Then I can request testimonials, and finally, formally apply to one of the regional boards.

I think there may be some difficulty getting some of the boards to evaluate any application, much less my own.  The America's Board has applications pending from December of 2009.  The Middle East Board has recently announced a June 1st meeting, which may be too soon.  However, the Asia Board appears to have one every month.

I'll shoot for the Middle East Board meeting if I can meet a few milestones in the next two days, otherwise I'll wait for the next Asia Board meeting.

Either way I'll be happy to have the application ready and can move onto other activities requiring my attention.

Open Source Musician's Interview
The other interesting thing to mention is my interview on the Open Source Musician Podcast.

Dan and Steve are super nice guys and really deserve credit for creating a bit of an grass roots groundswell around open source and musicians.  Their IRC channel (#opensourcemusicians on Freenode) always seems to have activity and usually has some interesting things going on.

Anyway, Ricardo (rlameiro) set the whole thing in motion and it was supposed to be me and stochastic.  Stochastic, however, missed the interview and I did it alone.

I had listened to several episodes before so I basically knew what to expect.  As I said before, Dan (who I think has a voice made for radio) and Steve are easy going guys so it was a relaxed event and I think it came out pretty good.

You can download and listen to the interview here.

My main box had a Hardy install (my main recording partition) and various Lucid Beta installs since we were in the middle of testing Lucid, therefore I used my laptop with a vanilla Karmic install to record the interview.   I ended up rather disappointed with how I sound; I recorded it using a rather inexpensive microphone headset, Pulse Audio, and Skype, the result was my voice sounded very tinny and had a discernible buzz.

But overall I was very happy with the interview and look forward to doing another one with them when I have something worthwhile to tell them again.

Communication
A hallmark I would like to develop is consistent communication with the users, which encourages reciprocative discourse or actions.

A simple post, email, or news item should help to keep the community informed, building a sense of trust and commitment.  A 21th century Fireside Chat with FDR, if you will allow the comparison.

In this format, communication probably will not take the form of long, laborious missives.  Rather, it will likely be short and to the point.

Examples might include:

• informing users of project direction and goals
• soliciting user suggestions opinions
• updating users of project goal accomplishment
• reminding users of upcoming milestones
• and requesting user testing

Currently I envision no more than two weeks between communiqués.  But can be reevaluated as necessary.

And hopefully, an informed and educated community results in an active and involved community.

The Best Laid Schemes o' Mice an' Men

I've been queried about my views of Ubuntu Studio's future; therefore, I will expound some of their intricacies now.  All while serendipitously keeping your window button firmly planted on the right side of your window and in the correct order.

Thank You (Falettinme Be Mice Elf Agin)
Intrinsically I tend to gravitate towards order and structure.  It's not a neurosis, I can function within chaos (and sometimes it is fun to do so), but I typically prefer not to do so.

Mainly it's that I'm an objective or goal oriented person and as such I find that I accomplish them more effectively with order, structure, and a plan.  Generally speaking, the trip is enjoyable but I derive a greater sense of reward from the accomplishment of Something Getting Done (huh, we've seen that before, haven't we?).

Also, as the kid who read the cereal box because I couldn't dully, sedentarily, and illiterately eat my breakfast cereal, I often ponder over topics of interest in an almost obsessive manner.  I'm not omniscient, I just have a hard time stopping my brain from devoting CPU cycles sometimes.

These are the qualities I feel I bring to Ubuntu Studio.  And hopefully an enthusiastically and passionately fresh perspective as well.

Everyday People
The most immediate goal I would like to approach would be to clearly define Ubuntu Studio's audience.  Some would argue that Ubuntu Studio has always had a definitive audience from it's inception.  Others argue otherwise, as they are wont to do.

I wasn't involved during those times so I cannot support either side.  But I would posit that in either case, both Ubuntu Studio and it's audience have evolved since Ubuntu Studio's genesis.  It would interesting to see if they have diverged and are incongruent now.

During this cycle (Maverick Meerkat) I am hoping to obtain qualitative and pervasive information about our audience and their needs.  My initial suggestion is to create an online survey, but I'm hoping we can develop other methods to supplement this approach.

The first tangible benefit of this process should be to determine how effective or successful we are in meeting our audience's needs.  Obviously, when we have a more concise and thorough definition of their needs then we are in a better position to address them.

Sing a Simple Song
Another tangible benefit, although not for our audience, is possibly reducing scope.  Now, before all two of this blog's follower email me with nasty comments and disreputable questioning of my parentage, I want to clarify my position.

Ubuntu Studio has taken a scattered and broad approach to application inclusion and fulfilling audience needs.  While I will not critique Ubuntu Studio as "bloated", I would suggest it demonstrates symptoms of limited "application creep".

I suspect that the attempts to fulfill user's needs have historically been based less on evaluating data and more on gut feelings or good intentions.  It is also possible that applications were included simply because of a "because it's available and we can" mentality.

The analyzing, inquisitive reader might have shrewd questions materialize in their heads, such as:

• Why is reducing scope a benefit?
• Oi, if the benefit isn't for the audience, then for whom is it a benefit?
• To be, or not to be: that is the question

Firstly, allow me to preface my answers by stating, "An application without a need is useless indeed!"  While not quite Shakespeare (but then what is these days?), this mantra would serve us well to remember.

That bit of poetry aside, addressing the first question; reducing Ubuntu Studio's scope minimizes the workload and responsibilities of the developers.

You might have noticed that I deftly answered the second question as well in one quick, sharp witted but cleanly spoken stroke!

Additionally, it should be pointed out that removing unnecessary applications also reduces the size of the ISO that is downloaded.  This curious phenomenon benefits not only Canonical's server bandwidth but also the hapless users who have a slow internet connection.

Lastly, I would point out that the last bullet point is in fact a statement, not a question, and I retort, "Cudgel thy brains no more about it, for your dull ass will not mend his pace with beating."

Hopefully I have deflected any possible hostile or aggressive emails by demonstrating the possibly substantial and appreciable benefits from evaluating the current application scope in contrast with defined user's needs.

Admittedly, I do not expect to find large tracts of applications that will qualify for scope reduction and furthermore, staunch resistance is expected to removing those that might be considered.  Granted, the potential also exists that we find solid justification for every package we currently have, which would be equally accepted.

It's a Family Affair
Refinements in our package development and maintenance would be something else I would like to improve by leveraging our relationship with Debian.

For the uninitiated, Ubuntu is based on Debian and many Ubuntu packages are derived directly from the Debian archives.  At the beginning of each Ubuntu release cycle packages not in the Ubuntu archives are automatically synced from the Debian archives.

Additionally (and more specifically), I would be remiss to not mention that the Debian Multimedia Team provides many audio specific packages to Ubuntu Studio via the previously mentioned syncing methodology.  Many thanks to the Debian Multimedia Team, without whom Ubuntu Studio would probably be a pale shadow of what it currently is.

Also of import, Debian seems to have a very robust and active program for adding new packages to their archives in comparison with Ubuntu.

Therefore, I would like to see new multimedia packages (e.g. LV2 packages) make their way into Ubuntu Studio via Debian and the Debian Multimedia Team if possible.  Given our lack of dedicated packagers and the Debian Multimedia Team's fastidiousness (non-derogatory), this becomes a no-brainer.  Their quality and throughput is magnitudes beyond what we can accomplish given an identical time scale.

While one of Debian's strengths lies in it's packaging, in a symbiotic twist, Ubuntu's stregnth lies in it's quantity of users.  This manifests itself, amongst other ways, as filed bug reports and patches submitted.  Therefore, we should be attempting to push bug fixing patches back to Debian where applicable rather than only patch them in the Ubuntu repositories.  Sometimes it is not applicable as Ubuntu is different than Debian and sometimes packages require specific moderations.

Reducing the delta between the Debian and Ubuntu packages will allow for auto-syncing at the beginning of each release.  Therefore, pushing patches back to Debian will not only help keep Debian and Ubuntu's package archives up to date but it will also reduce the workload on the Ubuntu Studio developers.

I believe there is great potential for both groups to mutually benefit from a closer working relationship and I hope we can explore it.

I Want To Take You Higher
Lastly I want to mention the possibility of developing new audiences.

This is not to imply that we would abandon our current audience; that would be silly given that I have discussed trying to definitively understand their needs and address them.  This has already been misunderstood so I want to say it clearly:

Engaging a new audience does not preclude continuing a commitment to an existing audience.

New audiences potentially could provide Ubuntu Studio with a substantial quantity of new users who could also go on to report bugs, help the development team or even develop their own audio centric applications.

Each of these new users, especially if it breaks out of the Ubuntu/Linux circle, could possibly engage in advocacy in a manner and effectiveness that has been yet seen.

This isn't a decision to pursue new audiences, rather, it's a decision to explore the possibility of developing new audiences.  Possible audiences need to be identified, their needs understood and our abilities to fulfill their needs evaluated before any decisions should be made.

I would expect that at the end of Maverick we might have begun to identify new audiences and their needs and might require a year (or more) to make a definitive decision, develop a plan, and begin to implement that plan.

It will possibly be a lot of work to successfully engage and support a new audience but the returns could be equally as rewarding.

In Time
Other items exist to be pursued that that not only require fewer literary tracts for explanation but also are not governed by or fit into a desirable timetable.  Some may be deferred due to interest or availability of resources, but hopefully these will all be addressed, just some sooner than others.  These include (in no particular order):

LV2 - packaging the LV2 effects, plugins, and generators started last cycle and continues to be an active goal right now thanks to quadrispro
JACK2/Pulse Audio - developing functional integration between JACK2 and Pulse Audio via dbus is another active project headed up by TheMuso
network manager - a common and familiar problem that finally received a bug report and is now being addressed, thanks to Ricardo (rlameiro) for filing the bug
update website - something that has been long overdue, we have a general direction and now hopefully progress will be made thanks to detrate.  I have high hopes that this accomplishment will have an expansive and dynamic effect with users
fill team positions - as all team positions are effectively empty, this is something that desperately needs to be addressed and i am hopeful that within the next month significant progress can be made, especially for the tech lead position
ubuntustudio-controls - updates are needed since JACK now handles rtprio and memlock in /etc/security/limits.d/audio.conf but Ricardo (rlameiro) would additionally like to explore a redesign which I would like to potentially leverage to include other activities that users routinely perform for setting up their boxes
Ubuntu Studio backports PPA - since the official backport team is pretty busy and our applications fill a niche need we might consider a backports PPA for our users, much like KDE maintains, to provide more immediate access to backported applications
documentation - more documentation is the obvious and immediate thought, but I would like to explore defining and possibly reorganizing the scopes of the wiki.ubuntu.com vs. help.ubuntu.com websites as they relate to Ubuntu Studio
decision documentation - who wants to repeat history? We should document reasons for certain decisions so that users understand why those decisions were made, plus we can keep knowledge continuity within the developer team even with member attrition.
testing procedures - I feel very, very strongly that if we want users to help us test Ubuntu Studio then we need to explicitly provide instructions explaining every step and expectation, therefore we need to develop clearly identified and documented testing procedures.  If this is effected we will significantly lower the threshold for users that might help us.  I am hoping that stochastic and I can work together to accomplish this, or at least start making appreciable progress, soon.
user communication - another topic about which I hold very, very passionate feelings.  I want to develop effective, consistent, pervasive, and thorough communication with our users to help develop a vibrant, dynamic relationship with the developers.  I believe a direct correlation will become evident between effective communication with users and their participation in development.  And this is to everyone's benefit.

 (You Caught Me) Smilin'
These are currently my immediate and foremost thoughts, more or less, about Ubuntu Studio and the its future.  Nothing shocking perhaps, but hopefully they align with the "do one thing and do it well" ethos.

I feel this is an excitingly enviable juncture in Ubuntu Studio's development and I am fortunate to be part of a project with so much exceptional potential, where we are only limited by our own desires and commitment.

Of course, this potential that would not exists if not for giants elevating us.  Hopefully all those who contribute to Ubuntu Studio's development will seize this opportunity and accomplish something worthy of having stood on their shoulders.


Lastly, please feel free to share your thoughts and opinions with me by commenting or emailing me directly at scottalavender@gmail.com.

Shaping the Future

Discussing leadership and quite possibly some of the biggest changes to Ubuntu Studio in a single release cycle, in more than 144 characters but in less than or equal to one blog post.

Take Me To Your Leader
Last night was an unusual night on #ubuntustudio-devel.  Usually the channel is pretty quite but we had continuing discourse for approximately seven hours.

Several times during the conversations Cory intimated that I should or was leading the project.  Other times some indirectly referred to me as the "leader".

It reached a climax when Troy asked who _was_ the lead and I said that I had volunteered as acting lead since no one else had stepped up.  This was the first time to make such a statement in a related public forum.

Aside from a few ominous statements ("Then the project's fat rests in your hands") that sprinkled the remainder of the discussion, the announcement seemed to be palatably received.

I don't feel much of a leader at the moment as I currently do not have a definitive "vision" of what the project should be, although I do not feel daunted or intimidated by the absence.

Originally I had considered that I might perform as a steward, just providing stability, organization, and direction, until someone more appropriate was identified.

Now, however, I do not think this is probable, so if no one were to object I would accept the responsibility of Project Lead for the indeterminate future.

When Seeing is More Than "Vision"
Although the discussion started with updating the website, Troy and Emmet directed the topic into trying to define Ubuntu Studio, its mission statement, and its audience.

It quickly became obvious none of these had been defined before.

One thing that *did* become obvious was that we probably would reduce the scope of the project.  This might be important, so I'll say it again: we probably would reduce the scope of the project.

However, all this is speculative discussion without basis until we clearly and definitively define our audience, their needs, and our goals to meet those needs.

But, it is possible this could be a very, very pivotal period in Ubuntu Studio's history.

Who knows, next release we might have an stripped down audio-centric distribution, with extremely limited video/graphical applications, that fits onto a CD, and is distributed as a LiveCD!  Oh, and Pulse Audio completed removed and using JACK as the sole sound server which starts automatically when logging in.  And the coup de grace would be installing Network Manager as so many users have asked.

There you go, this could be the next version of Ubuntu Studio.  Or not.

How Do We Get There From Here?

Starting to follow Troy Sobotka's advice from IRC and discuss openly what I've kept pretty quite starting with Ubuntu Studio's leadership and how it effects me.

But before I get started I should mention that I think Troy should go to medical school.  To me, his name just sounds like a doctor's name.  Try it, say it out loud...Dr. Troy Sobotka.  Sounds Hippocratic to me.

Disclaimer: The things I state are my opinions based on my perspective and I'm probably wrong on most, if not all, accounts.  Enjoy!

Leadership, It Does a Project Good
For some time, those with a keen eye and quick wit should have noticed the implosion of the Ubuntu Studio team leadership.  And not to point the Finger of Blame ™ at someone, but it started when Cory needed to step down originally as project lead.

Cory had to do what he had to do, but that was the demarcation of when the project transitioned from involved, decisive project leadership into something different.  Even when Cory returned, he couldn't commit the necessary time and was ineffective.

But that was better than suffering with a token leader, which we did.  And again, I don't fault someone for not having time, but in this case I can be critical for some not being forthcoming with their involvement status.  I feel that courtesy (or respect perhaps) for the others involved would demand it.

Nonsupporting Cast?
Slowly other supporting members have fallen away.  Like unnamed cast members from a science fiction show that join the away party on the unknown and unavoidably hostile planet, they were not destined to stay with us long apparently.

Luis has effectively not been involved for some time, even when he was.  Luke is now leaving, a great blow in my opinion and his leaving castrates the project rendering it far less potent.  Heh, how's that for a metaphor?  Probably not the one you wanted.

The three already mentioned were the core team at one point.  No more.

Others have limited involvement, although some might have more involvement behind the scenes that I am aware.

I don't think I've ever seen Andrew Hunter directly involved with Ubuntu Studio (but he could be managing packages for all I know), Jussi is around and offers opinions and gives suggestions but I don't know what else he does, and I don't even know what crimsum's real name is, much less what he does.

But no one has been really that visibly active that I have seen.  Except Eric.

I Will Not Repeat Myself Again.  I Said...
When I joined the project, Eric was Getting Things Done.  Yes, I used capitalized words because he was really doing things.  Visible things.  And lot of them.

Me for my part, I like when Things Get Done.  That's means something is Being Done Right.

So now that I've got my feet under me a little more and I can be a little more effective, it's a little frustrating that he is also beginning to minimize his involvement.  I was hoping he would assume the mantle of leadership and we could Really Get Things Done.  I added another capitalized word to the original sentence, that makes it even more impressive, and disappointing.

Again, this is not meant to be accusatory, I just unreservedly prefer to state my views directly and openly.  But to see the same cycle repeat itself is like an unfriendly kick in the groin, as opposed to a friendly one.

* insert history aphorism here *

History, The Lesser of Two Evils?
I like history, it offers great lessons.  I just don't like it when those lessons are repeated on me.  And now I'm part of that lesson.  But what can I take from it?

Warning:  Direct and Over Simplistic Discourse Follows!

With strong leadership Ubuntu Studio progressively makes improvement.  Devoid of strong leadership it meanders at best, flounder at worst.

The former statement is applicable to Cory's first tenure when the project first started.  He was direct and forceful but tractable strides of progress were achieved.

I believe the later statement applies to everything since.

So here we see a good history lesson and we can choose to learn from it.  Or not.

Please note that the statement, "Or not." does not mean to choose not to learn from it but rather not to choose to learn from it.  There is a distinction. 

To Lead or Not To Lead, That is the Question
I think Ubuntu Studio is important, perhaps even the premier media creating distribution.

So, this is an interesting situation.

I've thought about it for almost two months and Ubuntu Studio is holistically important to me, too important for me to stand impotently by and watch it succumb to entropy.

So, I will step up and conduct myself as acting project lead.

Why "acting lead"?  Because, while I do not believe that I am the best choice, I am certainly better than no one.  If some suitably capable person should desire to be project lead then I will support them and the project as I can, but just as another developer.

But until that time Ubuntu Studio is too important to me to allow it wander course without anyone at the helm looking to the future with seeing eyes and steadying the present with firm, guiding hands.

of Whats and Wheres

I've been busy, really busy, and at length I plan to talk about it.  I shan't do it all at once and it probably will be parsed between several posts over several weeks.  So, let's begin.

Back in February I embarked upon the RPM Challenge for the second year in a row.  The goal of the challenge is to record ten songs, or thirty-five minutes of music, during the month of February.  Writing the material during February is encouraged but not required and music that has been recorded previously is explicitly prohibited.

My name for the project is wirblewind and my page can be found here:  http://wirblewind.rpmchallenge.com/

Although I did not quite reach the ten song or thirty-five minutes of music goal, I accomplished several other goals.  Given that I only managed a single "song" last year, I am quite pleased by the progress, which was a goal.

Everything was recorded in Ubuntu Studio.  I'm proud of that as well.

Of all the songs, I'm quite pleased with Werewolf Baby for several reasons.  Specifically, I'm happy with the production of the song and believe it to be the best sounding of all the songs.  Also, this song was specifically written with a genre and subject matter in mind.

Normally, most of my songs are developed organically and I usually cannot direct their development.  In a very Zen matter, they are and I am only discovering them rather then creating them.  This one germinated from an idea and developed as a result and stayed rather true to it's roots.

The last topic I will discuss in this blog will be a conversation and its implications that I had with someone in the #ubuntustudio-devel channel on IRC.

Troy_S told me I should write, really write, about my thoughts on Ubuntu Studio instead of using this blog as a notepad to record technical minutiae of some accomplishment for future reference.

Troy is an interesting guy and comes from a very different place than I.  That's not a bad thing and I don't think we clash with each other, we are just different shades of color.  If I was Black Sabbath then he would be Joy Division.

I'm working my way through a couple of books he suggested to me about graphic arts and design.  Bloody good books they are!  I'm learning loads of new stuff, things I never considered or was aware of before.

Anyway, I'm going to do what he said.  I'm going to open up more about my thoughts on Ubuntu Studio and where it's heading as I've held those very close to the vest for the most part.  And hopefully no one gets upset about some of the things I might write :)

But just not at this particular juncture in time.  But soon, as I plan on writing more frequently here.

Of Branches and Trunks

My Plymouth theme changes were merged into the official trunk of the ubuntustudio-look package last night.  This is amazing.

Firstly, it's my first code that has been accepted into an official Ubuntu Studio package.

Secondly, this is something extremely visible as it will be the first (and mandatory) thing seen as Ubuntu Studio boots up.  And it is at this stage that I really, really hope it works!

Lastly, this is for a Long Term Supports release so my contribution will be relevant for three years!  Of course, unless someone else (or me) creates another theme and then replaces mine.  This seems unlikely unless my theme is borked somehow as there are many other, more important things to worry about.

Backporting packages was one thing.  Working on packaging a new application is another.  But this step is way beyond either of those.  Truly exciting, both for my contributions but also for my development.

REVU: First Blood

Today I submitted a revised zynjacku to REVU in response to my first comments by Fabrice.  I had already submitted revision to lintian, tool to dissects Debian packages and tries to find bugs and policy violations, warnings.

This took a little longer that I had hoped but I quickly addressed everything after the latest Ubuntu Studio meeting.  I notably had trouble getting zynjacku to compile using Debhelper7, although it should have been a snap.  If my past experience is any inidcator, then it's the dope behind the weapon, not the dope on the weapon.  I ended up reverting back to the long /debian/rules file.

Hopefully this will secure the first Advocate and can quickly acquire another Advocate in time for Lucid Feature Freeze.