Archive for the 'ubuntu' Category

All Star ‘Buntu

Wednesday, February 12th, 2014

As prep for the upcoming 14.04 LTS release of Ubuntu I spent some quality time with each of the main flavours that I track – Kubuntu, Ubuntu GNOME, Xubuntu, and Ubuntu with the default DE, Unity.

They are all in really great shape! Thanks and congratulations to the teams that are racing to deliver Trusty versions of their favourite DE’s. I get the impression that all the major environments are settling down from periods of rapid change and stress, and the timing for an LTS release in 14.04 is perfect. Lucky us :)

The experience reminded me of something people say about Ubuntu all the time – that it’s a place where great people bring diverse but equally important interests together, and a place where people create options for others of which they are proud. You want options? This is the place to get them. You want to collaborate with amazing people? This is the place to find them. I’m very grateful to the people who create those options – for all of them it’s as much a labour of love as a professional concern, and their attention to detail is what makes the whole thing sing.

Of course, my testing was relatively lightweight. I saw tons of major improvements in shared apps like LibreOffice and Firefox and Chromium, and each of the desktop environments feels true to its values, diverse as those are. What I bet those teams would appreciate is all of you taking 14.04 for a spin yourselves. It’s stable enough for any of us who use Linux heavily as an engineering environment, and of course you can use a live boot image off USB if you just want to test drive the future. Cloud images are also available for server testing on all the major clouds.

Having the whole team, and broader community, focus on processes that support faster development at higher quality has really paid off. I’ve upgraded all my systems to Trusty and those I support from afar, too, without any issues. While that’s mere anecdata, the team has far more real data to support a rigorous assessment of 14.04′s quality than any other open platform on the planet, and it’s that rigour that we can all celebrate as the release date approached. There’s still time for tweaks and polish; if you are going to be counting on Trusty, give it a spin and let’s make sure it’s perfect.

Rigor and its results

Friday, December 20th, 2013

Perhaps the biggest change in Ubuntu since 12.04 LTS has been our shift, under Rick’s leadership, towards rigorous, highly automated, test-based QA across all of Ubuntu – server, desktop and mobile.

And what I love about the process is:

  • it’s completely transparent – check out http://ci.ubuntu.com/ and drill down to see the individual test runs
  • it spans every product – server, desktop and mobile, across a wide and growing range of hardware
  • the team takes it absolutely seriously and “stops the line” to fix issues on a regular basis

This is the result of two years hard work by an amazing team – at the package testing and system test level – to help us raise the bar for free software platforms.

This is what the 64-bit x86 server test run looks like today:

Automated testing of the Ubuntu Server platform gives us quick feedback on breaking changes.

Automated testing of the Ubuntu Server platform gives us quick feedback on breaking changes.

 

Over time, thanks to contributions of tests by community, partners and Canonical folks, the number of tests has grown substantially. In the mobile environment we run over 400 smoke tests on every build of every image:

 

Automated test results on a Nexus device.

Automated test results on a Nexus device.

 

In addition to the system image testing you see here, there is a growing portfolio of package-level tests, and processes that test changes both for problems inside the modified package AND for packages that depend on it. So increasingly, we are able to pick up on a problem before it spreads to any developer desktops that are tracking the tip of development.

Testing makes us smarter

It’s significantly more challenging to create test harnesses than code itself. Building this capability exercised our best contributors for the better part of two years; every team has had to figure out how to “get meta” on the parts of Ubuntu they care about. And in the process, we come to a deeper understanding of what it is that users care about, how our platform fits together, and the magic that lives inside the kernel that enables much of this work to happen at scale and in an automated fashion. Grappling with hard problems is like training; the more you do it, the better you understand what’s possible.

Testing helps us go faster

It’s a curious phenomenon that taking time to work on the stuff around the code helps to get the code done faster. But in something as large and complex as a free software platform, change is both your friend and your enemy. Every week thousands of changes flow into Ubuntu from a huge range of sources, and it’s impossible for any on person to anticipate the consequences of every change in advance. Having a rigorous, automated test framework tells us immediately when a change causes a problem somewhere else. Greater confidence that problems will be caught lets us move faster with changes, knowing we can either revert them quickly or stop the line to concentrate everyone’s attention on the issue when it touches a broad swath of the platform.

Testing brings more eyeballs

