Canonical Voices

Posts tagged with 'uds'

Michael Hall

Last week was our second ever Ubuntu Online Summit, and it couldn’t have gone better. Not only was it a great chance for us in Canonical to talk about what we’re working on and get community members involved in the ongoing work, it was also an opportunity for the community to show us what they have been working on and give us an opportunity to get involved with them.

Community Track leads

This was also the second time we’ve recruited track leads from among the community. Traditionally leading a track was a responsibility given to one of the engineering managers within Canonical, and it was up to them to decide what sessions to put on the UDS schedule. We kept the same basic approach when we went to online vUDS. But starting with UOS 14.06, we asked leaders in the community to help us with that, and they’ve done a phenomenal job. This time we had Nekhelesh RamananthanJosé Antonio ReySvetlana BelkinRohan GargElfy, and Scarlett Clark take up that call, and they were instrumental in getting even more of the community involved

Community Session Hosts

uos_creatorsMore than a third of those who created sessions for this UOS were from the community, not Canonical. For comparison, in the last in-person UDS, less than a quarter of session creators were non-Canonical. The shift online has been disruptive, and we’ve tried many variations to try and find what works, but this metric shows that those efforts are starting to pay off. Community involvement, indeed community direction, is higher in these Online Summits than it was in UDS. This is becoming a true community event: community focused, community organized, and community run.

Community Initiatives

The Ubuntu Online Summit wasn’t just about the projects driven by Canonical, such as the Ubuntu desktop and phone, there were many sessions about projects started and driven by members of the community. Last week we were shown the latest development on Ubuntu MATE and KDE Plasma 5 from non-Canonical lead flavors. We saw a whole set of planning sessions for community developed Core Apps and an exciting new Component Store for app developers to share bits of code with each other. For outreach there were sessions for providing localized ISOs for loco teams and expanding the scope of the community-lead Start Ubuntu project. Finally we had someone from the community kick off a serious discussion about getting Ubuntu running on cars. Cars! All of these exciting sessions were thought up by, proposed by, and run by members of the community.

Community Improvements

This was a great Ubuntu Online Summit, and I was certainly happy with the increased level of community involvement in it, but we still have room to make it better. And we are going to make it better with help from the community. We will be sending out a survey to everyone who registered as attending for this UOS to gather feedback and ideas, please take the time to fill it out when you get the link. If you attended but didn’t register there’s still time, go to the link above, log in and save your attendance record. Finally, it’s never too early to start thinking about the next UOS and what sessions you might want to lead for it, so that you’re prepared when those track leads come knocking at your door.

Read more
Michael Hall

A couple of months ago Jono announced the dates for the Ubuntu Online Summit, June 10th – 12th,  and those dates are almost upon us now.  The schedule is opened, the track leads are on board, all we need now are sessions.  And that’s where you come in.

Ubuntu Online Summit is a change for us, we’re trying to mix the previous online UDS events with our Open Week, Developer Week and User Days events, to try and bring people from every part of our community together to celebrate, educate, and improve Ubuntu. So in addition to the usual planning sessions we had at UDS, we’re also looking for presentations from our various community teams on the work they do, walk-throughs for new users learning how to use Ubuntu, as well as instructional sessions to help new distro developers, app developers, and cloud devops get the most out of it as a platform.

What we need from you are sessions.  It’s open to anybody, on any topic, anyway you want to do it.  The only requirement is that you can start and run a Google+ OnAir Hangout, since those are what provide the live video streaming and recording for the event.  There are two ways you can propose a session: the first is to register a Blueprint in Launchpad, this is good for planning session that will result in work items, the second is to propose a session directly in Summit, which is good for any kind of session.  Instructions for how to do both are available on the UDS Website.

There will be Track Leads available to help you get your session on the schedule, and provide some technical support if you have trouble getting your session’s hangout setup. When you propose your session (or create your Blueprint), try to pick the most appropriate track for it, that will help it get approved and scheduled faster.

Ubuntu Development

Many of the development-oriented tracks from UDS have been rolled into the Ubuntu Development track. So anything that would previously have been in Client, Core/Foundations or Cloud and Server will be in this one track now. The track leads come from all parts of Ubuntu development, so whatever you session’s topic there will be a lead there who will be familiar with it.

Track Leads:

  • Łukasz Zemczak
  • Steve Langasek
  • Leann Ogasawara
  • Antonio Rosales
  • Marc Deslaurs

Application Development

Introduced a few cycles back, the Application Development track will continue to have a focus on improving the Ubuntu SDK, tools and documentation we provide for app developers.  We also want to introduce sessions focused on teaching app development using the SDK, the various platform services available, as well as taking a deeper dive into specifics parts of the Ubuntu UI Toolkit.

Track Leads:

  • Michael Hall
  • David Planella
  • Alan Pope
  • Zsombor Egri
  • Nekhelesh Ramananthan

