Tag Archives: Rick Spencer

Linux

Rick Spencer: User Interaction with Ubuntu Components

Leave a comment

I am so very able to amuse myself with all these funny pictures, but there are other amusing subreddits other than funny. So today I added the ability to choose a different subreddit. This involved diving into the world of Ubuntu Components.

Ubuntu Components were surprisingly functional, but as you will see, they are still a work in progress.

So, the first thing I needed to do was to make a way for the user to say that they want to change subreddits. Ubuntu Touch provides the bottom edge for your application to add a list of commands. This is a nice way to do it because it means that the screen isn’t cluttered with commands, but users know exactly where to go when they want them.

The first thing to do is to ensure that the top level of your app is a MainView, and then you are presenting the content in a Page. So, roughly your apps structure looks like …

//imports
MainView
{
    //set MainView properties
    Page
    {
        //app UI content
    }
    //components outside pages
}

I wanted to add a “subreddit” button. To do that, I set the tools property of the page to a list of actions. So far there is only one action. Essentially, I am defining a button. I tell it the text I want, the icon to use (I downloaded an icon that I wanted) and the action to take. So this goes inside the Page tag:

        tools: ToolbarActions
        {
        Action
        {
            text: “SubReddit”
            iconSource: Qt.resolvedUrl(“reddit.png”)
            onTriggered: PopupUtils.open(subRedditSheet)
        }
    }
Now you can see that if swipe from the button, I get my button.

But what is that action? What I did was create a ComposerSheet that allows the user to input the reddit that they want. You do this by defining a Component that wraps a ComposerSheet. A ComponentSheet is kind of like a dialog box. It handles putting Ok and Cancel buttons on for you. Note that you have to name the ComposerSheet “sheet”, or you get errors. All I added was a TextField that I called “subRedditText, but you can fill the ComposerSheet with whatever you want.

I just have to tell it what to do when the user clicks Ok. I did a little refactoring from yesterday to create a “changeSubReddit function that gets called on start up, and can get called from here. I just pass it the subreddit. (Don’t forget to import Ubuntu.Components.Popups 0.1 in order to use the ComposerSheet).

Then you call PopupUtils.open to pop it …read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Rick Spencer: How I Learned to Love QML and Inheritance Therein

Leave a comment
Gotta love the “developer art” … those placeholder images should be replaced by sweet Zombie artwork as the game nears completion.

For a long time I resisted the QML wave. I had good reasons for doing so at the time. Essentially, compared to Python, there was not much desktop functionality that you could access without writing C++ code to wrap existing libraries and expose them to QML. I liked the idea of writing apps in javascript, but I really did not relish going back to writing C++ code. It seemed like a significant regression. C++ brings a weird set of bugs around memory management and rogue pointers. While manageable  this type of coding is just not fun and easy.

However, things change, and so did QML. Now, I am convinced and am diving into QML.

  • The base QML libraries have pretty much everything I need to write the kinds of apps that I want to write.
  • The QtCreator IDE is “just right”. It has an editor with syntax highlighting and an integrated debugger (90% of what people are looking for when they ask for an IDE) and it has an integrated build/run system.
  • There are some nice re-factoring features thrown in, that make it easier to be pragmatic about good design as you are coding. I also like the automatic formatting features.
  • The QML Documentation is not quite complete, but it is systematic. I am looking forward to more samples, though, that’s for sure.

In my first few experiences with QML, I was a tiny bit thrown by the “declarative” nature of QML. However, after a while, I found that my normal Object Oriented thought processes transferred quite well. The rest of this post is about how I think about coding up classes and objects in QML.

In Python, C++, and most other languages that support OO, classes inherit from other classes. JavaScript is a bit different, objects inherit from objects. While QML is really more like javascript in this way, it’s easy for me to think about creating classes instead.

I will use some code from a game that I am writing as an easy example. I have written games in Python using pygame, and it turned out that a lot of the structure of those programs worked well in QML. For example, having a base class to manage essential sprite behavior, then a sub class for the “guy” that the player controls, and various subclasses for enemies and powerups.

For me, what I call a QML “baseclass” (which is just a component, like everything else in QML) has the following parts:

  1. A section of Imports – This is a typical list of libraries that you want to use in yor code. 
  2. A definition of it’s “isa”/superclass/containing component – Every class is really a component, and a compnent is defined by declaring it, and nesting all of it’s data and behaviors in curly brackets.
  3. Paramaterizable properties – QML …read more
    Source: FULL ARTICLE at Planet Ubuntu