I run the tip of development – Trusty today – because I can trust the team to spot a problem before it affects me almost every time. That gives me a better view on how Ubuntu is evolving day by day and the ability to ask questions when they are relevant, not right before release. For developers at upstreams or in companies where Trusty is going to be a key platform, the ability to exercise it personally is a huge advantage; you can directly influence the trajectory best if you know where things stand at any given moment. So more rigour translates into more eyeballs which translates into a better result for everybody down the line.

 

We expect to ship our first Ubuntu mobile devices in 2014, and this initiative gives me confidence that we can bring new features and capabilities and improvements to those users fast. And that’s one of the things that makes Ubuntu great.

Mistakes made and addressed

Sunday, November 10th, 2013

Occasionally we make mistakes. When we do it’s appropriate to apologise, address them, and take steps to ensure they don’t happen again.

Last week, someone at Canonical made a mistake in sending the wrong response to a trademark issue out of the range of responses we usually take. That has been addressed, and steps are being taken to reduce the likelihood of a future repeat.

By way of background, there are a number of trademarks around the Ubuntu name and logo which we are required to “enforce” or risk losing them altogether. In normal companies, the rule is that nobody else gets to use your logo. In Canonical, we have a policy that says that there are lots of cases where people DO get to use our name and logo; this is because our policy takes the internet-friendly view that communities need to have rights to a name if they want to feel like they are part of something; we go even further and explicitly allow the use of our name for elements of satire and mirth around Ubuntu. Every country has different rules about trademarks and free speech, we have a global policy that is more generous than most jurisdictions by default.

We do have to “enforce” those trademarks, or we lose them. That means:

  • we have an email address, trademarks@ubuntu.com, where people can request permission to use the name and logo
  • we actively monitor, mostly using standard services, use of the name and logo
  • we aim to ensure that every use of the name and logo is supported by a “license” or grant of permission

As you can imagine, that is a lot of work. A lot of what we find out there is fine, fun, harmless or constructive. Sometimes however it’s pretty nasty: we have had OEMs forging Ubuntu certifications to meet requirements for government tenders, for example.

In order to make the amount of correspondence manageable, we have a range of standard templates for correspondence. They range from the “we see you, what you are doing is fine, here is a license to use the name and logo which you need to have, no need for further correspondence”, through “please make sure you state you are speaking for yourself and not on behalf of the company or the product”, to the “please do not use the logo without permission, which we are not granting unless you actually certify those machines”, and “please do not use Ubuntu in that domain to pretend you are part of the project when you are not”.

Last week, the less-than-a-month-at-Canonical new guy sent out the toughest template letter to the folks behind a “sucks” site. Now, that was not a decision based on policy or guidance; as I said, Canonical’s trademark policy is unusually generous relative to corporate norms in explicitly allowing for this sort of usage. It was a mistake, and there is no question that the various people in the line of responsibility know and agree that it was a mistake. It was no different, however, than a bug in a line of code, which I think most developers would agree happens to the best of us. It just happened to be, in that analogy, a zero-day remote root bug.

The internets went wild, Wired picked a headline accusing Canonical of a campaign to suppress critics, Debian started arguing about whether it should remove all references to the distro-that-shall-not-be-named but then decided to argue about whether it should enforce its own trademarks which lead to an argument about… oh never mind. The point is, people are judging Canonical over this, which is fine and correct in my view, because I am judging Canonical over this too.

Here’s how I’m judging Canonical. Your framework may vary, but I think this is quite a defensible one.

Judge the policy. In this case Canonical has a trademark policy that enables community members to use the marks (good) and allows for satire and sucks sites even in jurisdictions where the local law does not (great!). Failing to have a policy would not be a bonus point in this review :)

Judge the execution of the policy. Canonical does the work needed to maintain the marks; it monitors and responds to requests and notifications around the marks (good). In this case, the wrong action was taken – a new employee was clearly not properly briefed about policy and sensitivities in a key audience for the company (bad).

Judge the response to the incident. Within hours of the publication of a response to our letter, the CEO, COO and legal team reviewed the decision, corrected the action and addressed the matter publicly. I apologised the moment I was made aware of the incident. And I’m reassured that the team in question is taking steps in training and process to minimise the risk of a recurrence.

For those carrying pitchforks and torches on this issue, ask yourself if that would be appropriate to a bug in a line of code in one of many thousands of changes being made monthly by a large team. No? Think about it.

 

On another, more personal note, I made a mistake myself when I used the label “open source tea party” to refer to the vocal non-technical critics of work that Canonical does. That was unnecessary and quite possibly equally offensive to members of the real Tea Party (hi there!) and the people with vocal non-technical criticism of work that Canonical does (hello there!).