Cloud DevOps

This is the counterpart of the Application Development track for those with an interest in the cloud.  This track will have a dual focus on planning improvements to the DevOps tools like Juju, as well as bringing DevOps up to speed with how to use them in their own cloud deployments.  Learn how to write charms, create bundles, and manage everything in a variety of public and private clouds.

Track Leads:

  • Jorge Castro
  • Marco Ceppi
  • Patricia Gaughen
  • Jose Antonio Rey

Community

The community track has been a stable of UDS for as long as I can remember, and it’s still here in the Ubuntu Online Summit.  However, just like the other tracks, we’re looking beyond just planning ways to improve the community structure and processes.  This time we also want to have sessions showing users how they can get involved in the Ubuntu community, what teams are available, and what tools they can use in the process.

Track Leads:

  • Daniel Holbach
  • Jose Antonio Rey
  • Laura Czajkowski
  • Svetlana Belkin
  • Pablo Rubianes

Users

This is a new track and one I’m very excited about. We are all users of Ubuntu, and whether we’ve been using it for a month or a decade, there are still things we can all learn about it. The focus of the Users track is to highlight ways to get the most out of Ubuntu, on your laptop, your phone or your server.  From detailed how-to sessions, to tips and tricks, and more, this track can provide something for everybody, regardless of skill level.

Track Leads:

  • Elizabeth Krumbach Joseph
  • Nicholas Skaggs
  • Valorie Zimmerman

So once again, it’s time to get those sessions in.  Visit this page to learn how, then start thinking of what you want to talk about during those three days.  Help the track leads out by finding more people to propose more sessions, and let’s get that schedule filled out. I look forward to seeing you all at our first ever Ubuntu Online Summit.

Read more
David Murphy (schwuk)

Zach Holman writes about how GitHub communicates:

here’s a look at most of the communication that happened at GitHub on one random recent day: February 4, 2014

The expected methods are all there: chat (Campfire in their case), email, and – of course – GitHub itself.

One thing that piqued my interest was their internal-only social network “Team” which seems very reminiscent of how Automattic use WordPress & P2. Since I learned how Automattic use P2, I’ve been wondering if we could do something similar at Canonical. Perhaps we could use Google+  for this as we already use it for internal HangoutsUbuntu Developer Summit, and to power Ubuntu On-Air. There are ways to limit Google+ communities to members of your Google Apps domain.

(Side note: I hate having two Google+ accounts!)

I really need to finish coalescing my thoughts and put them into their own post…

The other point I noted was that their use of email was both minimal and individual – Team and GitHub itself are their primary ways of disseminating information.

It always interesting to see how others do achieve similar goals to yourself.

Read more
David Murphy (schwuk)

Zach Holman writes about how GitHub communicates:

here’s a look at most of the communication that happened at GitHub on one random recent day: February 4, 2014

The expected methods are all there: chat (Campfire in their case), email, and – of course – GitHub itself.

One thing that piqued my interest was their internal-only social network “Team” which seems very reminiscent of how Automattic use WordPress & P2. Since I learned how Automattic use P2, I’ve been wondering if we could do something similar at Canonical. Perhaps we could use Google+  for this as we already use it for internal Hangouts, Ubuntu Developer Summit, and to power Ubuntu On-Air. There are ways to limit Google+ communities to members of your Google Apps domain.

(Side note: I hate having two Google+ accounts!)

I really need to finish coalescing my thoughts and put them into their own post…

The other point I noted was that their use of email was both minimal and individual – Team and GitHub itself are their primary ways of disseminating information.

It always interesting to see how others do achieve similar goals to yourself.

The post How GitHub communicates appeared first on David Murphy.

Read more
Michael Hall

Quick overview post today, because it’s late and I don’t have anything particular to talk about today.

First of all, the next vUDS was announced today, we’re a bit late in starting it off but we wanted to have another one early enough to still be useful to the Trusty release cycle.  Read the linked mailinglist post for details about where to find the schedule and how to propose sessions.

I pushed another update to the API website today that does a better job balancing the 2-column view of namespaces and fixes the sub-nav text to match the WordPress side of things. This was the first deployment in a while to go off without a problem, thanks to  having a new staging environment created last time.  I’m hoping my deployment problems on this are now far behind me.

I took a task during my weekly Core Apps update call to look more into the Terminal app’s problem with enter and backspace keys, so I may be pinging some of you in the coming week about it to get some help.  You have been warned.

Finally, I decided a few weeks ago to spread out my after-hours community a activity beyond Ubuntu, and I’ve settled on the Debian new maintainers Django website as somewhere I can easily start.  I’ve got a git repo where I’m starting writing the first unit tests for that website, and as part of that I’m also working on Debian packaging for the Python model-mommy library which we use extensively in Ubuntu’s Django website. I’m having to learn (or learn more) Debian packaging, Git workflows and Debian’s processes and community, all of which are going to be good for me, and I’m looking forward to the challenge.