Linux

Mark Shuttleworth: Let’s go faster while preserving what works best

Leave a comment
;-)

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’. …read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Stephen Michael Kellat: Ever Onward

Leave a comment

To every thing there is a season, and a time to every purpose under the heaven: A time to be born, and a time to die; a time to plant, and a time to pluck up that which is planted; A time to kill, and a time to heal; a time to break down, and a time to build up; A time to weep, and a time to laugh; a time to mourn, and a time to dance; A time to cast away stones, and a time to gather stones together; a time to embrace, and a time to refrain from embracing; A time to get, and a time to lose; a time to keep, and a time to cast away; A time to rend, and a time to sew; a time to keep silence, and a time to speak; A time to love, and a time to hate; a time of war, and a time of peace. — Ecclesiastes 3:1-8 (King James Version)

Well, UDS-1303 is now over. It appears that some folks in the community have been overtaken by the number of changes that have been proposed recently. That much is understandable. During sessions I participated in during UDS-1303, I kinda was a broken record talking about the need for change management.

For many this has been a time to speak. Indeed, there was much discussion during the summit. There were also many announcements of community members departing.

It is unfortunate that community members are departing. I hope they find success in their new endeavors. With the state of the technology world as of late, departures need not necessarily be permanent as paths may well cross again in the future. With new synergies erupting in the most unexpected of places it is inevitable that we may perhaps meet again.

The bumper sticker sized key to UDS-1303 is that discussion happened in a format very different from an e-mail list. For the proposals that were initially made by e-mail, this pretty much had to happen as slinging decontextualized text back and forth in that communications paradigm can be limiting. After concerns, proposals, counter-proposals, technical nightmares, fears, anticipations, hopes, and potential excitements more were expressed I look forward to seeing a more fleshed out proposal for rolling releases.

The problem is that at the broadest level it is easy to talk about rolling releases. When you get down to the nuts and bolts of it is when it gets pretty complicated and can at times resemble a Gordian Knot. As evidenced at UDS-1303, there are many possible methodologies and risk is unavoidable.

As initially proposed, I did not favor the proposal due to uncertainties and a lack of nuts & bolts details. After the discussions that have ensued, I’m ready to wait for the full proposal to be released by Rick Spencer that is fleshed out so that I can consider this further. I heard many interesting potential approaches to the nuts & bolts of doing this during UDS-1303 and eagerly await what is settled on …read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Joel Pickett: UDS-1303, Day One

Leave a comment

Now UDS-1303 Tuesday is through, I’d like to recap on a couple of the sessions I watched on Google+ Hangouts.

Rolling Release discussion (+1 maintenance beyond April)

Interesting discussion which included some of the System76 folks that basically said that the Ubuntu release schedule works fine for their clients. They ship the latest LTS, 12.04, and the current stable release, 12.10. They pointed out that each release of Ubuntu has been a clear improvement over the previous release (phew!), and were looking forward to the upcoming Raring Ringtail. Very compelling to hear straight from the OEM vendors – they have been shipping Ubuntu for the past fifteen (yes, that’s 15!) releases.

Rick Spencer outlined the idea to keep LTS releases and focus on daily quality with monthly pulses. I think this is an interesting concept in relation where Ubuntu is as a platform. If this idea had been discussed around the days that I started as an Ubuntu user (Intrepid Ibex era), the daily quality was just not there. It was more of a sentiment to encourage users not to use the development build until the later alpha snapshots, or even beta releases.

These days I’ve been using the Quantal and Raring dailies with minimal disruption, essentially my desktop and laptops feel like a normal (release) install. It’s just that updates are much more frequent and I’m using the latest available version of the software.

Loco discussion (LoCo community – what’s next?)

Another interesting discussion was the concept of approved and unapproved LoCo teams. I’m a member of the Australian LoCo, which is currently approved. As Jono stated in the session, I think there’s less of a need for approved LoCo teams now. The main benefit of being an approved LoCo is that, historically, LoCos would be sent CD’s/DVD’s, stickers and other Ubuntu merchandise around releases and conferences. This isn’t particularly sustainable to send a pack to all approved LoCos each release, and arguably more people are using other media like USBs to install Ubuntu.