For the record, technical critique of open source software is part of what makes open source software so good. It is welcome and appreciated very much at Canonical; getting reviews and feedback and suggestions for improvement from smart people who care is part of why we enjoy writing open source software. There isn’t anything in what I said to suggest that I don’t welcome such technical feedback, but some assumed I was rejecting all feedback including technical commentary. I was not – I was talking about criticism of software which does not centre on the software itself, but rather on some combination of the motivations of the people who wrote it, or the particular free  software license under which it is published, or the policies of the company, or the nationality of the company behind it. Unless critique is focused on improving the software in question it is pretty much a waste of the time of the people who are trying to improve the software in question. That waste of time is what I had in mind with the comment; nevertheless, it was a thoughtless use of an irrelevant label. Please accept my apologies if you have been a vocal non-technical critic of Canonical’s software and felt offended by the label.

Quantal, raring, saucy…

Friday, October 18th, 2013

Before I launch into the tongue-twisting topic of t-series terminology I would like to say a few thank-you’s.

Saucy, now officially known as Ubuntu 13.10, is a wonderful achievement by a very large and diverse collection of teams and individuals. Each of us is motivated by something different – in fact, we might have very different visions of what the ideal desktop looks like or what the default set of applications should be. But we manage, in the spirit of ubuntu, to work together to make something wonderful like 13.10, which serves the needs and goals of a very large number of people and communities.

This release had plenty to put it under pressure. It’s the preview-LTS, in a sense, which means we need to get a lot of the “big rocks” in. That means a willingness to lead change, and doing so in such a complex inter-dependent environment is very challenging. I would like to thank all the teams who have done their part to shape that change into something that worked for them. To the KDE, XFCE and GNOME-focused communities in Ubuntu, thank you for bringing your perspective and I’m delighted that you are all making such great releases now as well.

13.10 is a very special release for me because I think we are leading the GNU/Linux world into a very important arena, which is mobile personal computing. Canonical has its fair share of competitors and detractors who love to undermine the work it does, but I think that wiser heads appreciate the magnitude of the effort required to break this ice, and the extent to which it has taken courage and grace under fire for this team to deliver such a sharp 1.0 of the mobile experience for Ubuntu. It is a reflection of the widespread interest and enthusiasm for that work that we had such diverse participation in the core applications that make up this 1.0 of Ubuntu-for-phones. Multiple teams formed spontaneously to explore new territory: a new mobile design paradigm, new SDK, new visual language. And wow, you guys pulled it off beautifully.  So many contributions from a fresh free software community is testament to the work and style of guys like Michael Hall, who epitomise collaborative development and friendly exchanges of views, motivating guys like me and a hundred others to make sure we deliver something great.

Designers, shell engineers, browser engineers, app engineers, people who built app review and publication mechanisms, security experts… I could not be more proud of what these teams have achieved together.

For the technologists there are some very significant milestones, what Rick Spencer calls “the big rocks”, that made it into 13.10.

Image based updates is really important work. For the first time we can guarantee the integrity of a device running Ubuntu, knowing exactly what version of the OS is installed. I can’t wait to get that on my laptop. Yes, it will be a big change, but I can already see how it’s going to make things easier for me. And I’ll still have the full power of raw Ubuntu inside for all my cloud development needs. Well done to the guys who conceived and delivered the mechanism and the machinery that make it possible. Image 100 is, as they say, the cake.

Mir is really important work. When lots of competitors attack a project on purely political grounds, you have to wonder what THEIR agenda is. At least we know now who belongs to the Open Source Tea Party ;) And to put all the hue and cry into context: Mir is relevant for approximately 1% of all developers, just those who think about shell development. Every app developer will consume Mir through their toolkit. By contrast, those same outraged individuals have NIH’d just about every important piece of the stack they can get their hands on… most notably SystemD, which is hugely invasive and hardly justified. Watch closely to see how competitors to Canonical torture the English language in their efforts to justify how those toolkits should support Windows but not Mir. But we’ll get it done, and it will be amazing.

I can tell you what the agenda of the Mir team is: speed, quality, reliability, efficiency. That’s it. From what I’ve seen on the smartphone, Mir is going to be a huge leap forward for gaming performance, battery life and next-generation display capabilities. So thank you for the many contributions we had to Mir, and to everyone who is testing it in more challenging environments than the smartphone. I’m enjoying it on my laptop and loving the gaming benchmarks for native Mir. So to that team, and the broader community who are helping test and refine Mir, thank you.

