It’s official, UDS 13.05 is coming up next month, marking our second online Ubuntu Developer Summit, and coming only two months after the last one. While going virtual was part of our transition to make Ubuntu’s development more open and inclusive, the other side of that coin was to start holding them more often. The first we put into affect in March, and the second is coming in May. Read below for information about this UDS, and changes that have been made in response to feedback from the last one.

Scheduling

The dates for UDS 13.05 are May 14, 15 and 16, from 1400 UTC to 2000 UTC.  We will once again have 5 tracks: App Development, Community, Client, Server & Cloud and Foundations.  The track leads for these will be:

• App Development: Alan Pope, David Planella & Michael Hall
• Community: Daniel Holbach, Nick Skaggs & Jono Bacon
• Client: Jason Warner & Sebastien Bacher
• Server & Cloud: Dave Walker & Antonio Rosales
• Foundations: Steve Langasek

Track leads will be in charge of approving Blueprints and getting them on the schedule.  If you are going to be responsible for running a session, please get with the track lead to make sure they have marked you as being required for that session. If you would like to get a session added for this UDS, you can do so either through registering a Blueprint or proposing a meeting through Summit itself.  Both approaches will require the approval of a Track Lead, so make sure you discuss it with them ahead of time.

Changes to…

Using feedback from attendees of the March UDS, we will be implementing a number of changes for UDS 13.05 to improve the experience.

Hangouts

Google+ Hangouts have a limit of 15 active participants (if started with a Canonical user account, it’s 10 if you don’t have a Google Apps domain), but in practice we rarely had that many people join in the last UDS.  This time around we’re going to encourage more people to join the video, especially community participants, so please check your webcams and microphones ahead of time to be ready.  If you want to join, just ask one of the session leaders on IRC for the hangout URL. We are also investigating ways to embed the IRC conversations in the Hangout window, to make it easier for those on the video to keep track of the conversation happening there.

The Plenaries

Most people agreed that the mid-day plenaries didn’t work as well online as they do in person.  There was also a desire to have a mid-day break to allow people to eat, stretch, or hold a sidebar conversation with somebody.  So we are replacing the mid-day plenaries with a “lunch” slot, giving you an hour break to do whatever you need to do. We will be keeping the introductory plenary on the morning of the first day, because that helps set the tone, goals and information needed for the rest of the week.  In addition to that, we have added back a closing plenary at the end of the last day, where track leads will be able to give a summary of the discussions and decisions made.

The Schedule

In addition to the above plenary changes, we have added an extra day to this UDS, making it 3 days instead of two.  The last day will allow for overflow of sessions that couldn’t fit into 2 days, or the scheduling of follow-up session when it is determined they are necessary following a discussion earlier in the week.

Registration

Registration to attend will now be done in Summit itself, rather than through a Launchpad Sprint.  So if you’re not a track lead, and you’re not registering Blueprints, there’s nothing you need to do on Launchpad itself.  This will help those who do not have a Launchpad profile, though you will still need an Ubuntu SSO account to log in.

To register for UDS 13.04, go to the summit page, and just above the schedule you will see an orange “Register in Summit” button.  If you don’t see that, you either need to log in to  summit or you’ve already registered.

Summit Scheduler

Chris Johnston and Adnane Belmadiaf have been working hard to improve the Summit Scheduler website, taking feedback from attendees to improve the interface and workflow of the site.  We will include as many enhancements as possible before the start of UDS 13.05.  If you are interested in helping improve it, and you have some web development skills, please find them on #ubuntu-website on Freenode to find out how you can get involved.

Read more

After being away and enjoying some lovely downtime, I've returned to the online world to be met with the rush of a virtual UDS, a rolling release announcement, and a new windowing stack announcement. With the discussion advancing and the UDS sessions completed, it's time to weigh in and speak my thoughts as well.

I'd like to stare down the scarecrow -- that is, let us examine the straw man argument of a rolling release.

On a rolling release
I am definitely in favor of streamlining what we ship and support. The inter-LTS releases in general only make sense to run until the next one arrives. From a quality perspective, I really like what we've done with precise. I think it's an excellent solid base and the point releases we've done keep it relevant and offer a really nice way to get the latest stuff and keep a stable and long-term supported system.

As for a rolling release with LTS's sprinkled in, I have run a rolling release distro in the past (alongside ubuntu). I definitely enjoyed having access to the latest stuff, and having everyone on the same archive all the time (community-wise) kept us tighter and more able to relate and help each other. Overall, I think the pros outweigh the cons on moving towards it, but I have several caveats with the current approach.

