Canonical Voices

Posts tagged with 'uds'

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.

The post How GitHub communicates appeared first on David Murphy.

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

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

My year in review

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
Gerry Carr

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