ServerPapercutsSpec

Revision 2 as of 2009-12-03 09:18:48

Clear message

Summary

In the same vein as the One hundred papercuts project, the Server papercuts projects targets server usability issues and annoyances to make 10.04 a release that is more straightforward and painless to use.

Release Note

Thanks to the Server papercuts project, lots of usability fixes were applied to the Ubuntu Server 10.04 release, making it the easiest and most painless to use Ubuntu Server release ever.

Rationale

When focusing on new features and high-profile bugs, it's easy to overlook low-hanging fruit that could make the days of sysadmins using Ubuntu Server better. Some packages in main ship with bad default configurations, weird ways of enabling them or are altogether unfriendly. Most of the time the behavior is inherited from Debian and never questioned, while we could fix them so that they just work.

This project is about formalizing the search and fix of this low-hanging fruit, harnessing the power of the community to identify such bugs. It's also a great message to send for an LTS that we specifically concentrate resources on such bugfixing efforts.

User stories

As an Ubuntu Server user, I know first-hand what minor annoyances I encounter when using Ubuntu Server. I nominate the relevant bugs to the server papercuts project and it is brought to the attention of developers as low-hanging fruit that can make the experience better.

As a system administrator, I always have to do A in order to achieve B, which is painful. With Ubuntu 10.04 release, I'm happy to see this minor everyday annoyance fixed, and I can report everywhere that 10.04 LTS is really a rocking release.

Assumptions

Design

  • Goals
    • Improve Ubuntu Server

    • Involve community in nomination and fixes

    • Nice message to send to the world
  • Bug acceptance criteria
    • "Server experience" issues
      • Out-of-the-box readiness (bad default configs, package requiring manual steps to go from installed to running)
      • Teamplay (packages not working well together, while making sense to be used together)
      • Smooth operation (anything requiring tedious or repetitive manual work)
      • Missing documentation (missing man pages, missing inline comments in default configs)
      • Upgrade issues (init scripts failures blowing up maintainer scripts)
      • Cruft (broken symlinks, residue of purge)
      • Consistency (upstartification ?)
    • easy to fix

      • Not a papercut: Making the right software to install easy to find (good idea, too large project)

  • Project/tag creation
  • Announce project publicly
  • Start triaging papercuts nominations and plan fixes
  • Fix fix sponsor fix

Test/Demo Plan

tbd.

Unresolved issues

None.

BoF agenda and discussion

UDS discussion notes

Session purpose

Some packages in main ship with bad default configurations, weird ways of enabling them or are altogether unfriendly. Most of the time the behavior is inherited from Debian and never questioned, while we should fix them so that they just work[tm]. We should take the opportunity of the LTS cycle to review main packages for such issues and fix them. This session is about discussing the process to follow and potentially identify some targets.

Relevant issues

  • "Server experience" issues, easy to fix
  • Examples
    • Bad default configurations
    • Packages difficult to configure (too long to go from install to run)
    • Packages not working well together (while making sense to be used together)
    • Anything requiring tedious or repetitive manual work

To do this we need some fixed criteria for acceptance as a 'server paper cut'.

  • how big a bug counts as a paper cut
    • size/time etc ?
  • we should pick clear classes of bugs to attack
  • usability/user experience sounds like a clear area
  • admin steps from install to running is often 'complex'
  • we may not be the right people to even see a server paper cut as we know how things work
  • consistancy is a big driver on desktop paper-cuts

Goals

  • Usability improvements, particularly for frustrating things
  • Small chunks of work ("rhythmic, can do over and over again")
  • Community involvement
  • consistency
  • minimize our delta with debian

Example small usability improvements

  • command-not-found improvements
    • add more keywords
    • note that command-not-found only works when someone tries to run something, which doesn't really help when you don't have it installed and are looking for what to install

    • perhaps we need a 'whereis <foo>' which essentially does the search and output

  • tab-completion for more utilities
  • init script status action
  • upstartification of more init scripts
  • links to the server guide in the package description
  • man pages (missing or out of date)
    • enhance manpages.ubuntu.com to crowdsource manpage editing/creation
      • man pages as wiki pages
      • man pages as a remote browsable object either through the web and command line interface
  • broken symlinks
  • community involvement may be enhanced by this project as things are small
  • can EC2 server help bring people to the testing/papercuts effort
  • package descriptions (also with Software Center)
  • picking package names (we don't have software center on server to help)
    • or methods of finding the right package (apt-cache search isn't very good)
    • Software center tags are the analogy on the desktop -- command line version?
    • can we have something similar to command-not-found /usr/sbin stylee
    • People don't really use tasksel (had to remind them in the MOTD)
    • command-not-found could hint the user to use tasksel
  • ubuntu-server-tips
  • fix default config files that lack inline documentation if there are any
  • daemons you have installed but that don't setup their own init scripts
    • eg mediawiki requires you to uncomment a line before it's published
    • cut down on extra steps (eg edit /etc/default AFTER editing config file even if it was all comments)
    • pointing you to documentation at install time where such configuration is needed
  • maintainer scripts that blow up because the init script failed
    • packages that fail to remove because they can't shut down
  • Apache needs lots of work to do SSL. It should be out-of the box. Maybe create a dummy test cert, etc.
  • samba fails to upgrade if you remove /etc/samba/smb.conf
  • some things may not be papercuts: making the right software to install easy to find is a larger project
    • it may be worth doing this to get to a point where tagging s/w becomes a paper cut
  • more complete "purges" for some packages
  • byobu notification for apport crash (*)

Implementation

  • Start with a survey or discussion to define criteria / examples ?
    • 3 criteria: difficulty, benefit, would you volunteer?

Criteria (Potential)

  • small and quick to fix
  • Potential for acceptance in debian. (really??)

Risks

  • increasing the delta with debian on default configuration changes

CategorySpec