• Launchpad Entry: server-lucid-papercuts

• Created: 2009-11-20

• Contributors: ThierryCarrez

• Packages affected:

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

This project should trigger some community interest.

Design

Community-driven

This effort is highly community-driven. Daily users of Ubuntu Server are the best people to identify those pain points. By accepting only relatively easy bugs, we also make sure that the community can participate in fixing those bugs. All the project should be tightly integrated in the Ubuntu Server team meeting so that we can discuss the design, follow progress and apply any necessary change.

Nomination mechanism

There are two approaches here. One is to use a separate project in Launchpad (like for the "One hundred papercuts" project), the other is to use a set of tags.

LP Project approach:

• Nominate by marking Also affects project

• Accept by marking bug Confirmed for the project

• Reject by marking bug Invalid for the project

• Find bugs by looking at project bugs

• Fix-release in both Ubuntu and project

LP tag approach:

• Nominate by tagging server-papercut-proposed

• Accept by tagging server-papercut

• Reject by marking server-papercut-refused

• Find bugs by searching for tags
• Fix-release in Ubuntu

Discussed on Jan 13 meeting, decision was to use Project.

Acceptance criteria

Discussed on Jan 20th meeting.

• Server packages (in main, universe or multiverse)

• Should be considered as bugs, not features, so as to be fixable after FeatureFreeze.

• "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
  • Less than 2 hours to fix
  • Obvious and non-controversial solution

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

Anything relevant for "server experience" but too vast to be fixed as a papercut should be kept as a Lucid+1 blueprint idea, on a specific wikipage.

Publicity

Discussed at Jan 20th meeting:

In order to gather momentum around the project it is necessary to announce it on multiple community channels, once the nomination and acceptance criteria are defined, including but not limited to:

• Ubuntu weekly newsletter
• Ubuntu Server blog -- DONE
• Personal blogs
• ubuntu-server ML
• ubuntu-devel ML

Measurable bugfixing goals

The "One hundred papercuts" project had measurable goals under the form of 10 weekly sets of 10 bugs. We should also set some reasonable goal for this project, however I'm not sure a 10x10-like format would work for us. We'll start this effort later in the cycle. Given the size of our developer community, the most important is to make sure that all proposed patches get properly sponsored. The usual sponsoring time can be used for this. We can also dedicate some time specifically to papercuts bugs, and measure progress during the weekly meeting

Test/Demo Plan

This is not a feature so there is no test plan. The project is completed when all the process is in place. Success is measurable to the number of bug fixes that the project produced.

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