Read more
David Planella

Ubuntu French LoCo Team

The challenge

With Ubuntu now running across all form factors and devices and entering the mobile space, a new era begins. While our values remain the same, we’ve now faced with a unique opportunity to drive adoption of our favourite Free Software OS to a user base that could potentially be one or two orders of magnitude bigger.

We’ve layed out the foundations of an innovative and scalable platform that provides a stunning experience for regular and power users, and that is a delight for developers to use. Years of experience, user testing and design on the desktop, pioneering work on the cloud and the app development story for the phone are some of the key aspects that have made it possible.

In this new era our community is more important than ever, with LoCo teams and the LoCo Council at the forefront. Ubuntu contributors, enthusiasts, evangelists, advocates… with your events, initiatives across the globe you are all making it happen.

With virtual UDS happening this week, we’d like to kick off a series of discussions to come up with a solid plan on how to re-energize and empower LoCo teams to scale up to these new challenges, and to involve them in the technologies and projects that are driving this new chapter in Ubuntu. The contribution of leaders in our LoCo community and the LoCo Council will be key to our success here.

The sessions

From the 19th to 21th of November, both the Community and the App Development tracks at UDS will be full with LoCo team sessions, and we’d like all advocates and everyone involved in Ubuntu local community teams to participate and contribute to our LoCo plans this cycle. Here are the sessions this week:

LoCo projects

An initiative to work with LoCos to provide projects and outcomes for those teams and individuals looking for ways of contributing to Ubuntu. We’d like to create “LoCo projects”, a pool of projects LoCo teams can participate in as a team.

LoCo Portal promotion

The LoCo Portal is the window to the vibrant activity of our Ubuntu teams, and we want to come up with a plan to promote it and use it to highlight the awesome work that’s going on in the LoCo world.

Join this session >

LoCo Leadership growth

New challenges require leadership, and we’d like to work with the LoCo Council to grow a team of leaders to drive the global LoCo community.

Join this session >

LoCo community involvement in App Development

App development is an exciting new area that is becoming key to the success of Ubuntu among mobile users. We’re at a point where the platform and infrastructure is ripe for LoCo teams to get involved and start spreading the word and running Ubuntu app development events.

Join this session >

Build materials for the App Dev Schools initiative

Growing the number of learning materials to write apps for Ubuntu will be a key focus for next cycle, and it offers a great opportunity to share knowledge and help others getting started creating content for the platform. Join us to discuss the plan to create a set of materials and presentations for the App Dev Schools.

Join this session >

Campaign to grow the number of tutorials videos

As an extension to the App Dev Schools initiative, we’d like to come up with a plan to publish a series of short, topic-based app development tutorial videos.

Join this session >

Looking forward to seeing you all at UDS this week!

Image ‘Photo de grouple’ by rocknpol under CC BY-NC-SA 2.0

The post Empowering LoCo teams at UDS appeared first on David Planella.

Read more
Daniel Holbach

The next Ubuntu Developer Summit is coming up next week (27-29 August 2013) and you can already see a nice set of topics coming together in Launchpad. The schedule will, as always, be available at summit.ubuntu.com.

Jono Bacon and I are going to be track leads for the Community track, so I wanted to send out an invitation to get topics in, especially for bits concerning the Community track. If you are a team lead and had feedback from your team or you want to bring up a discussion topic where you are interested to help out with, check out our docs on how to submit a session for UDS. Please note: this is not a game of “this is what I think somebody should discuss and do for me”, so if you plan to bring up a session topic, be prepared, have a good idea of what might be on the agenda, reach out to people who might be interested in the topic, so you have a good set of participants and contributors to the project available.

If you just want to attend and listen in and contribute to sessions on the schedule, you can just do that as well, check out uds.ubuntu.com which has all the information on how to tune in. Register here. Can’t wait to see you all next week!

Read more
Michael Hall

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
Nicholas Skaggs

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
brendandonegan

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
Michael Hall

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
Daniel Holbach

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
Nicholas Skaggs


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
Nicholas Skaggs

Readying for UDS

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
Daniel Holbach

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! :-D

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. :-D

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
Daniel Holbach

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
Dustin Kirkland

I stepped away from a busy schedule of awesome sessions the Ubuntu Developer Summit in Oakland, CA to speak for a few minutes about the requirement of "openness" in modern Cloud Computing, the absolute necessity of security and encryption of data, and benefits of Ubuntu as both a Cloud host and guest. Enjoy!








If you're interested in learning more about security considerations when planning your cloud or big data deployment, consider subscribing to Gazzang's blog feed, or reading some of our white papers.

Cheers!
:-Dustin

Read more
Daniel Holbach

… 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:

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:

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
Mark Baker

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.

 

Calxeda CTO and Founder Larry Wikelius with Mark Shuttleworth at UDS

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
Michael Hall

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.

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