Mario Limonciello
Launchpad:..https://launchpad.net/people/superm1
e-mail:............<superm1 AT ubuntu.com>
e-mail:............<mario_limonciello AT dell.com>
IRC nickname:.....superm1 on Freenode network
Physical Location:.......Austin, TX.
Ubuntu Contributions
I've been active in the Ubuntu community for approximately 5 years. This isn't an exhaustive list, but some of the higher profile things that i've worked with.
Developer
I'm currently an ubuntu core-dev, and the only core-dev employed by Dell currently. I was previously a MOTU and also previously had per-package upload rights for DKMS.
Mythbuntu
I started the Mythbuntu project that centers around getting a MythTV box setup with a lightweight Ubuntu based environment. From this project there have been parts all over Ubuntu both in universe and main that are touched. These days its a good Ubuntu citizen and plugins have been developed that integrate tightly with Ubuntu infrastructure such as installation and live CD booting.
MOTU
I work mostly on multimedia related applications. You can take a look at my last 50 uploads at https://edge.launchpad.net/~superm1/+related-software and see that a majority of them end up being things that would be touched in a multimedia environment, but that also benefit the distro.
Installer
I've been involved with installer development for a while now. An example of this was one of my really early contributions that split Ubiquity into a lot of glade files loaded at startup rather than a monolithic glade file that was very difficult to deal with. Today I do a lot of bug fixing.
For Mythbuntu, used to have a custom written frontend that inherited functionality from the GTK frontend. I've converted this to fit into the newer ubiquity plugin architecture that was initially developed by Mike Terry. I've also added more features to the plugin architecture and help to maintain it now.
Kernel
I have helped tracking down bugs with Dell hardware and either coordinating patches with vendors or other developers or writing patches.
LIRC
I've been maintaining the LIRC package (which is in main) for some time now. Originally I moved all the lirc drivers into the kernel in a ubuntu/ director, but this has since then been dropped as they're moved into the kernel proper now. I have written some extensive debconf scripts to make it a simpler experience to use a remote and tie into mythbuntu frontends.
Dell
Since working at Dell on the Ubuntu team, I try to make all of the changes necessary to enable Dell hardware available in the current development release of Ubuntu prior to the machines shipping out of the factory. I end up working with a lot of the above teams to keep efforts in sync and regularly have to interact with a lot of people in the community.
dell-recovery
I've encapsulated all of the open source portions of dell factory install into a package stored in the Ubuntu archive called dell-recovery. The same package is shipped after install and can be used to generate recovery media from a recovery partition or from a source ISO image and a collection of driver packages.
oem-config
By working on dell-recovery a lot, I also find and fix a lot of oem-config bugs in the process.
DKMS
One of the specs that I helped to make happen was to move the proprietary drivers out of LRM and into their own packages. Centering around this spec is a tool to allow the kernel modules to be built on your running kernel. This is what DKMS provides. I am the upstream maintainer for DKMS ( http://linux.dell.com/dkms/ ) and have also been doing simultaneous uploads to Ubuntu when I do releases upstream.
DKMS is now in main so that restricted drivers can be installed without activating universe.
Future Ubuntu
As you can see above, I wear a lot of different hats. So when asked a specific question about what I think needs to change with Ubuntu I might spit out 4 different answers depending on what hat i'm wearing.
Cadence
Generally though I think all of my hats would agree there is a lot of tension with Ubuntu's release cadence. For Ubuntu to continue to be successful the target audience needs to be better defined. The release structure can then be defined around how that audience would use the software, install new software and update it.
Chrome OS hits the nail on the head in terms of where I think update technology needs to go. A consumer doesn't need to go out of their way to click update, and they don't even need to know what's being updated. It's no maintenance and you never need to worry about breaking applications.
Vendor applications
This plays a lot into the cadence point, but it's an impossible goal to require a third party closed source vendor to maintain software that works on all Ubuntu releases. Libraries can't be guaranteed from one release to another, KABI is never stable. The only way that some applications get by is by including static versions of libraries that are otherwise on the system to be used by applications. Rather than having a giant merge fest every release with what came in from Debian, I think it might actually be better to scrutinize things and only merge them if there actually is a perceived benefit to the user and fixes specific bugs/problems.
...