App containers and the associated mechanisms for application update are hugely important too. We now have a much better way for app developers to deliver an app to Ubuntu users, giving them much more control of the libraries and dependencies and updates that will affect them. We also make it much easier for developers to deliver newer versions of their app on older versions of the OS. I know that’s a top ask for many of our users, and we’ve done it for the smartphone. It will be available for the desktop as soon as we converge the two. I love seeing those app updates flow onto the phone, and I’m told the developer review and publication process is really sweet. Well done.

So yes, I am very proud to be, as the Register puts it, the Ubuntu Daddy. My affection for this community in its broadest sense – from Mint to our cloud developer audience, and all the teams at Canonical and in each of our derivatives, is very tangible today. It’s had its ups and downs this cycle :) but I feel we’ve pulled together. What the Register misses in that description is that so many of you are in fact the progenitors of Ubuntu’s goodness. Its a privilege to provide the conduit, but the generosity of all of you in making something wonderful to share through that conduit is what’s most touching.

So – saucy is in the can, and it’s time to turn our tactical talk to 14.04, which will of course be an LTS.

As such, our focus is going to be on performance, refinement, maintainability, technical debt. It would be entirely appropriate for us to make conservative choices in this upcoming vUDS, so please join us in those discussions as we shape 14.04 as a platform for long-term deployments on the PC and the cloud and the server. In particular, we will be providing OpenStack I, J and K on 14.04 for LTS deployments, so we need to make sure we meet the needs of that community for a solid core. On the desktop, 13.10 has benefited greatly from the fact that it has a team just focused on improving quality. We’ll do the same again and more for 14.04. On the mobile front, we’re going to keep racing forward, the platform is too new for an LTS and we’re excited to complete the journey of full convergence. We won’t get there in one cycle but given the pace of improvement of the phone and tablet in the last month I think it’s going to be a fantastic cycle there.

vUDS is where those core decisions are made. We’ve broken new ground on public consultation and discussion: anyone can participate by voice or video, discussions are fast and open-minded, results are communicated in the same week. It’s worth taking time out from work, play or sleep to bring your perspective to bear on what 14.04 needs to deliver, and what commitments you want to make to achieve that.

But… what will we call it? As TS Eliot put it, “the naming of cats is a difficult matter, it isn’t just one of your everyday games…”

It’s no trifling matter to tap the well of tempting tautological taxa in search of just the right mascot for something like 14.04. So many bad options! There’s the “tasty tailless tenrec” (wait for the letters from PETA), the “toxic taipan” (hello again my Aussie mates), and the  “tantric tarantula” (hold very still…). The “trigamous tayra” (bendy!) and “trippy tegu” just won’t do. We need something a bit more serious than the “twinkle-toed tamarin”, something a bit more transcendent than the the “toric terrapin”, a bit more thematic than the “thermic tamandua” (though I do like the reference to HEAT, something new in the OpenStack world) and a bit cooler than the “thermobaric thornytail”. There are quite a few good options too… Consider the “timely testudo”, that famous winning tortoise, or the “tenacious tapir” who always gets the job done, those might do. And who could resist the “telegenic tamias” other than, perhaps, the developers who have to type “telegenic” every time they make an upload!

Themes therianthropic seem a touch tub-thumping, and tigers Tasman a touch extinct. That tarsier is tactile but titchy too, the toad a bit witchy the the tree shrew, too-too. For a tip-top release nothing tepid will do.

So our titular totem, our tamper-proof taboo, our tranquil memento of mission and dues, our topical target of both cry and hue, the name for our LTS thoughtful and true: I give you, as Seuss would, with hullabaloo, the temperate and thrifty, the talented and tactful but ultimately, and tellingly, trusty tahr.

The tahr navigates Himalayan heights, shaggily suited, sure-footed and steady. A small tourist tahr population lived on my favourite Table Mountain, and while they’ve made way for indigenous animals, for a long time they symbolised hardiness and fearlessness, perched as they were against the cliffs. We’ll do well together. Let’s get cracking!

Two weeks with Mir

Tuesday, July 9th, 2013

Mir has been running smoothly on my laptop for two weeks now. It’s an all-Intel Dell XPS, so the driver stack on Ubuntu is very clean, but I’m nonetheless surprised that the system feels *smoother* than it did pre-Mir. It might be coincidence, Saucy is changing pretty fast and new versions of X and Compiz have both landed while I’ve had Mir running. But watching top suggests that both Xorg and Compiz are using less memory and fewer CPU cycles under Mir than they were with X handling the hardware directly.

