MOTUApplication

I, Scott Howard, apply for MOTU upload rights.

Name

Scott Howard

Launchpad Page

https://launchpad.net/~showard314

Who I am

Professor of Electrical Engineering work bio. Expertise in optical biomedical sensing/diagnostics/imaging. General hacker-ish approach to everything.

My Ubuntu story

My involvement

I've been involved in Ubuntu development for 8 years. In fact, this was my gateway to the open source world. I started off joining the bug squad, doing a bunch of bug squashing days, then joined bug-control (and over the first year or two reviewed many bug-control applications). I "adopted" gnome-power-manager for bug-triage and ended up fixing enough upstream bugs that I eventually got GNOME upload rights. At the same time I started working on maintaining universe packages. I joined MOTU science, and put a lot of effort in keeping Debian and Ubuntu in sync by pushing bug fixes to Debian and doing merges/syncs back to Ubuntu. Through this work with Debian, I adopted some Debian packages and got involved with debian-java and debian-science.

As I worked with Debian packages, I became a DD and have been a DD now for 5 years or so. You can see my Debian work here; I am the original packager and primary maintainer of nearly all of those packages.

I've also been an active Debian sponsor, and have helped applications that wanted to get in to Ubuntu get in to Ubuntu via Debian. Specifically, OpenMW, LibreCAD, and TripleA are all packages I worked with upstream to get in to Ubuntu via Debian when the authors lacked expertise. As a sponsor, I enjoy mentoring new contributors and have worked with and then advocated for several current DMs and DDs.

I've worked significantly with many upstream projects helping them with licensing issues (ensuring DFSG) and packaging.

I maintain automated daily build PPAs for a few projects.

Examples of my work / Things I'm proud of

See: https://wiki.ubuntu.com/ScottHoward/ContributingDeveloperApplication

  • Many SRUs (including several I stumbled across myself, triaged, wrote the patch, got it sponsored)
  • Numerous new packages in Debian & Ubuntu such as LibreCAD, Arduino (currently out-of-date because of licensing issues), OpenMW. Adopted or packaged required libraries for those packages. Sponsored many other Debian package uploads.

  • Lots of fixes, merges and syncs. My list at https://launchpad.net/~showard314/+related-software does not include the team packages of which I am the maintainer and help with in Debian. I also fix all ubuntu bugs in the Debian package and work hard to eliminate merges so packages can just sync.

  • As of 2011, I was involved with > 600 bugs, 200+ of them are fix released/committed (some of them are duplicate upstream trackers and the bug itself, this is just a rough interest). Now it's much more - but I can't keep track.

Areas of work

  • All the Debian packages I maintain.

  • My original work with gnome-power-manager and the desktop team pitti and fabrice sponsored a bunch of my first work. I also wrote, patched, and coordinated the all the strings that gnome power manager displays on Ubuntu and GNOME after getting feedback from the Ayatana team and sabdfl. Lots of maintenance of MOTU-science packages and with the debian-science (specifically with Andreas Tille, Steffen Moeller). Updating and maintenance of java packages and libraries with debian-java (Torsten Werner) and Edubuntu (Jonathan Carter).

Things I could do better

I could be on IRC more, I mostly work over email. I used to be more involved with Ubuntu MOTU mentorship, but haven't had time lately. I worked a bit on trying to resurrect the MOTU-mentoring program a few years ago (under the new name "developer mentoring"). However, the patch pilot and packaging sessions, I think, are a much more useful at identifying quality new developers as well as in getting people involved in high quality work immediately. They also appear to be good uses of limited developer time.

Plans for the future

General

Continued two-way coordination of Debian and Ubuntu packages. Keep maintaining and packaging the best and newest scientific software in Debian and Ubuntu, sponsoring MOTU-science packages (and other Universe packages).

What I like least in Ubuntu

