Ubuntu Dev Summit Lays Out Plans For Hardy Heron

Opurt writes "On the first day of the Ubuntu Developer Summit in Boston this week, a roundtable session focused on the vision for the upcoming Hardy Heron Ubuntu release. Unlike Gutsy Gibbon, which brought a handful of experimental features along with some new functionality, the focus with Heron will be on robustness as it will be supported on the desktop for 3 years. 'The Compiz window manager, which adds sophisticated visual effects to the Ubuntu user interface, will be a big target for usability improvements. Keyboard bindings and session management were noted as two areas where Compiz still needs some work.' PolicyKit and Tracker will also be significantly tweaked, while Heron is also likely to see a complete visual refresh."

Comments

more details

[sayfawa]

Here's a better summary of things to come in Hardy, linked from an OS News posting.

Re:can we just use numbers, please.

[kazade84]

The numbering system in Ubuntu is based on year, month of release (e.g 7.10) Obviously in development no-one knows if they are going to meet the deadline or miss it like they did with 6.06. This is the reason that the code names are used.

To make it clearer, development has just started on Hardy Heron, or what is likely to be known as 8.04. To start development the Ubuntu devs create repositories named after the codename (e.g. Hardy). If they used 8.04 and the deadline was missed and the release was actually 8.06 they wouldn't easily be able to change the repositories and other stuff.

The names are just code names, after release the number is the identifier that is used by Ubuntu (see if you can see 'Gutsy' on the Ubuntu.com front page, it's not there) its just usually the the code-names stick it peoples' minds.

So to sum up, the code names are there for a perfectly logical reason, and the animal thing is just a consistent naming theme that was chosen.

Re:Ubuntu To Do List

[EsbenMoseHansen]

* Application bundles - drag and drop install, removal. Ability to drag an .app to anywhere in the file system at any time. App resources all contained in the .app directory structure instead of scattered all over the file system We have this. It's called "deb packages". Works like a charm.

* /Application directory - default place for App bundles to be copied to You mean /application... no need to use capitals. Anyway, I don't see the advantage over the current system. I don't really care where packages are stored, that is my package manager's job. Oh

* /Preferences - standard place for apps to store their user specific settings instead of hidden . files in the main user home directory You mean /preferences :p Anyway, that sounds like a horrible idea. Cleanup after users would get more messy and quotas too. But putting them under ~/.prefs/... might not be a bad idea. There is some merit there, but not an easy thing to change!

* An app interface building tool that has OS X level UI element default spacing when laying out an interface to help with the jarringly hideous problems virtually every Linux app has with visual layo Hmm..I think OSX apps looks terrible, while KDE apps are the cleanest. But all three are quite usable, so I don't see this as a priority. And technically, it isn't the interface building tool's job to layout widgets, that would be horrible! Just imagine what happens when the font changes, or the resolution.