Talking with the Mir team, they say others have seen the same thing, and they attribute it to more efficient buffering of requests on the way to the hardware. YMMV but it’s definitely worth trying. I have one glitch which catches me out – Chromium triggers an issue in the graphics stack which freezes the display. Pressing Alt-F1 unfreezes it (it causes Compiz to invoke something which twiddles the right bits to bring the GPU back from it’s daze). I’m told that will get sorted trivially in a coming update to the PPA.

The overall impression I have is that Mir has delivered what we hoped. Perhaps it had the advantage of being able to study what went before – SurfaceFlinger, Wayland, X – and perhaps also the advantage of looking at things through the perspective of a mobile lens, where performance and efficiency are a primary concern, but regardless, it’s lean, efficient, high quality and brings benefits even when running a legacy X stack.

We take a lot of flack for every decision we make in Ubuntu, because so many people are affected. But I remind the team – failure to act when action is needed is as much a failure as taking the wrong kind of action might be. We have a responsibility to our users to explore difficult territory. Many difficult choices in the past are the bedrock of our usefulness to a very wide audience today.

Building a graphics stack is not a decision made lightly – it’s not an afternoon’s hacking. The decision was taken based on a careful consideration of technical factors. We need a graphics stack that works reliably across a very wide range of hardware, that performs predictably, that provides a consistent quality of user experience on many different desktop environments.

Of course, there is competition out there, which we think is healthy. I believe Mir will be able to evolve faster than the competition, in part because of the key differences and choices made now. For example, rather than a rigid protocol that can only be extended, Mir provides an API. The implementation of that API can evolve over time for better performance, while it’s difficult to do the same if you are speaking a fixed protocol. We saw with X how awkward life becomes when you have a fixed legacy protocol and negotiate over extensions which themselves might be versioned. Others have articulated the technical rationale for the Mir approach better than I can, read what they have to say if you’re interested in the ways in which Mir is different, the lessons learned from other stacks, and the benefits we see from the architecture of Mir.

Providing Mir as an option is easy. Mir is a very focused part of the stack, it has far fewer tentacles and knock-on consequences for app developers than, say, the init system, which means we should be able to work with a very tight group of communities to get great performance. It’s much easier for a distro to engage with Mir than to move to SystemD, for example; instead of an impact on every package, there is a need to coordinate in just a few packages for great results. We’ve had a very positive experience working with the Qt and WebKit communities, for example, so we know those apps will absolutely fly and talk Mir natively. Good upstreams want their code widely useful, so I’ve no doubt that the relevant toolkits will take patches that provide enhanced capabilities on Mir when available. And we also know that we can deliver a high-performance X stack on Mir, which means any application that talks X, or any desktop environment that talks X, will perform just as well with Mir, and have smoother transitions in and out thanks to the system compositor capabilities that Mir provides.

On Ubuntu, we’re committed that every desktop environment perform well with Mir, either under X or directly. We didn’t press the ‘GO’ button on Mir until we were satisfied that the whole Ubuntu community, and other distributions, could easily benefit from the advantages of a leaner, cleaner graphics stack. We’re busy optimising performance for X now so that every app and every desktop environment will work really well in 13.10 under Mir, without having to make any changes. And we’re taking patches from people who want Mir to support capabilities they need for native, super-fast Mir access. Distributions should be able to provide Mir as an option for their users to experiment with very easily – the patch to X is very small (less than 500 lines). For now, if you want to try it, the easiest way to do so is via the Ubuntu PPA. It will land in 13.10 just as soon as our QA and release teams are happy that its ready for very widespread testing.

Here comes the Carrier Advisory Group

Tuesday, June 18th, 2013

Last week we held the first meeting of the new Ubuntu Carrier Advisory Group, which helps us figure out how best to shape Ubuntu to meet the needs of the mobile industry.

It was very exciting!

We mapped out our approach to the key question I’ve been asked by every carrier we’ve met so far: how can we accommodate differentiation, without fragmenting the platform for developers? We described the range of diversity we think we can support initially, received some initial feedback from carriers participating immediately, and I’m looking forward to the distilled feedback we’ll get on the topic in the next call.

CAG members get a period of exclusivity in their markets. We’ll close the CAG to new members shortly.  We don’t need a very large group; just a few clear-thinking and thoughtful partners who have experience introducing new platforms. And with this initial group of members, we are all set to get really good insight for a really great launch next year.