To talk about what I like least, I need to explain about what I like most - as what I like least detracts from what I like most!

  1. It just works. My mother-in-law used it xubuntu on an ancient laptop as her primary OS for a few years, and didn't even notice a difference
  2. It just works really really well. I use this as my primary OS at home and at work, my productivity is extremely high due to how nicely everything works together and the available and powerful packages that are available
  3. Built within a larger OSS ecosystem. Ubuntu is built on Debian, which is the distro I agree with both the most philosophically and technically. Since Ubuntu strengthens Debian, and vice versa - this is great. Same with desktop (GNOME, KDE, etc) and individual packages.

  4. Dependency system is sane. This is inherited from Debian, but library support and multi-lib support is phenomenal.

Now for what I don't like:

Incorporating alternative packaging systems (Maven, npm, and pip/PyPi) within Ubuntu packages. This is double frustrating because I think Ubuntu/Debian "does it right," yet these systems are extremely useful to developers and users by skipping over some of the technical rigour in Ubuntu/Debian.

My fear is that by skipping all the work Ubuntu and Debian (and all the distros do, really) to make sure software is kept modern and bug free is skipped over which can lead to bitrot and packages depending on buggy, unsupported, or even insecure libraries. That is my slight fear for the "docker-ization" of everything, where everything is now in a virtual environment or chroot, or you "freeze" your python distribution/java libraries, node modules at an exact version of libraries is that it makes hunting down bugs harder, and any bugs fixed may only help a small subset of packages. Sure, you get perfect alignment of libraries and binaries, disk space is cheap so redundancy isn't a big issue, but the amount of maintenance to keep all these packages (and dependencies) secure and up-to-date is intimidating. I acknowledge that it is a move towards cross-platform package distribution, but even that isn't guaranteed yet (some pip packages work on Windows and not linux, and others the other-way-around).

It is frustrating trying to unify all these distribution systems in order to create a viable Ubuntu package. For example, I was looking into what it would take to create a node-js package for a very common node build tool Lineman Task list. Even though there exists easy tools (npm2deb) to help us, that is a scary hill to climb. So the question is, "how can we continue to do things the 'right way' and properly leverage these new repositories/way of getting stuff done?"

I don't like the duplication of effort now spreading in the OSS world to maintain packages in each distro and in the language's own package archive; and I don't like that so many projects in those new archives have no license or regard for other project's license.

Will Snappy help? I know it's meant for small systems, but it may help marry Ubuntu packages with other package repositories. Overall, I haven't worked with it enough to have opinion. I love that Ubuntu does push the envelope and does positively change projects (e.g., all the UI work sdbdft and the ayatana team did, lots of infrastructure improvements like multilib in Debian), but there are other cases where Ubuntu pushed their in-house technology rather than get behind contribute/collaborate another which leads to duplication of effort and division of attention (bzr over git, upstart over systemd, ubuntu software centre vs gnome). It seems Ubuntu has a better history forking and improving existing projects than investing their resources in in-house ones. Of course, it's easy to look back and say something should or should not have been done, but I think there is still something to learn from looking what was good in common with a group of things that worked well or not. My fear, for Snappy, is whether it will "win out" over other container-based package management systems. Without Debian on board (as they were for multilib), I'm worried it may end up the same way upstart did. But there are other goals for Canonical and Ubuntu where "Snappy" could be a success without widespread adoption externally.


Comments

If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.


Endorsements

As a sponsor, just copy the template below, fill it out and add it to this section.


TEMPLATE

== <SPONSORS NAME> ==
=== General feedback ===
## Please fill us in on your shared experience. (How many packages did you sponsor? How would you judge the quality? How would you describe the improvements? Do you trust the applicant?)

=== Specific Experiences of working together ===
''Please add good examples of your work together, but also cases that could have handled better.''
## Full list of sponsored packages can be generated here:
## http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?
=== Areas of Improvement ===


CategoryMOTUApplication

ScottHoward/MOTUApplication (last edited 2016-03-22 15:55:51 by localhost)