The other concern was the labelling and divide of LoCo teams. It should be noted that being an unapproved team doesn’t make you any less important than an approved LoCo. At the end of the day, LoCos will be recognised for the work that they do, supported by Planet Ubuntu blog posts, pictures of events (release parties, conference talks, Ubuntu Hours, Ubuntu Global Jam sessions) and team reports.

Thoughts on the first online UDS

On the whole, I think it went quite fine. I think if the LTS release structure is continued, I think a physical week-long UDS would be appropriate at least once through the LTS cycle. It’s also a positive bonus that everything is logged and the sessions are available once the session ends for people that have missed the session. These short UDS place a focus on detailed discussion, though if anything is missed, we’ll be able to revisit it again at the next UDS in a few months or on ubuntu-devel.

It would have been nice for Mark Shuttleworth to comment …read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Jorge Castro: Juju core 1.9.8 released

Leave a comment

David Cheney passes along that Juju core 1.9.8 has now been released.

For those not familiar with Juju core, it is the rewrite branch of Juju in golang. The team is now close to feature parity with the Python version, we expect to have something real nice for you by 13.04. 🙂

My favorite feature here is a real small one, an idea passed along to the team by Rick Spencer. juju generate-config -w will now spit out a configuration file for you. We’ve documented a bunch of providers in there, so out of the box you’ll get AWS, OpenStack, HP Cloud, and the local provider in the config file all commented out, you’ll be able to just paste in your creds and go. This is much nicer than trading snippets with friends.

Here’s the changelog, make sure you check it out, there are still some limitations, like lack of constraints, so be aware. Expect a summarized report on the Go version soon, we’ve inherited some great new features, including better multiplatform support, you’ll find 1.9.8 is working for OSX now.

…read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Didier Roche: Unity: release early, release often… release daily! (part 1)

Leave a comment

For almost the past 2 weeks (and some months for other part of the stacks), we have automated daily release of most of the Unity components directly delivered to Ubuntu raring. And you can see those different kinds of automated uploads published to the ubuntu archive.

I’m really thrilled about this achievement that we discussed and setup as a goal for the next release at past UDS.

Why?

The whole Unity stack has grown tremendously in the past 3 years. At the time, we were able to release all components, plus packaging/uploading to ubuntu in less than an hour! Keeping the one week release cadence by then was quite easy, even though a lot of work. The benefit was that it enabled us to ensure that we have a fluid process to push what we developped upstream to our users.

As of today, teams have grown by quite some extends, and if we count everything that we develop for Unity nowadays, we have more than 60 components. This covers from indicators to the theme engine, from the open input framework to all our tests infrastructure like autopilot, from webapps to web credentials, from lenses to libunity, and finally from compiz to Unity itself without forgetting nux, bamf… and the family is still growing rapidly with a bunch of new scopes coming down the pipe through the 100 scopes project, our own SDK for the Ubuntu phone, the example applications for this platform we are about to upload to Ubuntu as well… Well, you got it, the story is far from ending!

So, it’s clear that those numbers of components that we develop and support will only go higher and higher. The integration team already scaled by large extends their work hours and rush to get everything delivered timely to our user base[1]. However, it’s with no question that we won’t be able to do that forever. We don’t want as well introducing artificial delays to our own upstream on when we are delivering stuff to our users. We needed to solve that issue while not paying any price on quality, nor balancing the experience we deliver to our users. We want to keep high standards, and even, why not allying this need while providing an even a better, more reliable, and better evaluation before releasing of what we eventually upload to Ubuntu from our upstreams. Getting our cake and eat it too! :)

Trying to change for the better

What was done in the last couple of cycles was to separate between 2 groups the delivery of those packages to the users. There was an upstream integration team, which will hand over to the Ubuntu platform team theorically ready-to-upload packages, making the reviews, helping them, fixing some issues and finally sponsoring their work to Ubuntu. However, this didn’t really work for various reasons and we quickly realized that this ended up just complexifying the process instead of easing it out. You can see a diagram of where we ended up when looking back at the situation:

end of 12.04 and 12.10 release process

Seems easy isn’t it? ;) Due to those inner loops and gotchas, in addition to the whole new set of components, we went from a weekly release cadence to doing 4 to 5 solid releases during a whole cycle.