Next week I’ll be in Shanghai for the GSMA’s Mobile Asia Expo, and looking forward to a round of in-person meetings with our advisory group. Mostly we’ll be meeting by telephone and video conference, given the very global nature of the CAG, but there are a few events which attract critical mass of attendees in the industry where we’ll arrange a CAG face-to-face as well.

Thanks to everyone who is participating in the project – Ubuntu’s touch experience is really coming along in leaps and bounds. I love hearing about the new devices to which it’s been ported, or new apps getting started. This is the frontier for personal computing, and we want free software leading the way. You all make that possible.

Congratulations and thanks to the entire extended Ubuntu community for today’s release of Ubuntu 13.04, the Raring Ringtail. Feedback over the past few months on raring has been fantastic – pretty much universal recognition of the performance and quality initiatives Rick’s team have led and which have been embraced across the platform and the community.

In the work to underpin a rolling release, we made huge strides in automated quality assessment and performance testing. From here on out, I’m going to treat the cutting edge of Ubuntu as a rolling release, because the team have done such an amazing job of making daily quality a reality. That’s a value that we have all adopted, and the project is much better off for it.

Slipping the phrase ‘ring ring’ into the codename of 13.04 was, frankly, a triumph of linguistic engineering. And I thought I might quit on a high… For a while, there was the distinct possibility that Rick’s Rolling Release Rodeo would absolve me of the  twice-annual rite of composition that goes into the naming of a new release. That, together with the extent of my travels these past few months, have left me a little short in the research department. I usually spend a few weekend afternoons doodling with a dictionary (it’s actually quite a blast, and I recently had the pleasure of actually knowing what some ponce was talking about when they described something as ‘rugose’).

So today I find myself somewhat short in the naming department, which is to say, I have a name, but not the soliloquy that usually goes with it!

Which is why, upon not very deep reflection, I would like to introduce you to our mascot for the next six months, the saucy salamander.

The salamander is one of nature’s most magical creatures; they are a strong indicator of a pristine environment, which is a fitting way to describe the new world emerging around Ubuntu Touch – new applications, a new SDK, a gorgeous clean interface. You’ll find salamanders swimming in clear, clean upstreams – which is exactly what’s forming around Ubuntu’s mobile ecosystem. It’s a way of saying ‘thank you’ to the tremendous community that has joined the effort to create a single unified experience from phone to PC, with tons of crisp and stylish core apps made by people from all over the world who want to build something fast, fresh and free. And we’re saucy too – life’s too short to be stodgy or stilted. Our work is our play – we make amazing things for a huge audience, we find space for pretty much every flavour of interface and do it with style.

Happy release day everyone! Here’s to a super saucy cycle.

It’s been two weeks since Rick Spencer made the case for a rolling release approach in Ubuntu. Having a rolling release is one of the very top suggestions from the hardcore Ubuntu user community, and after years of it being mooted by all and sundry I thought it deserved the deep consideration that Rick and his team, who represent most of Canonical’s direct contributions to Ubuntu, brought to the analysis.

It’s obviously not helpful to have mass hysteria break out when ideas like this get floated, so I would like to thank everyone who calmly provided feedback on the proposal, and blow a fat raspberry at those of you who felt obliged to mount soapboxes and opine on The End Of the World As We Know It. Sensible people the world over will appreciate the dilemma at being asked to take user feedback seriously, and being accused of unilateralism when exploring options.

Change is warranted. If we want to deliver on our mission, we have to be willing to stare controversy in the face and do the right thing anyway, recognising that we won’t know if it’s the right thing until much later, and for most of the intervening time, friends and enemies alike will go various degrees of apoplectic. Our best defense against getting it wrong is to have a strong meritocracy, which I think we do. That means letting people like Rick, who have earned their leadership roles, explore controversial territory.

So, where do we stand? And where do I stand? What’s the next step?

What makes this conversation hard is the sheer scale of the Ubuntu ecosystem, all of which is profoundly affected by any change. Here are the things I think we need to optimise for, and the observations that I think we should structure our thinking around:

Releases are good discipline, cadence is valuable.

Releases, even interim releases, create value for parts of the Ubuntu ecosystem that are important. They allow us to get more widespread feedback on decisions made in that cycle – what’s working, what’s not working. Interestingly, in the analysis that played into Rick’s proposal, we found that very few institutional users depend on extended support of the interim releases. Those who care about support tend to use the LTS releases and LTS point releases.

Release management detracts from development time, and should be balanced against the amount of use that release gets.