• Monthly snapshots
• As Colin Watson put it, if we're presumbly releasing and testing a monthly snapshot, we failed in a rolling release sense -- we don't have daily quality.
• In general, I don't see a target audience for a monthly snapshot. Why can't we create an installer image (do full testing milestone on it), then call it gold for a long period (until new installer changes we want to bring in, which require us making a new image). In other words, I would like to see us only generating new images for an actual release (in this case only LTS's), or for a new installer. (Note that I mean supported images (in any sense), not just an image for testing)
• Quasi-rolling mentatility
• It seems like we want to support the idea of users running a snapshot of our archive on a certain date, and then only update at certain days and times
• This is insane fragmentation and defeats the purpose of being a rolling release. People should strive to run up-to-date systems, and always be current. For us, we need to ensure the archive is always upgradeable so they can do so
• LTS point-releases
• Continue and enhance point-releases for LTS to keep regular flows of new, well supported and stable software
• This was discussed and well noted in discussions and at UDS. As I mentioned, I really like how precise is going, and we can continue and bolster these efforts even more in a rolling world.

On flavors
I will prefix everything I say here with the fact I have never put together and supported a flavor, but I most certainly have enjoyed utilizing them, and working with members of the community who focus there efforts on them.

I was able to catch the end of the UDS session on flavors and had an excellent discussion with some folks from xubuntu and kubuntu. Thanks to those folks who helped provide some flavor feedback on the proposal.

I would like to challenge the flavors to engage in healthy discussions about how there release process works, how to serve the needs of there users, and how to make the best use of there time and resources. I'm sure this type of introspection happens in each flavor on a regular basis, but I'd like to call special attention to how releases work.

Last cycle, ubuntu adopted a cadence for driving quality into the daily images. This work has been on-going since precise really, and rick's idea's for a rolling model continue this line of thinking. If you'll ask the community folks who helped be a part of these cadences, they can tell you it was a challenging change, but we're really hitting our stride now. The constant iterations on how we test and what we do I think had been extremely positive towards helping quality make a bigger impact.

With that in mind, our release processes shouldn't be exempted from this. QA (and development :-) ) efforts are seen as linked to the current release process, resulting in chaos if you are radical enough to unlink them. So what options (in my opinion!) of course exist for a flavor in this new world?

• LTS only
• Some flavors have already gone to an LTS only model, and I think it's been extremely helpful for those who've done so, in terms of what they can focus on without worrying about supporting lots of releases.
• Rolling only
• You can chose to go full force into a rolling release, and eschew LTS's altogether
• 2 year "normal" releases
• You could choose to simply push a new image out every 2 years (like an LTS), but without long term support. Instead, consider supporting until the next (2-years or so) release.
• Keep things as-is
• As kubuntu and others have shown this cycle by not adopting a cadence for testing, you can keep the traditional model in place. The buildbots are still there, the testing tools still exist, and the knowledge and experience in releasing on a 6 month cadence is there. Remember, ubuntu itself has synced from upstream debian every 6 months; a flavor could choose to do the same with ubuntu.

Now of all these options, at this point I would personally recommend adopting the LTS only model. Work with and sync your development to your upstream project and land your work in the rolling release. Release an LTS as normal and deliver timely point release updates to the LTS. There is nothing stopping you from even delivering these point releases every 6 months (or a different timetable!), emulating the current process but with a stable ubuntu LTS base and a simplified upgrade process.

On some alternative ideas

6-8? month-stable releases between LTS

Not a bad idea for retaining the flavor of the current system. Indeed, if you really like the idea of monthly snapshots and updating, this is probably the better way to do it. However I don't think it solves any issues for an OEM or for flavors. Namely, the release support timeline is too short for an OEM to base an image on, while for flavors, it would force an even faster cadence and churn upon users. I also don't see a target audience for it. Who would run this, but not run a rolling? Folks who want stability couldn't adopt such a small supported time-frame, and I feel like our efforts to test and release would be wasted as we throw it away as soon as the next stable is out.

Don't change anything!
This idea is just a knee-jerk reaction to change. Unless you feel like our last release was the pinnacle of perfection (I don't), we should be evaluating how we do things, iterate and try and do them better. 

On quality in a rolling release
I want to talk specifically about quality as that's what is dearest to me. How do you ensure quality in a rolling release world?
 
First, I would like to challenge you on what you mean by quality. Is older software better quality than newer software? Age != quality, even though we often traverse down that slippery slope. I wrote about this before, but simply put how we define quality is subjective. For the sake of comparison here, let's talk about quality as having a desktop that just works. That is, your hardware works and the applications and software running on it enables you to accomplish your tasks without issue.

So, with that in mind, how does that work in a rolling release? If you've run the development versions of ubuntu in the past, there have been times where a bad package may have rendered your system unbootable. For any user trying to run this as there daily system, it's obvious that level of 'quality' doesn't work. But at the same time, I've found bugs running the development version of ubuntu that cause actual crashes (see this for example), yet have little impact (if any) on my system working properly to enable me to accomplish my tasks. So how can we define quality metrics (and we should!) for each release? Here's a quick summary of my expectations in extremely simple terms:

• LTS
• No issue that hinders or prevents utilizing ubuntu
• Rolling
• No issue that would cause a crash for expected usecases and workflows

The key difference to me is usability. If I am forced to use a workaround for a crash in a minor application or task in a rolling release is probably ok. Note that I say probably, because well, we haven't defined these metrics yet as a community. Being forced to do so in an LTS is not an acceptable level of quality. And of course, causing a system to not boot is never acceptable.

On the reaction and the future
I'm excited to see these discussions taking place, and I would encourage people to think critically and take part in these discussions. There are definitely some wonderful ideas and conversation taking place.

Just remember we're a team and all part of ubuntu. Healthy debate is a very important part of continuing to better ourselves as a community and project. 

Read more

The inaugural online UDS (or vUDS as it’s becoming known) is underway. This brings with it a number of new challenges in terms of running a good session. Having sat in on a few sessions yesterday and been the session lead for several sessions at physical UDS’s going back nearly two years now, I thought I’d jot down a few tips on how to run a good session.

Prepare

Regardless of whether the session is physical or virtual, it’s always important to prepare. The purpose of a UDS session is to get feedback on some proposed plan of work (even if it is extremely nebulous at the time of the session). Past experience shows that sessions are always more productive where most of the plan is already fleshed out prior to the session and the session basically functions as a review/comments meeting. This depends on your particular case though, since the thing you are planning may not be possible to flesh out in a lot of detail without feedback. I personally find this is rarely the case though.

Be punctual

UDS runs on a tight schedule, at least in the physical version, although I don’t see any good reason why this should change for vUDS. Punctuality is therefore important not as good manners but from a practical point of view. You need to time to compose yourself, find notes and make sure everything is set up. For a physical UDS this would have been to check microphones are working and projectors are projecting. For a vUDS, in my brief experience, this means making sure everyone who needs to be is invited into the hangout and that the etherpad is up and the video feed is working on the session page.

Delegate

As the session lead it is your responsibility to run a good session, however it will be impossible for you to perform all the tasks required to achieve this on your own. Someone needs to be making notes on the Etherpad and someone needs to be monitoring IRC. You should also be looking out for questions yourself but since you may be concentrating on conveying information and answering other questions, you do need help with this.

Avoid going off track

Time is limited in a UDS session and you may have a lot of points to get through. Be wary of getting distracted from the point of the session and discussing things that may not be entirely relevant. Don’t be afraid to cut people short – if the question is important to them then you can follow up offline later.

Manage threads of communication

This one is quite vUDS specific, but especially now that audiovisual participation is limited, it is important that all of the conversation take place in one spot. Particularly for people who are catching up with the video streams later on. Don’t allow a parallel conversation to develop on IRC if possible. If someone asks a question in IRC, repeat it to the video audience and answer it in the hangout, not on IRC. If someone is talking a lot in IRC and even answering questions, do invite them into the hangout so that what they’re saying can be recorded. It may not be possible to avoid this entirely, but as session lead you need to do your best to mitigate it.

Follow up

Not so much a tip for running a good session, but for getting the best from a good session. Remember to read the notes from the session and rewatch the video so that you can use the feedback to adapt your plan and find places to follow up.

That’s all there is to say, I really hope this first virtual UDS goes very well and that sessions are productive for everyone involved.

Read more

Shortly after the Ubuntu App Showdown earlier this year, Didier Roche and Michael Terry kicked off a series of discussions about a ground-up re-write of Quickly.  Not only would this fix many of the complications app developers experienced during the Showdown competition, but it would also make it easier to write tools around Quickly itself.

Unfortunately, neither Didier nor Michael were going to have much time this cycle to work on the reboot.  We had a UDS session to discuss the initiative, but we were going to need community contributions in order to get it done.

JFDI

I was very excited about the prospects of a Quickly reboot, but knowing that the current maintainers weren’t going to have time to work on it was a bit of a concern.  So much so, that during my 9+ hour flight from Orlando to Copenhagen, I decided to have a go at it myself. Between the flight, a layover in Frankfurt without wifi, and a few late nights in the Bella Sky hotel, I had the start of something promising enough to present during the UDS session.  I was pleased that both Didier and Michael liked my approach, and gave me some very good feedback on where to take it next.  Add another 9+ hour flight home, and I had a foundation on which a reboot can begin.

Where is stands now

My code branch is now a part of the Quickly project on Launchpad, you can grab a copy of it by running bzr branch lp:quickly/reboot.  The code currently provides some basic command-line functionality (including shell completion), as well as base classes for Templates, Projects and Commands.  I’ve begun porting the ubuntu-application template, reusing the current project_root files, but built on the new foundation.  Currently only the ‘create’ and ‘run’ commands have been converted to the new object-oriented command class.

I also have examples showing how this new approach will allow template authors to easily sub-class Templates and Commands, by starting both a port of the ubuntu-cli template, and also creating an ubuntu-git-application template that uses git instead of bzr.

What comes next

This is only the very beginning of the reboot process, and there is still a massive amount of work to be done.  For starters, the whole thing needs to be converted from Python 2 to Python 3, which should be relatively easy except for one area that does some import trickery (to keep Templates as python modules, without having to install them to PYTHON_PATH).  The Command class also needs to gain argument parameters, so they can be easily introspected to see what arguments they can take on the command line.  And the whole thing needs to gain a structured meta-data output mechanism so that non-Python application can still query it for information about available templates, a project’s commands and their arguments.

Where you come in

As I said at the beginning of the post, this reboot can only succeed if it has community contributions.  The groundwork has been laid, but there’s a lot more work to be done than I can do myself.  Our 13.04 goal is to have all of the existing functionality and templates (with the exception of the Flash template) ported to the reboot.  I can use help with the inner-working of Quickly core, but I absolutely need help porting the existing templates.

The new Template and Command classes make this much easier (in my opinion, anyway), so it will mostly be a matter of copy/paste/tweak from the old commands to the new ones. In many cases, it will make sense to sub-class and re-use parts of one Template or Command in another, further reducing the amount of work.

Getting started

If you are interested in helping with this effort, or if you simply want to take the current work for a spin, the first thing you should do is grab the code (bzr branch lp:quickly/reboot).  You can call the quickly binary by running ./bin/quickly from within the project’s root.

Some things you can try are:

./bin/quickly create ubuntu-application /tmp/foo

This will create a new python-gtk project called ‘foo’ in /tmp/foo.  You can then call:

./bin/quickly -p /tmp/foo run

This will run the applicaiton.  Note that you can use -p /path/to/project to make the command run against a specific project, without having to actually be in that directory.  If you are in that directory, you won’t need to use -p (but you will need to give the full path to the new quickly binary).

If you are interested in the templates, they are in ./data/templates/, each folder name corresponds to a template name.  The code will look for a class called Template in the base python namespace for the template (in ubuntu-application/__init__.py for example), which must be a subclass of the BaseTemplate class.  You don’t have to define the class there, but you do need to import it there.  Commands are added to the Template class definition, they can take arguments at the time you define them (see code for examples), and their .run() method will be called when invoked from the command line.  Unlike Templates, Commands can be defined anywhere, with any name, as long as they subclass BaseCommand and are attached to a template.

Read more

Our UDS in Copenhagen was the busiest for me ever, but I enjoyed it a lot. There was heaps of energy, good ideas and many good conclusions for the Raring cycle. One thing I really enjoyed was the Leadership Mini-Summit.

We had it at UDSes two times before and what I feel we did better this time around was that we had more concrete examples of Ubuntu teams, their leadership and the challenges we face. It gave us a great opportunity to be together, brainstorm and learn from each other.

I volunteered to give a brief summary for all those who could not attend this time around. The following points are all based on my memory and our notes of the event. Lots of other brief conversations happened there as well.

• Actively training successors: we discussed a number of interesting experiences in teams and found that some teams had problems finding successors, especially in teams where leadership had been in the same hands for a longer time. We found that when the structures of new team, where things are more open and free-form, slowly moved towards more structure and more processes this might lead to the feeling that things are tedious to main and some fatigue.
  Somebody noted that when finding new leadership and key people in the team, that it’s important to note who has a special skill (maybe presenting or organising or just a special interest), and even if they are a bit reluctant in the beginning, give them lots of positive encouragement and form a personal relationship with them. Their interests are obviously important too.
  Another point mentioned was that sometimes it’s necessary and important to scale back activities if necessary. Also to harness volunteer energy when it’s there.
  Some mentioned that they had been in touch with a new class of contributors: users who need more of a framework, more instructions and were generally less self-starting. Others mentioned they had met people who had misconceptions about involvement in Ubuntu, that there are requirements or they need to be “allowed to” work on something rather than just jumping in. We should definitely encourage these people to get involved. As leaders in the community we should strive to empower others to do things like give the presentations at their events rather than inviting us to do them.
  It’s also important to always provide lists of opportunities (a TODO list basically).
• Milestones and mid-cycle check points for community projects.
  Some team members found this very useful in watching their team projects progress during the cycle. Most technical teams use work items and blueprints which through our infrastructure are used very well. In less technical teams they are used much less.
  What everybody agreed on was that they’d try to get more team reports and use work items as well.
• Ubuntu Member “incubator”.
  Some noticed a concern around great contributors who for reasons of their own didn’t want to apply for Ubuntu membership. Sometimes it was lack of knowledge about it, others said they didn’t know why and other just didn’t feel they were ready yet, although they clearly were.
  We will review our Membership documentation to make it clearer what Ubuntu membership is there for and how it is important.
  There were also some related discussions about how some members were just interested in becoming members and then dropped their activities. Discussions around this did not come to any conclusions though.
• How to respond to “How can I get involved?”
  Some teams mentioned they had had great results with one-to-one mentoring, other teams said they were overwhelmed by requests for 1-on-1 mentoring. Everybody agreed that it was important to not drown potential new contributors with “walls of text”, but that for more diverse projects a simple flow chart could help to explore interests. In there it would be important to define “requirements” for the involvement, but to be encouraging at the same time.
  Some work will go into a proof-of-concept flow-chart which then could then be re-used and translated.
• Some good ideas for LoCos in general. (These ideas turned up in various discussions.)
  One team had a meeting where lots of people had lots of ideas, but no concrete outcomes or plans of action. Some said that it’d help to categorise the ideas and try to group people into teams who could then collaborate and present their work the next time.
  In another part of the conversation we talked about “official events” and “big events”. Everybody agreed that it’d help to generally try to also encourage small, fun events, like Ubuntu Hours for example.
  Although there were conflicting views on how to organise a big LoCo in general, everybody agreed that it was important to encourage a feeling of one team, no matter which part of the state/country the contributors are from.

Many other topics were discussed as well and it was great to see how we, once we sat together, solve problems together and inspire/help each other. Thanks a lot everyone for turning up.

The work items we agreed on were:

• Daniel to write a blog post about the Leadership Mini-Summit.
• Alan to draft proof-of-concept workflow diagram to visualise activities in a team. Daniel to help publicise it and get feedback.
• José to edit the Question2Answer template and ask to get localized version of a Q&A system.
• Daniel to add flavour teams to CC checkup schedule and mail CC list about the idea to reach out to regularly teams to check in how they’re doing.
• Chris to check into automating the team reports by way of the LoCo Team Portal, and try and get it implemented. Pasi to work on a proof-of-concept for a simple website for sending and gathering team reports easily.
• Daniel to bring up the idea of creating a mailing list for the broader community (we can use it for announcements).
• Laura to mail all councils/boards who can approve members to notify the CC about new members.
• Joel to review https://wiki.ubuntu.com/Membership and send suggestion to CC.

Thanks again and good work everyone!

Read more

Greetings from Copenhagen! I thought I would give a mid-UDS checkup for the quality team community. You may have already heard some of the exciting stuff that is already been discussed at UDS. Automated testing is being pursued with full vigor, the release schedule has been changed, and cadence testing is in. In addition, ubuntu is being focused into getting into fighting shape by targeting the Nexus 7 as a reference platform for mobile.

I was honored enough to have a quick plenary where attendees here got to see and hear about the various automated testing efforts going on. Does that mean the machines have replaced us? Hardly! The goal with bringing automated testing online is to help us be more proactive with how and why we test. We've done an amazing job of reacting to changes and bugs, but now as a community I would like us to focus on being proactive with our testing. The changes below are all going to help set us firmly in this direction. By proactively testing things, we eliminate bugs, and repetitive or duplicated work for ourselves. This frees us to explore more focused, more interesting, and more in-depth testing. So without further ado, here's a quick rundown of the changes discussed here in Copenhagen -- hang on to your testing hats!

Release
The Release schedule has dropped all alphas, and the first beta, resulting in a beta and then final release milestone only. In addition, the freezes have been moved back a few weeks. The end result is the archive will not be frozen till late in the cycle, allowing development and testing to continue unencumbered. This of course is for ubuntu only. Which brings us to flavors!


Flavors
Flavors will now have complete control over there releases. They can chose to test, freeze, and re-spin according to there own schedule and timing. Some will adopt ubuntu's schedule, others may retain the old milestones or even do something completely different.


ISOs
Iso's will now be automatically 'smoke' tested before general release. No more completely broken installers on the published images! In addition, the iso's will be published daily as usual, but will not have typical milestones as mentioned above. Preference will be given to the daily iso -- the current one -- throughout the cycle. Testing will occur in a cadence instead of a milestone.

Cadence
Rather than milestones, a bi-weekly cadence of testing will occur with the goal of assuring good quality throughout the release cycle. The cadence weeks will be scheduled and feature testing different pieces of ubuntu in a more focused manner. This includes things like unity, the installer, and new features landing in ubuntu, but will also be the target of feedback from the state of ubuntu quality.

State of ubuntu Quality
A bold effort to generate a high level view of what needs testing and what is working well on a per image basis inside of ubuntu. This is an experimental idea whose implementation will garner feedback early in the cycle and will collect data and influence decisions for testing focus during the cycle. *fingers crossed*

AutoPilot
This tool will integrate xpresser to allow for a complete functional UI testing tool. One of the first focuses for testcases will be automating the installer from a UI perspective to free our manual testing resources from basic installer testing! From the community perspective, we can join in both the writing, and executing of automated, as well as the development of the tool itself.

Hardware Testing Database
This continuing experiment will become more of a reality. The primary focus of the work this cycle will be to bring the tool, HEXR, online and to do basic integration with the qatracker for linking your hardware profiles. In addition, focused hardware testing using the profiles will be explored.

I hope this gives you a nice preview of what's coming. I would encourage you to have a look a the blueprints and pads for the sessions, and ask questions or volunteer to help in places you are interested. I am excited about the opportunities to continue bringing testing to the next level inside of ubuntu. I  owe many thanks to the wonderful community that continues to grow around testing. Here's to a wonderful cycle.

Read more

I trust everyone is readying themselves -- don't blink! Ubuntu UDS-R is already upon us. Those of you who have been watching closely may have heard about some of the planned sessions for QA, but if not feel free to take a look. Don't worry, I'll wait.

But wait, there's more! In addition, there is going to be an evening event where testing is the focus. It's happening Tuesday evening. The goal is to learn about some of the testing efforts going on inside ubuntu, including automated testing; and more importantly, to write some testcases! Folks will be on hand to help talk you through and discuss writing both automated and manual test cases.

Looking through the tsessions, I hope you have the sense that testing is continuing to play a large role in ubuntu. And further, that you can be even more invovled! UI testing, automated testing, testcase writing -- all of these are focus points this cycle and have sessions. Get involved -- and if your at UDS, please do come to a session or two, add your voice, and grab some work items :-) Let's make it happen for next cycle.

Read more

For me this Ubuntu Developer Summit (http://uds.ubuntu.com) is going to be very special. As always I look forward to meet all you great people again – it’s like meeting “the other party family” again.

Ubuntu Development
A number of development-related sessions are on my list as always and they are going to be very interesting.

We are going to kick off with Ubuntu Development Videos, a session where we’ll discuss how to update our Ubuntu Development videos. This is long overdue, and it might be especially interesting, because I received this very special request on IRC:

<bobweaver> dholbach, if you or others make video tutorial of how to 
            package a updated one I will make video of me shaving my 
            head

Let’s make it happen together!

The next question we’re going to ask ourselves is “What new devs should be doing“. We had some success in the last cycle with proposing a number of categorised tasks to new contributors. Let’s build on that and figure out how we can tell new contributors which tasks they can focus on to have a seamless experience which eases them into our community.

In the last cycles it has become a tradition to look at our Packaging Guide and figure out how to improve it. We are very glad to have received countless fantastic contributions in the last few cycles. This puts us into a great position to provide newcomers with help and with expert up-to-date articles. Here we’ll talk about phasing out the old packaging guide and how to improve our support for translations.

The Developer Advisory Team is alive and kicking and has reached out to many new contributors the last cycle. Still there’s a bunch of things we can improve further. If we want to welcome new folks with open arms and get the best out of their feedback, we need a strong DAT. Help us out.

One thing which never failed to inspire me was whenever work of new contributors was showcased. It’s important because we not only want to show our gratitude by showing off great work done by new people, but also to show others that doing Ubuntu development is no crazy rocket science.

We also plan to have two Ubuntu Development workshops.
• Packaging Guide User Testing
• Getting Started with Ubuntu Development

New Exciting Stuff
Readers of my blog have probably figured out by now that I got interested in Automated Testing recently. Personally I think it’s one of the best way to be involved in Ubuntu development, because you essentially ensure (theoretically forever) that a given piece of functionality works. To define how we are going to get more people involved in this initiative, let’s meet at the “Automated Testing Community” session.

Also stay tuned for another special announcement with regard to this.

The Community Track
As Jono is busy becoming a father, (All the best man! Big hugs from here!) I will take care of business at Copenhagen and lead the Community track. We have many many exciting things lined up. The Community Roundtables with huge amounts of interesting topics. And sessions about Ubuntu IRC, Ask Ubuntu, juju, translations, Edubuntu, Lubuntu, the Ubuntu Youth team, Ubuntu Accomplishments, more juju, Ubuntu TV, the Ubuntu Data Mining project, the Debian healthcheck, Ubuntu on Air sessions, the Ubuntu Women team, Xubuntu and many other presentations, discussions and meetings. You can very easily see: the Community Track is where it’s at!

One thing I’d like to highlight is the Ubuntu Leadership Mini-Summit because I feel it’s critical to our success as the Ubuntu project that we figure out how we can lead our respective areas of the community efficiently and learn from each other. Drop by and let’s talk.

You can already see: this UDS is going to be quite busy for me, but it’s also clear that it will kick arse.

Read more

It’s time for some Ubuntu Development Events for those of you who are raring to go get started for 13.04 development.

We will be starting the fun today at 13:00 UTC with Ubuntu Open Week. Luckily I still managed to book a double session, so we’ll have plenty of time to get you started and introduced to Development team and what we do.

The Ubuntu Developer Summit (UDS) will be happening form 29th October to 1st November in Copenhagen and we will have some workshops there as well. If you’re in town, make sure you drop by. Watch the Packaging Guide User Testing and the Get Started with Ubuntu Development workshops. For us it will be great to see how people use the Packaging Guide and what we need to fix. For you it will be great to have people around who are going to help you if you should get stuck. Also it will be a great time to catch up and get to know each other. Thanks a lot to Benjamin Drung (and others) who are going to help with these events.

There will be plenty more activity at UDS which I’ll blog about soon too.

Read more

… for planning things, but also for getting things done.

In-between sessions I had discussions with many many folks and I’m happy to say there was renewed and much interest in the Packaging Guide.

Heroes like Andrew Starr-Bochicchio, Leo Iannacone, Joseph Mills and others have contributed suggestions, code, ideas and text bits to improve the packaging guide, and that’s on top of what was discussed in the session we had.

During the session we identified a number of areas of focus. In no particular order, there’s:

• Include the Packaging Guide in Ubuntu
• Translate it in as many languages as possible
• Merge the Wiki documentation into the guide
• Do user-testing of the guide
• Do an editorial review of all the content

Also in many other sessions, the Packaging Guide was usually deemed the best place to educate new contributors about how things work, which is great.

What happened this week (outside of sessions) already was:

• Andrew trimmed down our CSS usage a lot.
• Andrew reviewed debian/copyright, so we get closer to get it into Ubuntu.
• Leo worked on nice new side-bar.
• I split up the package into various variants of the guide.
• I removed some embedded java script bits.
• …and lots more.

This level of activity is fascinating and bodes well for a great 12.10 cycle.

What I love most about the guide is that everybody can help us if you have just a little bit of interest in Ubuntu Development. Let’s have a quick look at some bugs you could help out with, if you’re interested.

Here’s some ‘bitesize’ bugs, I hope we can you interest in:

1. #885315 traditional-packaging.html is empty, but linked to
2. #885317 add info how to get in touch with other developers, find work, etc
3. #890273 Explain that it’s helpful to split up big changes into multiple commits
4. #922576 Encourage new contributors to check out code and toy around
5. #792495 apt-cache included in basic packaging software section
6. #841946 Advertise ‘setup-packaging-environment’ in getting-set-up article
7. #950227 Use ‘bzr lp-propose’ instead of ‘bzr lp-open’
8. #973887 patches-to-packages refers/links to non existing loom information
9. #997753 documentation typo: “intial” should be “initial”
10. #816427 Mention http://screenshots.debian.net/upload in the packaging-from-scratch sections
11. #978493 “bzr commit” should be “debcommit” in fixing-a-bug.html

Obviously, there’s more bugs and there’s a blueprint to subscribe to. Feel free to grab a bug and help out, or catch us on IRC and find out how you can get involved.

Update: I forgot to mention John Kim, who has contributed a bunch of bug reports with his experience. Great work, John!

Read more

On Monday, Calxeda, one of the leading innovators bringing revolutionary efficiency to the datacenter, unveiled their new EnergyCore reference server live onstage with Mark Shuttleworth at the Ubuntu Developer Summit (UDS) in Oakland California.

 

The choice of UDS at the venue to unveil the new hardware to the world was flattering and underlines how the innovators in next generation computing are building out a compelling platform together. Ubuntu and Calxeda have been working together for several years to bring Ubuntu on Calxeda to market in the form now being shown at UDS. The collaboration of Canonical and the Ubuntu community with Calxeda has been vital to be able to deliver a solution that can very easily deploy OpenStack based cloud using MAAS and Juju on hardware that is so innovative.

The EnergyCore reference server unveiled at UDS can house up to 48 Quadcore nodes at under 300 Watts with up to 24 SATA drives. In this configuration it is possible to house 1000 server instances in a single rack and other server form factors being developed by OEMs may enable several times this volume. It is precisely this type of power efficient technology that will accelerate the adoption of next generation hyperscale services such as cloud and we are proud to be at the very core of it.

So congratulations to Calxeda on the arrival of the EnergyCore and congratulations to Canonical and the Ubuntu Community for providing the platform that will power it.

Read more

Another May, another Ubuntu Developers Summit. This time I am in Oakland, California, USA (even if my tweets shows Dallas, Texas as geolocation).

As usual with US trips this one took insane amount of time. But I was 3cm from not going here… Why? Because I got stuck in toilet at home. Hopefully with help from neighbour I was able to bash door out and get to the bus stop on time.

Then standard set of bus, plane, plane, train and finally arrived in hotel. As my room was not yet ready I got 30$ coupon to bar to not waste time on waiting. Free meal/beer ;)

My room is at 17th floor (which means 15th) and has a nice view in the evening:

On Sunday I went to see San Francisco centre (I saw Golden Gate on earlier visit). Chinatown was interesting experience. Lot of people speaking language which I do not understand, shops full of food which I do not recognize.

Some random photos:

After getting some souvenirs and refilling of my US T-Mobile sim card I decided to go to the cinema for ‘The Avengers’ movie. It was nice experience. Touchscreen operated ticket machines which allow to buy ticket in one minute (but people were standing in long queue to buy tickets in ‘normal way’) made it even better. As in Poland there was big amount of commercials before movie (including some in style “our Army/Navy is great, why not join us”) but what I liked was just-before-movie animation reminding about not talking/texting/tweeting during movie (made with characters from “Madagaskar” series). Have to admit that RealD 3D glasses were more comfortable than Dolby 3D ones used by Polish cinemas. Movie itself was great but I think that will have to see it in Poland due to my English ;D

During evening there was usual Canonical internal plenary and then dinner. I even managed to sleep 6 hours despite jet lag ;D

Monday started with interesting keynote and presentation of Calxeda ARM server using technology they were talking about at previous UDS. Photos:

It is 2U case with 24 Serial-ATA discs and 12 nodes with 4 quad-core EnergyCore processors per node. The only cables inside are power ones as rest of connections is on pcb. Connection with world by four Ethernet connectors.

I went to “Create filesystems for embedded devices” session where we discussed how to make Ubuntu Core even smaller. People mentioned OpenEmbedded, OpenWRT, buildroot as usual, we got some strange use cases too. What will come from it? Time will show.

Plenaries were interesting. First Chris Kenyon told about cooperation with OEMs and ODMs and how it relates with Ubuntu. Laptop in a pizza box picture was nice — reminded developer boards. Then Bdale Garbee from HP shown us that there is no way to go though life without being served by HP technologies or hardware. Both talks were great and I hope that rest of plenaries will be like that.

After plenaries I went to San Francisco to register at Tizen conference and to meet some friends from Maemo times. Technical showcase and partner demos were boring and it was hard to feel that it is something innovative. But who knows… maybe Tizen will be yet another phone/tablet/ivi/etc OS even when Moblin, Maemo, MeeGo did not succeed.

During evening (back at UDS) there was ‘Meet & greet” social event. Our Linaro group (Amber, Ricardo, Paul, me) was showing member boards and replying to misc questions from audience.

What next? Sessions, social events, discussions about my patches with other developers, some sight-seeing.

---

All rights reserved © Marcin Juszkiewicz
UDS-Q was originally posted on Marcin Juszkiewicz website

Read more

My big focus during the week of UDS will be on improving our Application Developer story, tools and services.  Ubuntu 12.04 is already an excellent platform for app developers, now we need to work on spreading awareness of what we offer and polishing any rough edges we find.  Below are the list of sessions I’ll be leading or participating in that focus on these tasks.

• Upstream App Developer Documentation
  Identify tutorials and documentation needed by upstream developers to port and integrate their applications with Ubuntu and Unity
• App Developer events
  Promote and run a successful series of online app developer events, including at least:
  - The Ubuntu App Developer Week
  - The Ubuntu App Developer Contest
• Ubuntu platform API documentation
  Identify which APIs need to be documented for application developers and ways in which we can provide these APIs in a developer friendly way
• Upstream App Developer Support
  Provide support and mentoring resources for upstream app developers who want to port or integrate their application with Ubuntu and Unity
• Promote and encourage upstream delivery in Ubuntu
  Get more app developers talking about Ubuntu and targeting Ubuntu. Promote Ubuntu as a platform in the places independent app developers socialize.
• Upstream App Developer Outreach
  Identify and engage targetted upstreams to submit their apps to the Ubuntu Software Centre
• Ubuntu App Developer Site incremental improvements
  Building upon the foundations of the initial Ubuntu App Developer site, we’d like to expand it on a second design phase.
• App Developer external outreach
  We want to increase the visibility and awareness of Ubuntu app development outside of the regular Ubuntu channels.
• MyApps submission experience and expectations for upstreams
  Review the current process and identify which parts of the documentation need to be improved. Also figure out what specifically we expect from upstreams and which help the ARB can provide.
• Advertise new apps in the Software Center
  Promote the availability of new apps in the Software Center, both in USC itself and through other channels, to raise awareness of apps targeting Ubuntu

And if you’re curious about what else I’ll be up to, my full schedule for the week can be found here: http://summit.ubuntu.com/uds-q/participant/mhall119/

Read more

The Ubuntu Florida LoCo Team is my home team, and this cycle I will once again be meeting up with Chris Johnston to participate in the Ubuntu Global Jam.  Since Chris is the one organizing this event again, I asked him a few questions about it.

Tell me about yourself and how you are involved in Ubuntu

My name is Chris Johnston. I got involved in Ubuntu about 3 years ago. I started by attending a Florida LoCo Team event at Michael Hall’s house. I got involved with the Ubuntu Beginners Team, the Classroom Team, and the BugSquad. I was one of the original planners of Ubuntu User Days and I got involved in developing for what is now the LoCo Team Portal. After attending my first UDS I saw a need and started coding on the Summit Scheduler. Now days I spend most of my time developing on Summit or the LoCo Team Portal.

Have you organized a Global Jam event before, and if so what was your experience? How did you choose a venue and select activities?

I organized a Global Jam event last cycle. We ended up with only 3 people participating, but we had a productive day hacking on summit.ubuntu.com and even got a new developer involved.

What kinds of activities do you plan of doing as part of your upcoming jam?

During this Global Jam, we will again be working on some of the community supported websites, including Summit and the LoCo Team Portal.

How do you spread the word about your event to get more people to participate?

Through the LoCo Team Portal and talking to people about it.

 

Now it’s time for you all to share your stories about past and future Global Jam events!

Read more

In March I wrote where I will travel. Decided to write such memo at start of year so it will be more visible what my plans are for 2012.

In February I will miss FOSDEM because Linaro Connect Q1.12 will start right after it. So at 4th I will fly to San Francisco for a week. But this time instead of flying back home I decided to spend weekend in New York City where I hope to meet some people from Bug Labs company. You know: we worked with each other for 1.5 year and I met only Peter Semmelhack and Ken Gilmer. Also I plan some sightseeing.

Then a bit of quiet until next Linaro Connect will happen. Probably May but it was not yet decided where and when. As many people I also hope for Asia (never was in this part of world).

Same month there will be Ubuntu Developer Summit somewhere at west coast of USA. Who knows — maybe it will end in trip around the world in May? Sounds interesting but I think that only sounds as it can be hard to survive due to jet lag.

Then July/August another Linaro Connect. No idea where, but hope for Europe. In meantime I may or may not attend Ubuntu Rally (Canonical internal event) which will be somewhere in US (as it follows UDS place).

And end of year will bring yet another Linaro Connect and Ubuntu Developer Summit. Second one in Europe.

What else? Probably LinuxTag if company events will not be at same time, maybe something local (there are few conferences planned in Szczecin).

Overall it looks that there will be some travelling — but this year I plan to make more use of free time to see something else than conference centers.

---

All rights reserved © Marcin Juszkiewicz
Events in 2012 which I will attend was originally posted on Marcin Juszkiewicz website

Read more

You never know where you’re going to end up in 12 months.  This time last year I was writing down resolutions for myself about things I wanted to accomplish at my job over the course of 2011.  I accomplished almost none of them.  In fact, I wouldn’t even be working at the same place a scant 4 months later.

I’m not one to publicly list what was on my resolutions list, but I will tell you what wasn’t on it:

• Get hired by the company that makes the most popular (and my favorite) Linux Desktop
• Work from home, every day, with people all over the globe
• Fly to Budapest, Hungary for a week
• Hang out and work with a couple hundred of the smartest, coolest people I know

And I most certainly didn’t have:

• Transition from a web developer to a very public, community facing role

To say that 2011 has been an exciting year for me would be an understatement in the extreme.  And yet 2012 promises to be even more exciting, as I transition from a heads-down software developer to a far more public and people facing role as the Upstream Liason for Canonical and Ubuntu.  I’ve spent the last month subscribing to upstream mailing lists, IRC channels and blog feeds, so I can keep track of what is going on in the Ubuntu and upstream communities.  I’m really looking forward to having an increased focus on the community side of Ubuntu, the new types of challenges I will face, and the people I will meet and get to know over the course of the next year.

Read more

The Ubuntu Developer Summit – UDS – is a major event in the Canonical calendar. Taking place every six months, it is the Ubuntu event which defines the focus and plans for our up-coming version of Ubuntu. In the first week of November, over 800 people, from Canonical engineers and employees, Ubuntu community members, partners, ISVs, upstreams and many more gathered to discuss and plan for the upcoming Ubuntu 12.04, code-named Precise Pangolin.

UDS covered 420 sessions, under nine tacks, from desktop to design, community to server and cloud. Attendees worked in the usual collaborative and open environment and spent the week pooling their experience and expertise and sharing best practise resulting, as always, in the very best ideas. Right now, those ideas are are represented in hundreds of blueprint documents and are being put into action by developers, community and Canonical, who are already driving forward for April’s launch. As a practical demonstration of that openness you can track our progress here (note, it’s early days!): http://status.ubuntu.com/ubuntu-precise/.

Focus on desktop and the cloud

Over the coming months, we’ll see much more of the fruits of UDS’ labour as new features are developed and collaborations and partnerships formed. Right now, the focus is on refinement, quality and stabilisation. As Ubuntu 12.04 will be a LTS release, which, for the first time, will be supported for five years, getting performance and stability right will be extremely important. For businesses, cloud is becoming ever more important, so we’ll be looking at building out a robust test infrastructure; there will be continued support for the latest releases of OpenStack and much effort will be put into improving Juju and developing the Charms collection.

For our desktop users, refinement of the interface is a continued focus and we’ll regularly run usability testing to make sure Ubuntu looks and feels great. For ubuntu 12.04, there will be a lot of developments for power users, including multi-monitor support, and improvements to boot speed, text-free boot and power consumption. And of course, the community centres around the developer programme, design, governance and loco teams. Engaging and embracing developers continues to be important (for free software) as we seek to bring new and exciting applications to the Ubuntu platform.

Our wonderful sponsors

We also wanted to take this opportunity to extend a special thank you to all of our sponsors who helped us accomplish this monumental task. Cloud Foundry, Rackspace, Google, System 76, Freescale, Nebula, as well as our media partners, Ubuntu User, Linux Pro Magazine, all attended and contributed to the success of UDS in different ways. Some gave plenary sessions;
Brian Thomason and Juan Negron – Cloudfoundry Server deployments using Juju
James Blair and Monty Taylor – Rackspace – Distributed QA in the OpenStack Project

It’s Linaro’s summit too

Also, for the second time, UDS was co-hosted with the Linaro Connect event, where the best software developers met to plan out and code the future of Linux on ARM. Canonical has been actively participating in the Linaro project since it began in 2010, and having both events run in parallel is a good opportunity to share new ideas and collaborate. ARM continues to gain more traction in traditional PC areas, such as the data center and Ubuntu continues to contribute to the enablement of ARM. You can hear more from David Brash’s Linaro plenary, An ARM Technology Update.

And a vision for what’s next

While the focus for Canonical and the Ubuntu community is firmly on the next launch , we’ve already started to think beyond this release. In Mark’s opening keynote, he talked of extending the Ubuntu mission; “‘Linux for Human Beings’ cannot end at the desktop, but needs to take into account the devices that will be used by human beings in the years to come….”. In the coming two years, we’ll start to see Ubuntu powering tablets, phones, TVs and smart screens from the car to the office kitchen, and it will connect those devices cleanly and seamlessly to the desktop, the server and the cloud. You can read more on Mark’s vision for the future of Ubuntu on his blog: or see the full keynote.

For lots more video and insight you can check out the excellent Ubuntu Developers Channel on YouTube

So, roll on Ubuntu 12.04!

Read more

I arrived back home in Augsburg, from last week’s Ubuntu Developer Summit in Orlando, FL. As this is a quality/LTS cycle, we pretty much already knew in advance what to do (bug fixing, bug fixing, some boot speed, and did I mention bug fixing?), but still we had many highly interesting and exciting sessions this time, not so much about what we are going to do, but how we are going to build 12.04.

So far our common practice has been to toss everything new into the development release until Feature Freeze and then try and clean up most of the fallout. Me and many other developers have always cried for having more time for fixing long-standing bugs and not introducing breakage in the first place. It seems that now with 12.04, Ubuntu/Canonical are actually getting serious about it.

(Any resemblance to that postcard from the Kennedy Space Center which I went to last Sunday is of course absolutely unintended and purely coincidental ).

The mission statement is now to have working ISOs, stable ? development, and daily intra-development upgrades every day, quick and regular cleanup of uninstallable packages, component-mismatches, NBS etc., backed by a new “stable +1″ team backed by three people on a rotational shift.

QA team is now setting up daily automatic smoketesting of the installer and other packages which have tests. For the latter we’ll convert some packages to the DEP-8, the proposed format for running autopkgtest on (I’ll do udisks, postgresql-common, pygobject, apport, and jockey soon).

We’ll try do put uploads which might break something (like new libraries) to a staging area first, against which we can run test suites of reverse dependencies before it lands in the new release. As doing this on a large scale still requires infrastructure to be created, we’ll only exercise it for a few packages by uploading to precise-proposed first, but this has a high potential for extension.

We want to commit to fixing major breakage within 3 hours of development time, or otherwise revert the faulty package to the previous version (unless that aggravates problems, such as file conflicts).

Finally, for Canonical upstreams we are introducing “acceptance criteria”, which will hopefully significantly raise the quality and lower the regressions of each Unity etc. release.

So, the mission is clear. In practice we’ll probably have to make some real-life concessions, and Murphy’s law dictates that there still will be some breakage, but we can learn from that as we go.

Let’s build 12.04 LTS!

Read more

It’s late, I’m tired, so this is going to be brief.  But if I didn’t put something up now, chances are I’d procrastinate to the point where it didn’t matter anymore, so something is better than nothing.

JuJu

So the buzz all week was about Juju and Charms.  It’s a very cool technology that I think is really going to highlight the potential of cloud computing.  Until now I always had people comparing the cloud to virtual machines, telling me they already automate deploying VMs, but with Juju you don’t think about machines anymore, virtual of otherwise.  It’s all about services, which is really what you want, a service that is doing something for you.  You don’t need to care where, or on what, or in combination with some other thing, Juju handles all that automatically.  It’s really neat, and I’m looking forward to using it more.

Summit

Summit worked this week.  In fact, this is the first time in my memory where there wasn’t a problem with the code during UDS.  And that’s not because we left it alone either.  IS actually moved the entire site to a new server the day before UDS started.  We landed several fixes during the week to fix minor inconveniences experienced by IS or the admins.  And that’s not even taking into consideration all the last-minute features that were added by our Linaro developers the week prior.  But through it all, Summit kept working.  That, more than anything else, is testament to the work the Summit developers put in over the last cycle to improve the code quality and development processes, and I am very, very proud that.  But we’re not taking a break this cycle.  In fact, we had two separate sessions this week about ways to improve the user experience, and will be joined by some professional designers to help us towards that goal.

Ubuntu One eBook syncing

So what started off as an casual question to Stuart Langridge turned into a full blown session about how to sync ebook data using Ubuntu One.  We brainstormed several options of what we can sync, including reading position, bookmarks, highlights and notes, as well as ways to sync them in an application agnostic manner.  I missed the session on the upcoming Ubuntu One Database (U1DB), but we settled on that being the ideal way of handling this project, and that this project was an ideal test case for the U1DB.  For reasons I still can’t explain, I volunteered to develop this functionality, at some point during the next cycle.  It’s certainly going to be a learning experience.

Friends

Friends!  It sure was good to catch up with all of you.  Both friends from far-away lands, and those closer to home.  Even though we chat on IRC almost constantly, there’s still nothing quite like being face to face.  I greatly enjoyed working in the same room with the Canonical ISD team, which has some of the smartest people I’ve ever had the pleasure of working with.  It was also wonderful to catch up with all my friends from the community.  I don’t know of any other product or project that brings people together the way Ubuntu does, and I’m amazed and overjoyed that I get to be a part of it.

Read more

Just took the plunge, using the excellent bandwidth and local mirror at UDS:

$ lsb_release -irc
Distributor ID: Ubuntu
Release: 12.04
Codename: precise


Nothing blew up in my face, so it seems today is a good day to die^Wupgrade.

Read more