Discussing about it with Rick Spencer, he gave me a blank card on thinking how we can make this more fluid to our users and developers. Indeed, with all the work piling up, it wasn’t possible to release immediatly the good work that upstream did in the past days, which can lead to some frustration as well. I clearly remember that Rick used the term “think about platform[2] as a service”. This kind of immediatly echoed in me, and I thought, “why not trying that… why not releasing all our code everyday and delivering a service enabling us to do that?”

Daily release, really simplified diagram

Even if not planned from the beginning (sorry, no dark, hidden, evil plan here), thinking about it, this makes sense as part of some kind a logical progression from where we started since Unity exists:

  • Releasing every week, trying manually to get the release in a reasonable shape before uploading to Ubuntu
  • Raise the quality bar, put some processes for merge reviewing.
  • Adding Acceptance Criterias thanks to Jason Warner, ensuring that we are getting some more and more good tests and formal conditions on doing a release
  • Automate those merges through a bot, ensuring that every commits in trunk builds fine, that unit tests are passing
  • Raise again the quality bar, adding more and more integration tests

Being able and ensuring we are able to release daily seems really, looking at it, par of the next logical step! But it wouldn’t have been possible without all those past achievements.

Advantages of daily releases

It’s quite immediate to see a bunch of positive aspects of doing daily releases:

  • We can spot way faster regressions. If a new issue arose, it’s easier to bisect through packages and find the day when the new regression or incorrect behavior started to happen, then, looking at the few commits to trunk (3-5?) that was done this day and pinpoint what introduced it.
  • This enables us to deliver everything in a rapid, reliable, predictable and fluid process. We won’t have crazy rushes as we had in the past cycles around goal dates like feature freezes to get everything in the hand of the user by then. This will be delivered automatically the day after to everyone.
  • I see also this as a strong motivation for the whole community who contributes to those projects. Not having to wait a random date hidden in a wiki for a “planned release date” to see the hard work you put into your code to be propagated to the user’s machines. You can immediately see the effect of your hacking on the broader community. If it’s reviewed and approved for merging (and tests passes, I’ll come back to that later), it will be in Ubuntu tomorrow, less than 24 hours after your work reached trunk! How awesome is that?
  • This also means that developers will only need to build the components they are working on. No need for instance to rebuild compiz or nux to do an Unity patch because the API changed and you need “latest everything” to build. Lowering the entry for contributing and chances that you have unwanted files in /usr/local staying around conflicting with the system install.

Challenges of daily release

Sure, this comes with various risks that we had to take into account when designing this new process:

  • The main one is “yeah, it’s automated, how can you be sure you don’t break Ubuntu pushing blindly upstream code to it?”. It’s a reasonable objection and we didn’t ignore it at all (having the history of years of personal pain on what it takes to get a release out in an acceptable shape to push to Ubuntu) :)
  • How to interact properly with the Ubuntu processes? Only core developpers, motus, and per-package uploaders have upload rights to Ubuntu. Will this new process in some way give our internal upstream the keys to the archives, without having them proper upload rights?
  • How ensuring packaging changes and upstream changes are in sync, when preparing a daily release?
  • How making useful information in the changelog so that someone not following closely upstream merges but only looking at the published packages in raring-changes mailing list or update-manager can see what mainly changed in an upload?
  • How to deal with ABI breaks and such transitions, especially when they are cross-stacks (like a bamf API change impacting both indicators and Unity)? How to ensure what we deliver is consistent across the whole stacks of components?
  • How do we ensure that we are not bindly releasing useless changes (or even an upload with no change at all) and so, using more bandwith, build time, and so on, for nothing?

How then?

I’ll detail much of those questions and how we try to address those challenges in the subsequent suite of blog posts. Just for now, to sum up, we have a good automated test suite, and stacks are only uploaded to Ubuntu if:

  1. their internal and integration tests are passing above a certain theshold of accepted failures.
  2. they don’t regress other stacks

Stabilizing those tests to get reliable result was a tremendous work for a cross-team effort, and I’m really glad that we are confident in them to finally enable those daily release.

On another hand, additional control is made to ensure that packaging changes are not committed without someone with upload right being in the loop for acking the final change before the copy to the distribution happens.

Of course, the whole machinery is not limited to this and is in fact way more complicated, I’ll have the pleasure the write about those in separate blog posts in the following days. Stay tuned!

Notes

[1] particularly around the feature freeze

[2] the Ubuntu platform team here, not Ubuntu itself ;)

Source: FULL ARTICLE at Planet Ubuntu