While reaffirming our interest in releases, I think we established that the amount of time spend developing in a cycle versus spent doing release management is currently out of whack with the amount to which people actually DEPEND on that release management, for interim releases, on the desktop. On the server, we found that the interim releases are quite heavily used in the cloud, less so on physical metal.

Daily quality has raised the game dramatically for tip / trunk / devel users, and addresses the Rolling Release need.

There’s widespread support for the statement that ‘developers can and should use the daily development release’. The processes that have been put in place make it much more reliable for folks who want to track development, either as a contributor to Ubuntu or as someone who ships software for Ubuntu and wants to know what’s happening on the latest release, to use Ubuntu throughout the development cycle. For those of you not aware, uploads to the edge get published in a special ‘pocket’, and only moved into the edge if they don’t generate any alarms from people who are on the VERY BLEEDING EDGE. So you can use Raring (without that bleeding edge pocket) and get daily updates that are almost certain not to bork you.  There is a real community that WANTS a rolling release, and the daily development release of Ubuntu satisfies this need already.

LTS point releases are a great new enhancement to the LTS concept.

On a regular basis, the LTS release gets a point update which includes access to a new, current kernel (supporting new hardware without regressing the old hardware on the previous kernel, which remains supported), new OpenStack (via the Cloud Archive), and various other elements. I think we could build on this to enhance the LTS with newer and better versions of the core UX (Unity) as long as we don’t push those users through a major transition in the process (Unity/Qt, anybody? ;-)).

Separating platform from apps would enhance agility.

Currently, we make one giant release of the platform and ALL APPS. That means an enormous amount of interdependence, and an enormous bottleneck that depends largely on a single community to line everything up at once. If we narrowed the scope of the platform, we would raise the quality of the platform. Quite possibly, we could place the responsibility for apps on the developers that love them, giving users access to newer versions of those apps if (and only if) the development communities behind them want to do that and believe it is supportable.

Phew.

That’s what I observed from all the discussion that ensued from Rick’s proposal.

Here’s a new straw man proposal. Note – this is still just a proposal. I will ask the TB to respond to this one, since it incorporates both elements of Rick’s team’s analysis and feedback from wider circles.

Updated Ubuntu Release Management proposal

In order to go even faster as the leading free software platform, meet the needs of both our external users and internal communities (Unity, Canonical, Kubuntu, Xubuntu and many many others) and prepare for a wider role in personal computing, Ubuntu is considering:

1. Strengthening the LTS point releases.

Our end-user community will be better served by higher-quality LTS releases that get additional, contained update during the first two years of their existence (i.e. as long as they are the latest LTS). Updates to the LTS in each point release might include:

  • addition of newer kernels as options (not invalidating prior kernels). The original LTS kernel would be supported for the full duration of the LTS, interim kernels would be supported until the subsequent LTS, and the next LTS kernel would be supported on the prior LTS for teh length of that LTS too. The kernel team should provide a more detailed updated straw man proposal to the TB along these lines.
  • optional newer versions of major, fast-moving and important platform components. For example, during the life of 12.04 LTS we are providing as optional updates newer versions of OpenStack, so it is always possible to deploy 12.04 LTS with the latest OpenStack in a supported configuration, and upgrade to newer versions of OpenStack in existing clouds without upgrading from 12.04 LTS itself.
  • required upgrades to newer versions of platform components, as long as those do not break key APIs. For example, we know that the 13.04 Unity is much faster than the 12.04 Unity, and it might be possible and valuable to backport it as an update.

2. Reducing the amount of release management, and duration of support, for interim releases.

Very few end users depend on 18 months support for interim releases. The proposal is to reduce the support for interim releases to 7 months, thereby providing constant support for those who stay on the latest interim release, or any supported LTS releases. Our working assumption is that the latest interim release is used by folks who will be involved, even if tangentially, in the making of Ubuntu, and LTS releases will be used by those who purely consume it.

3. Designating the tip of development as a Rolling Release.

Building on current Daily Quality practices, to make the tip of the development release generally useful as a ‘daily driver’ for developers who want to track Ubuntu progress without taking significant risk with their primary laptop. We would ask the TB to evaluate whether it’s worth changing our archive naming and management conventions so that one release, say ‘raring’, stays the tip release so that there is no need to ‘upgrade’ when releases are actually published. We would encourage PPA developers to target the edge release, so that we don’t fragment the ‘extras’ collection across interim releases.

 

That is all.

All the faces of Ubuntu

Thursday, March 7th, 2013

Harald,

Of course what Kubuntu and Xubuntu and Ubuntu GNOME Remix et al do matters. If it didn’t, we wouldn’t invest a ton of time and energy in finding ways to share the archives effectively. And I consider it one of the lovely things about Ubuntu that there is room for all of us here. As long as there are people willing to make it happen, there’s room for a new face.

You all make the broad Ubuntu family more diverse and more interesting. For which I’m grateful.

In return, you get the benefit of an enormous and concentrated investment in making a core platform that can be widely consumed (on top of the already enormous efforts of the open source community, Debian, and any number of other groups). That investment brings with it a pace of change, and a willingness to be focused on specific outcomes. Mir, which is a fantastic piece of engineering by a very talented team that has looked hard at the problem and is motivated to do something that will work well, is just one example. Every week, we’re figuring out how to coordinate changes. Why blow a gasket over this one? I’ve absolutely no doubt that Kwin will work just fine on top of Mir. And I’m pretty confident Mir will be on a lot more devices than Wayland. Which would be good for KDE and Kubuntu and Plasma Active.

So, before you storm off, have a cup of tea and think about the gives and gets of our relationship. Seriously.

Mark

Ubuntu in 2013

Wednesday, December 26th, 2012

This is a time of year to ponder what matters most and choose what we’ll focus on in the year to come. Each of us has our own priorities and perspective, so your goals may be very different to mine. Nevertheless, for everyone in the Ubuntu project, here’s what I’ll be working towards in the coming year, and why.

First, what matters most?

It matters that we not exclude people from our audience. From the artist making scenes for the next blockbuster, to the person who needs a safe way to surf the web once a day, it’s important to me, and to the wider Ubuntu community, the people be able to derive some benefit from our efforts. Some of that benefit might be oblique – when someone prefers XFCE to Unity, they are still benefiting from enormous efforts by hundreds of people to make the core Ubuntu platform, as well as the Xubuntu team’s unique flourish. Even in the rare case where the gift is received ungraciously, the joy is in the giving, and it matters that our efforts paid dividends for others.

In this sense, it matters most that we bring the benefits of free software to an audience which would not previously have had the confidence to be different. If you’ve been arguing over software licenses for the best part of 15 years then you would probably be fine with whatever came before Ubuntu. And perhaps the thing you really need is the ability to share your insights and experience with all the people in your life who wouldn’t previously have been able to relate to the things you care about. So we have that interest in common.

It matters that we make a platform which can be USED by anybody. That’s why we’ve invested so much into research and thinking about how people use their software, what kinds of tools they need handy access to, and what the future looks like. We know that there are plenty of smart people who’s needs are well served by what existed in the past. We continue to maintain older versions of Ubuntu so that they can enjoy those tools on a stable platform. But we want to shape the future, which means exploring territory that is unfamiliar, uncertain and easy to criticise. And in this regard, we know, scientifically, that Ubuntu with Unity is better than anything else out there. That’s not to diminish the works of others, or the opinions of those that prefer something else, it’s to celebrate that the world of free software now has a face that will be friendly to anybody you care to recommend it.

It also matters that we be relevant for the kinds of computing that people want to do every day.

That’s why Unity in 2013 will be all about mobile – bringing Ubuntu to phones and tablets. Shaping Unity to provide the things we’ve learned are most important across all form factors, beautifully. Broadening the Ubuntu community to include mobile developers who need new tools and frameworks to create mobile software. Defining new form factors that enable new kinds of work and play altogether. Bringing clearly into focus the driving forces that have shaped our new desktop into one facet of a bigger gem.

It’s also why we’ll push deeper into the cloud, making it even easier, faster and cost effective to scale out modern infrastructure on the cloud of your choice, or create clouds for your own consumption and commerce. Whether you’re building out a big data cluster or a super-scaled storage solution, you’ll get it done faster on Ubuntu than any other platform, thanks to the amazing work of our cloud community. Whatever your UI of choice, having the same core tools and libraries from your phone to your desktop to your server and your cloud instances makes life infinitely easier. Consider it a gift from all of us at Ubuntu.

There will always be things that we differ on between ourselves, and those who want to define themselves by their differences to us on particular points. We can’t help them every time, or convince them of our integrity when it doesn’t suit their world view. What we can do is step back and look at that backdrop: the biggest community in free software, totally global, diverse in their needs and interests, but united in a desire to make it possible for anybody to get a high quality computing experience that is first class in every sense. Wow. Thank you. That’s why I’ll devote most of my time and energy to bringing that vision to fruition. Here’s to a great 2013.